On Fri, Mar 30, 2012 at 01:25:03PM -0700, Junio C Hamano wrote: > 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". Right. I also think either is a huge improvement for new users over "matching". But since we are going through the pain of changing the default, I think it's worth nit-picking between the options to come up with the best default. > > 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. I guess part of me is just cynical. We are announcing "the default will change to upstream" under the assumption that upstream will get polished to everyone's liking. But until that polishing is actually done, I am pessimistic. :) > > 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? Sort of. It is more because "upstream" is an overloaded concept. Perhaps you created the branch from origin/master because you wanted to say "this is where my topic is based, and when I 'rebase -i' later, I want it to be considered the baseline". Or perhaps you meant to say "I am going to work on origin's master branch, but I would prefer to call it 'topic' here". In the latter case, pushing back to origin/master makes sense. They are forks of the same branch to you, and pushing back is how you will share your changes to master. But in the former case, you may or may not consider them the same branch, and you may be pushing simply to share your work-in-progress of the topic. Putting that work onto "master" would be confusing in that case. Note that "current" has the same assumption in reverse. If you create a local "master" branch (whether or not it is based on a remote "origin/master"), you may or may not mean them to be the same branch. So we have to decide when two things are forks of "the same branch", and when it is merely "X is based on Y", or "X happens to have the same name as Y". And I think the "name is the same" semantics are way more obvious. Do you recall discussions a few years back about git's branching model versus that of mercurial and other systems? One of the confusing things for people new to git was the idea that git fundamentally doesn't care about "what is a branch". They got confused that "master" in the local repository really had no connection to "master" on the remote repository (whereas in hg, I think there is some magic in the DAG that connects them). But that leads me to think that people really do consider "same name is the same branch", which means "current" is going to be a lot less likely to confuse people (for that matter, look at the current matching semantics, which use name mapping; people get confused that we are pushing all matching branches, but I don't remember anyone ever complaining that they expect "foo" to go to "bar"). > 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. Is that what you said? Or did you say "I am starting a new topic that will be based on origin/master?" I feel like the concept of "upstream" is very loosely specified, and can mean many things. And even if you do eventually expect it to be merged into master, it does not mean you expect it to do so by default during "git push". You might also simply want to push the current state of your topic. > 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. Sure, I think that is a better workflow. But I don't expect everyone to follow it, and I don't think "upstream" is wrong to behave the other way. You could also teach them what "upstream" means, and have them set push.default to it. Ultimately, it is not about whether one workflow is better than the other. It is about having a default that stops the user and says "hey, I don't know what workflow you're using. So you need to tell me before I can continue." -Peff -- 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