Ooo.  But I think that's the other way around.  It was prepared for that
purpose but people never followed through.  Check the archive around

Eh, in that sense, "git remote" itself is useless, isn't it?  I have to
say that this particular point of your argument does not give us any new
or interesting insight to work from.

As I already said, I think "push to backup" option would be useful.  It
just cannot take over --mirror option, which means something different.
--

[ message continues ]

Hi,


I think it is very much the other way round.  "git remote add" is meant 
for adding _additional_ remotes.  "git clone" just _happens_ to install an 
"origin" remote.

I even have a case where I used "--mirror" _twice_ in the same, _non_-bare 
repository.  It has merit, you know?

Ciao,
Dscho

--

[ message continues ]

Well, the thread is not very explicative.  Neither is the commit log 
message.  There is no info as to *why* it is useful.

After finding no particularly good info in the commit, and seeing that 
the functionality is unused within git's shell script porcelain, I wrote 
my RFC on the intuition that it is a failed experiment.  (The rest of 

Hm, bad sentence on my side.  My point was that my proposed improvements 
to clone:

   git clone --bare -o origin <url> foo.git

satisfy 99% of the usecase; you usually know beforehand if you're 
cloning for local development or for mirrors.   Anyone who *still* needs 
--mirror after that (i.e. needs two mirror-mode remotes, or needs it on 
non-bare repositories), 99% of the time knows how to hack the config. 
Actually in the latter case (non-bare repos) he might have to hack the 
config soon, if Dscho's patch to forbid this is polished and goes in.

In the end, this piece of functionality is almost unused (surely unused 
within git's shell porcelain, if not in the wild) and is dubiously 
placed for two reasons:

1) If the point of git remote is to shield from the config, what the 
user will learn is that "git remote" is about "git branch -r" (maybe 
he'll also learn "refs/remotes/something").  Now instead you have an 
option that goes under "git remote" just because it creates remote.* 
configuration options.  Indeed, "git remote add --mirror -f" will create 
*local* branches, so that "git branch -r" does not show them.

2) Similarly, "--mirror" suggests that the remote will go hand in hand 
with "git push" (that has the "--mirror" option, and this started my 
confusion) rather than "git fetch"/"git pull".  Indeed, even after my 
patch[1] to add some DWIM functionality for mirrors to "git push", the 
user will need to hack the config file manually to activate the DWIM.

Instead, my proposed meaning of "git remote add --mirror" would fix both 
discrepancies...

Paolo

[1] http://marc.info/?l=git&m=120877130932254&w=2
--

[ message continues ]