0

Before anything, I know the difference between git pull and git fetch.

However, I'd like to pull every branch at a time, and I learned that a command git pull --all exists, but it did not accomplish that purpose, as it fetches all branches but only merges the one I am working in with its remote (and other stackoverflow posts like this assured me that).

The documentation on man git-pull references the git fetch command and in the --all section says 

   Options related to fetching
   --all
       Fetch all remotes.

My question is, then, therotical.

Does it make sense to exist a git pull --all since its name is misleading?

And does it make sense to reference man git-fetch in a way that also misleads, since git pull --all is not the same as git fetch --all ?

(I know this question may sound like primarily opinion based question, however maybe I can get from you an understanding of these git commands that I do not have now. And others may not have it as well.)

Paolo
  • 21,270
  • 6
  • 38
  • 69
samthegolden
  • 1,366
  • 1
  • 10
  • 26

2 Answers2

3

This is likely because git pull involves, necessarily, a git fetch operation. git fetch has an --all flag, so we get an --all flag on git pull as well, just so git pull can pass that exact same flag to git fetch (which it absolutely has to be able to do).

Yes, the name could be different, and that might avoid confusion, but I think it's equally confusing to have git pull have a flag called --all-remotes, for instance, which ends up being used like the --all option of fetch. Maybe if they changed the --all option on fetch to --all-remotes as well, it would work out -- but then you'd be proposing a major API change for a possible slight improvement in clarity, and that's generally a bad idea.

Sidenote: there is no built-in command to update all branches at once, as far as I'm aware. Hub has sync, which will do this, but short of that, my research seems to indicate that your best bet is making your own alias or function to check out all branches one by one.

inim
  • 146
  • 3
  • 1
    Update all branches: `git fetch 'refs/heads/*:refs/remotes/origin/*'`. You can [configure git](https://stackoverflow.com/a/25941875/7976758) to do this automatically on just `git fetch [origin]`. – phd Dec 19 '19 at 18:28
1

The original git pull was a shell script that:

  • ran two Git commands: git fetch, then a second one, usually git merge;1
  • recognized particular options as its own, and took them out of its argument list;
  • recognized particular options as ones to pass to the second command, and took them out of the argument list as well until running the second command; and
  • without really looking, just passed everything that was left to the first Git command, git fetch.

As such, if you wanted to run git fetch --all followed by pull's selected second Git command, you could run git pull --all. The fact that this is rarely useful—and not at all useful to the second command, whatever it might be—was not really relevant. The script was dumb and just passed everything through.

The Git authors strive to maintain backwards compatibility. Therefore, if you could do something pointless before git pull was rewritten to make it go fast on Windows, the rewrite has to support everything you could do before the rewrite. Therefore it must accept, and pass on, the --all option, even though there is little point in doing so.

1The other obvious one is git rebase. However, there are a bunch of tricky corner cases, such as when running git pull in a new, otherwise-empty repository, so that in some rare situations, git pull had to use yet another different second command. The script got this wrong at least once, and I once wrecked several days of work this way. I no longer use git pull if I can possibly avoid it.

(In the empty-repository case, we just want to create the current branch based on the result of the fetch. There is nothing to merge or rebase, so we can use neither git merge nor git rebase. But what if there are untracked files? The original git pull script destroyed them.)

torek
  • 448,244
  • 59
  • 642
  • 775