3 ms·

EDIT: I was wrong and misunderstanding how these options interact, this doesn't solve the stated problem. Still good to have in your config but not as powerful

EDIT: I was wrong and misunderstanding how these options interact, this doesn't solve the stated problem. Still good to have in your config but not as powerful as desired, sorry. Keeping comment contents mostly for posterity's sake. Under the hood `git pull` is just `git fetch`+`git merge` so these two configs together would ideally enable the behavior requested (but unfortunately don't): [fetch] all = true [pull] ff = only I also disable fast-forwarding with `git merge` since I prefer the branch topology you get without it. This doesn't break natural `git pull` fast-forwarding either, thanks to the above config: [merge] ff = false Commands to set all these: git config --global fetch.all true git config --global pull.ff only git config --global merge.ff false

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.

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.