Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes:
> Junio C Hamano <gitster@xxxxxxxxx> 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
--
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