On Fri, Mar 30, 2012 at 2:01 PM, Jeff King <peff@xxxxxxxx> wrote: > On Fri, Mar 30, 2012 at 01:25:03PM -0700, Junio C Hamano wrote: >> > 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. I'd like to offer my strong agreement as somebody who has just led his team through a transition from svn to git. Branch names are really important to people. If they've decided to branch "origin/master" as something that's not called "master", there's a really good chance that they mean it to be a new branch. I think it's also really important to consider the consequences of getting it wrong under either scenario. If a user does some work on his new "features/frobnitz" branch and does a "git push" only to find that his work has been committed to the company's master branch he will be confused, frustrated, and publicly embarrassed. He then has to apologize and figure out how to revert the changes. I really don't see any scenario where that user ends up saying "oh yeah, I guess git was right and I was wrong." Compare that outcome to somebody who expects upstream behavior and gets current. That person pushes "features/frobnitz" expecting to see his changes appear on "origin/master", only to find that they didn't. Instead there's a new branch "origin/features/frobnitz". Maybe it's not what he expected but it's easy enough to understand. He hasn't inconvenienced anybody else, so there's no need for apology. He just takes a look at the docs and figures out how to accomplish what he intended and deletes the branch he accidentally created. It's this public vs. private embarrassment factor that motivated me to recommend "current" as our company policy and most strongly convinces me that "current" is the right default. Cheers, -Nathan -- http://n8gray.org -- 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