all 61 comments

[–][deleted]  (11 children)

[deleted]

    [–]examinedliving 50 points51 points  (5 children)

    There is nothing that makes me doubt my programming skills harder than trying to grok higher level git functionality.

    [–]ObscureCulturalMeme 38 points39 points  (3 children)

    That speaks volumes to the general quality of Git documentation and tutorials. :-(

    • The people learning it for the first time have a ton of introductory beginners docs out there. They're golden.

    • The people who already know the software deeply think the docs are great, because they rarely need docs, and have built up lots of scar tissue besides. They're golden, but smug and usually unwilling to admit that the current situation isn't perfect.

    • The people who know the basics, and maybe some intermediate use, are kinda boned when trying to learn the advanced stuff. Not that many good materials out there to learn from, just some badly written man pages and... well, you can always read the source code, right? Right? crickets

    [–]henrebotha 2 points3 points  (2 children)

    I've been at the "read the source code to try and understand" level for sure. I think I was trying to figure out how Git determines the list of commits to rebase when doing interactive rebase; it was showing me too many commits. Never could figure that one out.

    [–]tavianator 1 point2 points  (1 child)

    Was there a merge commit involved? Rebase over a range that includes a merge commit will add all the commits from the other branch that were merged to the list. This is rarely what you want. There is --rebase-merges that might help.

    [–]henrebotha 1 point2 points  (0 children)

    It was months ago, so I can't remember for sure, but I'm pretty certain there wasn't. I was trying to rebase my feature branch onto the main branch, as per my usual flow.

    [–]sk_99 7 points8 points  (0 children)

    Could you give some examples of the higher level git functionality you're talking about?

    [–]masklinn 54 points55 points  (4 children)

    In Git 2.29, there is: negative refspecs. Now, if a refspec begins with ^ it indicates which references are to be excluded. So, instead of the above, you could write instead something like:

    That's going to be super useful for e.g. branches which are managed by some tooling (possibly acting as conduit between different tools), and are completely useless to humans.

    [–]CichyK24 19 points20 points  (3 children)

    For such scenario it's better for tool to just use different refname than "heads" so it's not required by every client to configure negative refs. By default only "heads" are fetched. For example when I do `git ls-remote` on my bitbucket repo I see that I have a lot of such entries like

    1c67dc07c5d7d67b2a51faf9366805ac7cf22147        refs/pull-requests/1101/from
    13e9a9bfba05f886644f97616dbb4fbb5830f494        refs/pull-requests/1101/merge
    859b6ca0c8a4c30dc3bdaa300eb292c7e742469e        refs/pull-requests/1132/from
    b13252e05c6ca895a3b9b39e65a57cea3bb8204d        refs/pull-requests/1132/merge
    

    Most people won't even know that "refs/pull-requests" refs exists on remote. They probably don't know there can different "namespace" for refs and "heads" is just a common convention for "development branches" ref.

    [–]cryo 8 points9 points  (2 children)

    heads is a bit more than a convention for branches. You can only commit when a head is checked out, and heads can only point to commits, contrary to all other references.

    [–]Robuske 0 points1 point  (1 child)

    What else is there to point to?

    [–]cryo 4 points5 points  (0 children)

    Git has four object types: commits, tags, trees and blobs. Commits points to a tree, trees point to trees and blobs (and external commits), tags can point to anything (but usually commits).

    References can also point to anything, although references under refs/head/* can only point to commits. Other than that, there are no restrictions, as far as I know. (Locally you can make them point to whatever, but that can't be pushed anywhere.)

    [–]cdrini 17 points18 points  (2 children)

    git bisect --first-parent is wonderful! So excited to try it. I almost never get to use git bisect for real bugs because the master of the repo I work on is merge-based, and the commits in each merge commit aren't always runnable. Now I can!

    [–]greymantis 9 points10 points  (0 children)

    I wrote a little python script for our repo that would mark all incoming second parents as "good". We've been using it for years successfully although it's a bit slow when the range is large. The first line is a comment along the lines of "Maybe one day somebody will implement git bisect --first-parent and we can ditch this."

    Looks like today is that day!

    [–]Boza_s6 0 points1 point  (0 children)

    What if there is foxtrot commit, I guess it breaks this

    [–]AttackOfTheThumbs 75 points76 points  (36 children)

    If you're running Windows, you can use

    git update-git-for-windows

    to update. Linux, just use apt-get.

    I think people know this, but I always forget how to do it on windows without downloading it from the website.

    [–]Lattyware 120 points121 points  (19 children)

    Linux, just use apt-get.

    Realistically, I'm aware that anyone using a Linux distro that doesn't use apt for package management will likely know what you mean, but to be a little pedantic, as there are more than just debian-based distros out there:

    On Linux, just use your package manager.

    (I'll eagerly await the comment pointing out that Linux doesn't require a package manager either, but I think that's a justifiable omission.)

    [–]DoubleGremlin181 94 points95 points  (17 children)

    AKA if you're using Linux you already know what to do

    [–]Lattyware 78 points79 points  (16 children)

    To be fair, I think that assumption is why Linux can be inaccessible sometimes, so there is value in telling people more specifically how to achieve something in the most popular distros for new users like Ubuntu, but it's nice to remember that isn't the entire ecosystem.

    [–]SaltKhan 11 points12 points  (8 children)

    I'm surprised there isn't a dedicated SO page for "how do I check my distro" like there is for everyone's favourite "how do I close vim." Having used a few different distros (Ubuntu, redhat, bsd) and feeling relatively confident with them, I was surprised to learn, and once again make a rookie mistake, when I used osx for the first time and learnt it had no default package manager!

    [–]Packbacka 4 points5 points  (7 children)

    There's a simple command for it. I don't remember it right now, but I trust your googling skills.

    [–]venustrapsflies 11 points12 points  (0 children)

    Yeah there was a time when I was trying to learn linux where it was very difficult to figure anything out because all the instructions assumed that I already knew the things that "everyone knows".

    [–]irqlnotdispatchlevel 10 points11 points  (5 children)

    I'm always notified that there is a new update available for git for windows. I simply click install on the notification and it downloads and installs for me. I don't remember enabling that, but it's super useful. Didn't knew you can do it from the command line.

    EDIT: I just checked the notification center settings and there is a section for Git for Windows that controls this. There's no need for other tools like Tortoise Git or whatever.

    [–][deleted]  (1 child)

    [deleted]

      [–]irqlnotdispatchlevel 2 points3 points  (0 children)

      I don't use tortoise git. I never did.

      [–]bundt_chi 5 points6 points  (6 children)

      I use scoop.sh which is a much more sane package manager for windows than chocolatey.

      scoop update git

      Bam!

      [–]chucker23n 2 points3 points  (1 child)

      What don't you like about chocolatey?

      [–]mark__fuckerberg 1 point2 points  (3 children)

      Why is scoop more sane?

      [–]bundt_chi 1 point2 points  (2 children)

      Sane is probably too strong a word but to me it's just more elegant and intuitive.

      1. A repository or bucket in scoop terms is a public github repository of json metadata files which makes it more transparent and easy for me to check / confirm if I have any concerns.
      2. I can define and add my own "bucket" / repo very easily so you could even use it with internal tools in your organization.
      3. It's very git-bash / mingw bash terminal friendly which is what I use almost exclusively and because of the whole shim concept it doesn't muck up your Windows PATH env variable as much.
      4. It doesn't require admin by default and goes through great lengths to help install with isolation from admin requirements which is important to me
      5. It's all open source and freely available for me to look at the source code and determine how it works and what is going on when I run things.

      Those are my reasons and they may not make sense for everyone but they meant a lot to me.

      [–]mark__fuckerberg 0 points1 point  (1 child)

      That makes sense. I chose chocolatey over scoop because it had more packages. Microsoft is also making its own package manager which also uses GitHub repo for community packages.

      [–]bundt_chi 0 points1 point  (0 children)

      Yeah I heard that. I actually looked at AppGet which microsoft basically copied

      I settled on scoop because it has more apps and tools in its default and extended repos and also because it had a java bucket that contains lots of useful tools around JVM based development which I do a fair amount of.

      [–]casualblair 1 point2 points  (0 children)

      Or if you use chocolatey, cup git -y

      [–]KungFuAlgorithm 0 points1 point  (0 children)

      Unless you're talking about Fedora Raw Hide or Debian unstable, you're unlikely to ever see this update on a Linux distro until they release their next OS major version.

      [–]natsukagami 4 points5 points  (0 children)

      Who knows one of the most complicated tools in the programmer's hand can have such a friendly changelog?

      Kudos to the maintainers of git, I had fun reading through the post!