Bill Lear wrote:
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.
(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@xxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
