... 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.
... 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
--
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
