"Martin Langhoff" <martin.langhoff@xxxxxxxxx> writes: > Still, the big fat ![rejected] do seem over the top when I know it > really means "stale". If "stale" can be proven cheaply, I think it would be a very good change to introduce [rejected] vs [stale]. > And I don't completely follow how bad the impact of > auto-fast-forwarding local tracking branches on a merge. If it's a > fast-forward, my "local state" wasn't that exciting to begin with ;-) If your branch is configured to track the remote and when your branch is behind, it probably is safe to assume that the user most likely wants the ff merge to happen _when_ the branch is checked out. I am with you that. I am not sure if that ff should happen when you fetch from the other side as you suggest. Doing so automatically means it would break workflows of people who are deliberately _holding back_ from updating to the remote they are tracking for whatever reason. As you said, the point they were holding back at can be found as _one_ of the reflog entries even if you force the auto-ff upon fetch, but that does mean you are forcing them to go and look for it, while they used to be able to _rely on_ that their tips will not be molested without them telling git to do so explicitly. So I am with you that auto-ff would help more people but I am not convinced it would not hurt anybody. Perhaps making "git-checkout" to notice this and offer (or suggest) fast-forwarding at that point may be safer and make more sense. You cannot grow your local branch unless you check them out, and your remote tracking will keep growing without the auto-ff you are suggesting, so it is not like people will lose anchoring point to compare between branches if we do not auto-ff. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
