Jeff King <peff@xxxxxxxx> writes: > I would say without hesitation that fast-forwarding the upstream is more > likely to be disastrous than creating a new branch. However, > push.default=current can also fast-forward an existing branch (although > if you have a local "foo" and its upstream is _not_ the remote "foo", I > find it extremely unlikely that a remote "foo" also exists). > > On the other hand, one thing we have not talked about is how one gets > into the "topic push fast-forwards master" situation. Which is running: > > $ git checkout -b topic origin/master > > I'm not sure if that is something totally clueless people will run. And > maybe by the time people are intermediate enough git users to run that, > they will have figured out how upstream works. So maybe my concern is > overblown.... I already said that I do not deeply care either way, and it appears that only you two are the ones who deeply care *and* have things to say that are worth listening to (we've seen many "me too wants upstream" without deep thought a few weeks ago against the RFD). Whichever way you two agree to go eventually, could you come up with a (hopefully) small summary of caveats that can be pasted in the future release notes that switches the default away from the matching? E.g. "The new default is now 'upstream', which does mostly what new people do, but the user should not allow the default kick in in these situations: A, B, C..." It might end up saying "The new default is now 'current',..." but the point is that either semantics would need to come with a warning. Thanks. -- 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