Re: [PATCH 0/7] limit the usage of the default remote "origin" to the minimum

From: Paolo Bonzini <bonzini@gnu.org>
Date: Apr 30, 2008, 05:24 UTC
Message-ID: <48180270.9080708@gnu.org>
In-Reply-To: <20080429231201.GA22646@sigill.intra.peff.net>

Show 15 quoted lines

>>> ... The principle of "remove defaults from code, and
>>> put them into the automatically generated config file" makes sense to
>>> me. It gives users an easy place to look to understand and change such
>>> behavior. So even without the rest of the patches, I think this is an
>>> improvement.
>> If the removal of defaults do not break expectations of users of an
>> existing repository, I'd agree.  Is it the case, or the lack of default
>> that is supposed to be there now suddenly makes the tool do unexpected
>> things?
> 
> I think in the case of patches 1 and 2 (but without the later patches)
> it becomes redundant. And of course, Paolo's idea is that it opens us up
> to changing the default later, in which case it will cease to be
> redundant. But I think even in the meantime that it gives the user
> a clue when looking in the config file about what can be tweaked.

Agreed. Patches 1 and 2 can definitely go in earlier and can help in the transition (see later).

> Didn't we already have this discussion and don't we already have a way to
> define a remote that you can use to push to more than one places?

No, because you may want to push to some places, and mirror to others. Unfortunately, mirroring is not handled entirely within match_refs but is also special-cased in builtin-send-pack.c. So you cannot handle it with a magic refspec (like --force), and you are forced to use a separate remote, independent of remote.*.mirror.

Show 9 quoted lines

>>> ... I
>>> assume people still with ancient .git/remotes files? Are those actually
>>> deprecated?
>>
>> Neither .git/branches.  When you interact with hundreds of remote
>> repositories, one interesting branch per each, like akpm does, the format
>> of one-file-per-remote is far easier and simpler to work with.
> 
> Then in that case, I think the warning is definitely bogus.

When you use .git/remotes and .git/branches, do you actually use them with the zero-argument versions of "git pull" (and "git fetch")? I'm not sure about that, actually I very much doubt so.

So here is my plan.

1) Merge patches 1 and 2 now.

2) Add a warning to "git push" if it pushes to something without a push 
refspec.  Merge patch 3, the doc can say that --push suppresses this 
warning.  Make sure the warning suggests how to silence it.

3) Merge patch 5 as it is just a cleanup.

4) Merge patch 6.

5) Add a similar warning to "git fetch".

6) Add a warning when "git push" is used with zero-arguments and there 
is more than one remote with a push refspec.  Something like, "git push 
will only push to ***.  This may not be what you want, and it may change 
in future versions of git".

7) If there is a revolt against the warning in (5), revert it and add a 
warning whenever the "magic origin" behavior is triggered by "git push".

For 1.6.0, the remaining changes would be harder to warn about preventively, so this part can be refined:

8) In "git pull", turn the warning into an error.

9) Ditto for "git fetch".

10) Ditto for "git push" if we had to go for (7).  If we didn't, merge 
patch 4 for 1.6.0.  Put a prominent note in the release notes that "git 
push" will push to all remotes with a push refspec.  By now, users will 
have added push refspecs appropriately thanks to the warning in step 2 
above; so at least "git push" will not stop pushing to origin.

In the meanwhile, decide what is the best thing to do for patch 7. If we decide it is to go in, steps 5 and 9 will have to be replaced with something else (I don't know what).

Paolo