Re: [RFC PATCH] push: start warning upcoming default change for push.default

Holger Hellmuth [off-list ref] writes:

On 13.03.2012 14:17, Junio C Hamano wrote:

quoted

that is required to understand it is greater.  Also the current
implementation of 'upstream' has some weird semantics (or undesigned
bugs) pointed out by Peff, which would make it even more confusing.

If Peff's "push to same branch in a different remote" is a bug (and
IMHO it is) it should not count as a reason for what should be the
default.

I may phrased it poorly, but I don't think you mean "if the bug is fixed,
then the behaviour of upstream is simple and easy to understand".  The
very reason the bug exists in the first place is that the semantics that
mode wants to give its users is complex enough that even the people who
should know (i.e. those who implement it) overlooked that there is a
corner case their implementation was not handling. It is a demonstration
that upstream is not an easy-to-understand choice to throw at new people.

By the way, the documentation is very confusing in its description
what git push without parameters does. For example it is not really
explained in the description or options part, the only explanation is
in the Examples. There "git push" points to "git push origin" and:
-------------
"git push origin
           Without additional configuration, works like git push origin :.

           The default behavior of this command when no <refspec> is
given can be configured by setting the push option of the
           remote.
------------

Now the refspec documentation never says anything about what '.' means
(the only docu about refspecs I could find is in pull-fetch-param.txt

That should read:

	... works like "git push origin :".

That dot you see after the colon is a full-stop for the sentence, not a
part of any refspec.

Is this patchworthy (in that case I'll try to make one) or did I just
not read at the right places?

It is patch-worthy; you already know that it made you waste time looking
for ':.'---the documentation shouldn't have done that.

On 13.03.2012 18:41, Junio C Hamano wrote:

Holger Hellmuth[off-list ref]  writes:

quoted

If Peff's "push to same branch in a different remote" is a bug (and
IMHO it is) it should not count as a reason for what should be the
default.

I may phrased it poorly, but I don't think you mean "if the bug is fixed,
then the behaviour of upstream is simple and easy to understand".  The

I think the behaviour of the whole pull/push system is not easy to 
understand. One has to learn a lot of concepts about git before being 
able to answer the simple question "if I do 'git push' now, what happens?".

Since I am using git without any collaboration I never had much need to 
play around with the whole porcelain remote configuration (cloning and 
using git config was enough). So today I tried to create a bidirectional 
link between a local and a remote branch using only porcelain commands 
(i.e. without using git config directly). Somehow I didn't succeed. I 
can either use git checkout --track or git push -u to make a pull 
connection between the two, but to automatically push I would have to 
create a branch of the same name (and know that this is the magical 
ingredient that makes it work!)

Maybe what is missing is a parameter to git-push that tells git that 
from now on this is what git push should do per default in this branch 
(Similar to what git checkout --track does). This would mean that even 
new users could do most remote configuration with just the knowledge of 
git checkout and git push.

By the way I think I found another "hole" in the porcelain: If you add a 
single branch to follow with git remote add -t <branch> ..., you can't 
add another. A second git remote add -t <otherbranch> ... will be met 
with an error that the remote is already configured. I would have to 
delete the remote and add it again with git add -t <branch> -t 
<otherbranch> ..... Or use a different remote name (which would be 
confusing later on). Did I miss something?