[dragging Matthieu, an advocate for "upstream", into this] Jeff King <peff@xxxxxxxx> writes: > OK. Then I think we shouldn't switch to upstream, and I'm ready to > debate it. :) I already posted my arguments earlier in the thread[1]. > What do you think? Honestly speaking, I do not care too deeply either way. The difference between "mixed" and "current/upstream" is a very deep-rooted one and has much more to do with how "batchy" person you are, than if you are pushing to a shared or your own repository. The underlying assumption for the original push semantics of "mixed" (or use of remote.$there.push configuration) is that the way you work is to prepare all your branches to be pushed $there ready by the time when you push $there. Concentrate perfecting your local work, perhaps even being oblivious to what others do in the meantime, and then push out everything in one go. The "oblivious to what others do" part is obviously harder to arrange if you are pushing into a shared repository, but the connection between the "shared repository workflow" and "push everything in one go" is not fundamental. On the other hand, both "current/upstream" are for people whose work habit is to complete _only_ the current branch; when you push it out $there, it does not matter if the other branches that will eventually be pushed out to the same repository are ready. And this "only the doneness of the current branch matter" is fundamentally different from "push everything in one go", and I am already happy to see that future Git is moving in this direction, which also matches the way vast majority of people seem to work. So in that sense, I do not care which one we picked between "current" and "upstream". Obviously the former is much simpler to explain and understand, as people do not have to learn upstream tracking before doing their first "push". > I think we can deal with my first issue (some workflows will cause "git > push" to error out without doing anything) with targeted advice for each > situation. Yes. I think that is up to the people who favored "upstream" over "current" to share their anecdotes to polish such advice messages. > But I still worry about the "implied merge" concern I > raised, and I think the only way to fix that is to have a new mode that > is almost but not quite "upstream" (like the upstream-current hybrid I > mentioned). ... which is this. > my two concerns is that this: > > $ git clone ... > $ git checkout -b topic origin/master > $ hack hack hack > $ git push > > will try to implicitly fast-forward merge your commits onto master. And the reason why it is surprising to the beginners is? Because "topic" and "master" (of "origin/master") are not the same name? If you strip default features out of fear that it may be surprising to the beginners, you would end up telling them to always explicitly say what they want to push and to where, so we would need to draw a line somewhere. I tend to think that this is on the "understandable" side of the line (after all, I said "Let's start a topic to be merged to origin/master" when I started the topic, and I've been rebasing the topic up to date from time to time), but obviously you don't think so. And I think your aversion to the "implicit fast-forward" will lead you to teach beginners to do this instead: $ git clone ... $ git checkout -b topic origin/master $ hack hack hack $ git checkout master $ git merge topic $ eyeball, test, think $ git push which arguably is a more disciplined way, but I do not know if we can expect that people can be trained to be _that_ well disciplined. > Has somebody volunteered to make the necessary fixes to "push.default = > upstream" in the first place? At the very least we need the fixes you > mentioned in your mail[2] before it can become the default. So maybe > doing those is a good first step (of course we are in release freeze, > and it would be nice to settle this before v1.7.10 ships, so maybe there > is not time). If we were to take "upstream", as long as we commit to make it ready by the time we switch, I do not see it as much of an issue. Of course, the "will change to 'upstream'" message may need to be rephrased to say that the idiotic usages that would trigger bugs in the current "upstream" implementation I listed in the message you are referring to (which were actually taken from your earlier message, IIRC) are not supported and currently give undefined results, but will be fixed by the time we actually do the switch. > [1] http://article.gmane.org/gmane.comp.version-control.git/194299 > > [2] http://article.gmane.org/gmane.comp.version-control.git/194295 -- 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