Re: push.default: current vs upstream

[Junio C Hamano <gitster@pobox.com>]

[dragging Matthieu, an advocate for "upstream", into this]

Jeff King <peff@peff.net> 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