4 ms·

I meant: (we're in branch A) >git pull ... From ... rev1..rev2 A -> origin/A rev3..rev4 B -> origin/B Updating rev1..rev2 Fast-forward --- The fast-fo

by yyyk 2y ago

I meant: (we're in branch A) >git pull ... From ... rev1..rev2 A -> origin/A rev3..rev4 B -> origin/B Updating rev1..rev2 Fast-forward --- The fast-forward is on branch A. I'd like the git pull to also fast-forward branch B (and branches C,D,Etc.). They're usually by other devs, I don't usually check these, but when I do, I could save an extra command when switching if git just moved the branch head with the data it already has.

mook 2y ago
I work around it with: git checkout origin/A There's no reason to clutter `git branch list` output with branches I don't care about.
- deleted 2y ago
  [deleted]
- yyyk 2y ago
  I do care, I just won't be committing there 99% of the time. Your idea is interesting, didn't know that's useful. Detached head is a bit annoying though.
matthberg 2y ago
You're right that doesn't fix it and it is annoying. I just learned something about git, thanks! Thinking on this more I think I'd prefer changing `git checkout/switch <branch>` to automatically use `origin/<branch>` instead (like mook mentions in a sibling comment), rather than changing the `git pull` behavior. Keeping the local branch refs in place after `git pull` lets you still easily see the local vs remote differences when running `git log`. Changing the behavior of `git checkout` or whatever you use to switch branches to auto fast-forward seems to be a way to have your cake and eat it too, almost. But, clearly you've thought more on this than I have (having just learned about it lol), what do you think?
- yyyk 2y ago
  These aren't branches I commit regularly to, but I'd rather avoid the detached head state when using 'origin/'. Auto fast-forwarding on switch would be good enough for me.