On Oct 21, 2019, at 3:30 AM, Segher Boessenkool <seg...@kernel.crashing.org> 
wrote:
> 
> On Sun, Oct 20, 2019 at 06:06:30PM +0200, Gerald Pfeifer wrote:
>> On Wed, 9 Oct 2019, js...@gcc.gnu.org wrote:
>>> +<li>Use "<code>git commit</code>" and "<code>git push origin
>>> +master</code>" to check in the patch.</li>
>> 
>> I will admit I made a couple of first commits without reading those
>> details and just used a plain "git push".  
>> 
>> Is there any problem with that, any drawback?
>> 
>> Or could we simplify those instructions?
> 
> Neither command works in all cases

This isn't helpful.  The advanced person already knows this and the limitations 
of it, and the non-advanced people are confused by the lack of certainty.  So, 
the web page should not say it, and saying it here, doesn't help much as well.  
Trying to have a git tutorial that covers all the bases in two lines, isn't 
useful either.  So, to that end, the documentation should only list git commit, 
git push, alone.  All other complexity, should rely upon the mountains of git 
tutorials and git books that can cover the details.  The simple commands always 
work for the simple cases.  The people that are not simple, unfortunately have 
that hard up-hill climb that is git, and nothing we can do in this manual can 
change that.

> , and both work in the simpler cases.
> 
> "git push" will push what you have configured to push for the current branch
> you are on.  If you are on your local "master", and you have followed the
> simple instructions above, that will probably push your local "master" to
> the "master" on your remote "origin" (that is, "git push origin 
> master:master").
> 
> "git push origin master" makes it explicit what remote you want to push to,
> and what local branch you want to push, but not the remote branch you want
> to push to.
> 
> "git push" is slightly more dangerous, but git will prevent you from doing
> most dangerous things, so that's alright.  The instructions as-is are a good
> habit to get into, and for more advanced things you *do* need to name your
> remote and branches; you'll have to learn them some time, why not now.

Cause, the gcc doc cannot do a good job explaining them.  And, if it tried, it 
would be wrong.  So, only list the simple things that work in the simple cases, 
and defer everyone else to more advanced documentation that we don't provide.  
If you want to cookbook it with gcc specific things, do that in the wiki, if 
you want, please, not the gcc doc.

Reply via email to