"Martin Langhoff" <martin.langhoff@gmail.com> writes:

quoted text
> 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].

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html