Daniel Berlin wrote:
Well, no.
We will never use git exclusively as long as it requires as many
workflow changes for people as it currently does. This is not me
speaking for the gcc community, this is me telling it like it is based
on experience moving us to svn.
lol! Maybe you should ask the Xorg maintainers how much "pain"
it was dropping a centralized scm for a distributed one.
My personal experience of migrating from svn to git, for what
is worth, is 100% positive: I can't think of even one use case
that got worse.
But here we weren't (yet) talking of migrating to git. We were
just going to serve many GCC developers with a better tool
alongside the official one.
Even simple things, like having to do git diff -rHEAD instead of git
diff to see added files, etc.
LOL! You can't be serious: why would *compiler* *developers*
be unable to grasp a few command line syntax changes such as
these? Aren't you underestimating your users perhaps?
Again, ask the Xorg developers. IIRC, all they did was writing
a quick cheatsheet to map cvs commands to their git equivalents.
Regardless of how fast it is, until the UI is something people don't
have to think about to work with, it's not going to fly.
Sad but true.
You have never used git recently, have you?
The easy things are as easy as svn/cvs (just different sometimes).
The hard things (new repo, merging, branching) are fundamentally
easier. And the totally crazy things become possible.
If someone on overseers wants to set up a gcc git mirror, that is fine
(fche may do it for you, in fact). However, we don't (for various
reasons, some technical, some political), allow offsite things to be
considered official parts of our infrastructure.
Thus, I am opposed to adding a link to git.infradead.org, but not
opposed to a link to a git repo on gcc.gnu.org.
Fair enough. I hereby volunteer to setup and maintain the git
mirror on gcc.gnu.org if someone provides me a shell account
there.
Should be quite useful. A post commit hook, does not slow down svn
commit operations, right?
Sadly, it does in most cases (which is why i don't have an hgpullsvn
hook in post-commit) due to the requirement that it trap errors and
output.
I bet pushing a changeset to git is not going to add
noticeable delay.
I'm not sure it matters if the repo is 15 minutes behind for any real
work, however, and if a repo was put on gcc.gnu.org, ther ewould be no
problem having a cron job that syncs it
Yeah, it's absolutely not bothering me.
If we host it on gcc.gnu.org, it would be interesting to let
people with ssh keys just commit to git to get the changeset
automatically pushed back to svn. This is a documented
feature of "git svn", although I never tested it myself.
--
\___/
|___| Bernardo Innocenti - http://www.codewiz.org/
\___\ One Laptop Per Child - http://www.laptop.org/
