Bill Lear wrote:
quoted text
> 
> What's wrong with 'git init --mirror git://host/repo'?

It wouldn't match other --mirror options. You would want it to set up
refs/remotes namespace for you, but the other --mirror options (those
in push/fetch) are meant to explicitly ignore refs/remotes and make
sure branches are named exactly the same on both sides (hence --mirror).

I wouldn't mind if it was given some other option that did what you
wanted, but having --mirror mean two such very different things would
be bad.

"git init --remote origin=git://host/repo", where the lhs of the equal
sign would default to "origin" might be a good way to implement it.

Personally I don't have any problems with the current way of getting
things done, so it's not my itch.

quoted text
> 
>> (I actually think that it is another example of cvs/svn damage, where you 
>> _need_ to clone first, or otherwise you will _never_ be able to commit 
>> to the repository.)
> 
> I think there is a tendency here to blame every shortcoming of git on
> someone else's supposedly unsanitary past rather than facing up to
> inherent problems in git itself.  We have several very senior, very
> dedicated software developers who LOVE git, and who loathe CVS, but
> who nevertheless find many vexing issues in git.
> 

git is not perfect. It's just better than everything else. Bringing up
those vexing issues here is one way of making it better though, so thanks
for doing that. :)

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html