4

Possible Duplicate:
Can “git pull --all” update all my local branches?

I'm a happy Git user. But I find that I'm often doing a lot of pulling, and maybe this can be automated.

I mean, I'm working on a local repo, and the remote is Github. I have several branches, say master, dev and bugfixing. I work on multiple computers, so often I have to push a branch from one computer and pull it from the other.

This is tedious. This can sometimes take a lot of time. For example, say I'm on master. I can do git pull and have the updated origin/master merged into it. But then say that origin/dev was updated too. Now I need to git checkout dev and git merge origin/dev and finally git checkout master. That's really annoying. And don't get me started on these times where the branches aren't set to track their respective remote branches and I have to do git branch --set-upstream master origin/master.

Is there a way to have all the branches merge in the remote branches automatically? We can assume that all of the merges are fast-forward. (If they aren't I have no problem with just getting an error message so I'll manually merge.)

Community
  • 1
  • 1
Ram Rachum
  • 84,019
  • 84
  • 236
  • 374
  • Is there any fundamental reason why you can't simply pull/push directly to/from your other computer, rather than doing a two stage process whereby you push to github and then pull from github on another computer? – Robin Green Apr 22 '11 at 11:36
  • For one, I'd like everything to be pushed to Github, so I wouldn't want to push to both places every time. Also I want to be able to scale this workflow on an unlimited number of computers and VMs, and pushing to all of them every time would be very inconvenient. – Ram Rachum Apr 22 '11 at 12:36

4 Answers4

2

This isn't something I'd want to do myself, but out of interest I've written a script that (I think) does what you want:

This first updates your remote-tracking branches from every remote that doesn't have remote.<name>.skipDefaultUpdate set to true. Then it goes through all of your local branches (i.e. those under refs/heads) and for each one that has an upstream branch set, sees if your local branch can be fast-forwarded. If so, it updates your branch.

Finally, it tries to merge the upstream for your current branch (if it is set) into the current branch, as would happen with git pull.

I've tested this a bit, but note that because of the use of the plumbing command git update-ref to do the fast-forward, it's potentially dangerous if there's some bug in the script, so no warranties, please test carefully, understand what it's doing, etc.

And don't get me started on these times where the branches aren't set to track their respective remote branches and I have to do git branch --set-upstream master origin/master

The only problem I have with that command is the really confusing results if you forget to include master - an easier alternative is to use git push -u <remote-name> <refspec> on one of the occasions when you push the branch.

Mark Longair
  • 446,582
  • 72
  • 411
  • 327
  • Thanks for the script. I don't have time though to test, debug, maintain and distribute the script on the different computers and VMs I work on. – Ram Rachum Apr 22 '11 at 12:56
  • .... but apparently neither do you have time between running `git checkout dev` and starting work on that branch to notice that it says "Your branch dev is behind origin/dev by 5 commits and may be fast-forwarded" and then do `git merge origin/dev` in response. – Mark Longair Apr 22 '11 at 13:27
  • Yep, those are both problems. A solution might be implementing something like this into Git itself as `git push --merge-all` or something. – Ram Rachum Apr 22 '11 at 14:04
1

If you want to work this way there's no reason to keep your local branches up to date. Just use git fetch origin to get what's new on the other side, and sync our local branches only when you want to commit to them.

Until then, you can do just git checkout origin/dev to inspect the code there.

che
  • 12,097
  • 7
  • 42
  • 71
  • "sync local branches only when you want to commit to them." I often want to commit to them, and having to sync them manually is exactly what I'm trying to avoid. – Ram Rachum Apr 22 '11 at 12:37
  • @cool-RR: How about starting with `git fetch`, and then creating alias command that will do `git checkout $branch && git reset --hard origin/$branch`, and using that instead of checkout+pull? – che Apr 23 '11 at 15:40
0

Automatically - I can only think of using hooks to do all thinks automatic that you want out of your repos. Say a post-receive hook ( on server side) to push, merge, checkout etc. Or a post-commit hook ( on client side )

Git Automatically push to Dev and Production from Central Repository depending on branch pushed

Community
  • 1
  • 1
manojlds
  • 290,304
  • 63
  • 469
  • 417
-2

I'm not sure i've understood what you want, but how about:

git pull --all

?

Tom Anderson
  • 46,189
  • 17
  • 92
  • 133
  • 3
    The `--all` is only passed to `git fetch`, so all remote-tracking branches are updated but only one merge will be tried. The questioner wants all local branches to be fast-forwarded from their upstream remote-tracking branches where that's possible. There's a question about the behaviour of `git pull --all` here: http://stackoverflow.com/q/4318161/223092 – Mark Longair Apr 22 '11 at 12:35
  • I tried it, but it doesn't seem to merge the different branches. i.e., if I'm on `dev` and I do `git pull --all`, this command would _not_ merge `origin/master` into `master`. – Ram Rachum Apr 22 '11 at 12:41
  • (Incidentally, I wasn't the downvoter.) – Mark Longair Apr 22 '11 at 12:55
  • @Mark: Why not? It's an incorrect answer! – Tom Anderson Apr 22 '11 at 12:56