1. 17

  2. 4

    This is very handy - I hit this problem just last week and had “figure out how to make git aliases work for both main/master” on my todo list. Thank you!

    1. 2

      Note, this presumes your git clone actually set refs/remote/$REMOTE/HEAD to point to the branch which if you set the config option pull.default to say simple will be the case. Additionally old versions of git servers didn’t always set the HEAD back and your clone may not have this. (cough atlassian stash cough)

      If not, none of this is going to work. Additionally the remote technically could update the refs in between you.

      git ls-remote origin

      Might be a more “correct” way to get at the default branch name on a remote, but means a network call and looking at the HEAD commit and which ref branch is the same as HEAD.

      1. 1

        You’re right, my thought was this would work in the majority of cases (Github, etc) and would avoid the network call which would slow things down in the general case. Alternatively you could also run git remote set-head origin --auto every so often but realistically how often is a repository going to change the default branch. We now live in a world where there is no longer a standard convention for default branch names (it was always possible to change but Github changed the default) and I needed a way to not have to worry about that for every repository.

        1. 3

          Yep its fine as-is, just wanted to basically say “Its complicated” and that this whole branch name change hadn’t helped matters and made git even more sharp edged. I think its good to at least note that these aliases need to be treated in the vein of a manual transmission, miss clutching and you’ll end up stalling the engine.

          One other way this can all fall down is if the remote is also not named origin (easy to do as well!). Or you did a git init without any remote.

          To be honest I’ve not come up with any amount of aliases/wrappers or anything that can adapt to all these permutations and wish we never had this happen or that git had a better way to track this than a bunch of weird plumbing commands that solve 80% of the problem. /rant mode off

      2. 2

        Some of these seem not very useful

          diff = diff master

        This seems like a no-op according to the git-config(1)

        To avoid confusion and troubles with script usage, aliases that hide existing Git commands are ignored.

        It also seems like a strange use-case. From my command history, I mostly use git diff, git diff-cached, and git diff $somefile. I’m not sure that I would want to default comparing against master instead of the default of comparing against HEAD.

          pom = push origin master
          merged-branches = "!git branch --merged master"
          sync = "!git fetch -p && git rebase origin/master"

        Why not just !git fetch && git rebase? If you’ve set your upstream, you don’t need to specify to rebase onto a particular branch all the time.

        1. 2

          I use git diff master all the time - I tend to create a series of small semantic commits and often want to see “what all have I changed in this feature branch”, especially before submitting a PR.

          1. 1

            I tend to use git log (-p) for that sort of thing. If the changes are committed, then I want to use the structure I created for myself!