Re: push.default: current vs upstream

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

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Obviously the
>> former is much simpler to explain and understand, as people do not have to
>> learn upstream tracking before doing their first "push".
>
> Again, this is simple only for people who never run "git pull" without
> argument.

If you are running "git pull" with what to pull and integrate, you know
system much better than those who only use the canned "git pull without
argument" settings, so customizing push.default should be easier for you
than the real beginners whom we try to avoid confusing with the built-in
default, no?

Before saying "again", perhaps we should read and think about what the
other side said.  I think [*1*] raises a good point.

> For the others, they already have to learn about the "upstream"
> semantics.

But the others have graduated from CVS/SVN mentality.  Also, "upstream"
needs to be carefully chosen; I suspect that it is not as trivial for the
beginners to wrap their mind around it as you seem to be implying.

After a "git clone", you may want to work on whatever you are doing on
your topic branch, and then share it with your collaborator and polish it
to be suitable for the master, you may want to do this:

    git checkout -b topic ; work work work
    git push origin topic

But if your work on topic is ready to be published for everybody, you may 
just do this:

    git checkout -b topic ; work work work
    git push origin master

The upstream of topic for the former case would be origin/topic while for
the latter case it would be origin/master.

I and you know that.  But is the rest of the user experience set up to
easily arrange this automatically?  With branch.autosetupmerge, I suspect
that the above can be generalized to:

	git push origin master:topic ;# create the shared starting point
	git checkout -b topic origin/topic ;# and fork it

        repeat the three steps below 0 or more times
          work work work
          git push ;# goes to @{u} that is origin/topic
          git pull ;# takes work by collaborators from @{u}

	git push origin HEAD:master ;# topic is fully cooked, ready for master

and everything *should* go smoothly when @{u} is set up correctly.  At
least, that was the plan for @{u} mechanism.

The last step that pushes "git push origin HEAD:master" *might* be simpler
to explain if it were done this way:

	git checkout master
        git pull ;# syncs to the origin/master
        git merge topic
        git push

Also see Peff's 194414 in the same thread.

[References]

*1* http://thread.gmane.org/gmane.comp.version-control.git/194175/focus=194470