Re: push.default: current vs upstream

[Nathan Gray <n8gray@n8gray.org>]

On Fri, Mar 30, 2012 at 2:01 PM, Jeff King <peff@peff.net> 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