www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Rosenvold <kristian.rosenv...@gmail.com>
Subject Re: Current use of GitHub
Date Tue, 05 Apr 2011 09:19:25 GMT
ti., 05.04.2011 kl. 10.08 +0200, skrev Jukka Zitting:
> Hi,
> On Tue, Apr 5, 2011 at 8:28 AM, Kristian Rosenvold
> <kristian.rosenvold@gmail.com> wrote:
> > *All* git-svn based workflows involve rebasing (rewriting history). By
> > standard git wisdom that makes your workflow single-user unless you have
> > quite advanced git users.
> I any case I would recommend git-svn users to use the svn repository
> for collaboration. If you have a commit that can be shared, just do a
> git svn dcommit and everyone is happy ..

As long as we're svn-backed, that should certainly be the official
recommendation. This does not mean that's how things happen in real
life ;)

I frequently use git/github to collaborate with myself at different
computers, so I push/rebase/reset when I move from my laptop to my home
office to my office. Sometimes code can be in shambles, not even
compiling (I can switch dev computers in 30 seconds in this manner). Git
users simply end up using their servers for far more use-cases than svn
users, and I wouldn't dream of dcommitting anything that doesn't even

And we already have several examples where asf committers choose to
collaborate in git/github branches only to dcommit when done. I'm not
sure it matters in this context, it just creates larger svn commits;
there may be other concerns about this.

I understand the original query as requesting insight into the current
usages of the mirrors, and there may be several reasons for that. From a
technical perspective I think the current integration is reasonably
state-of-the-art when it comes to git<->svn integration, which
unfortunately says a lot about the orthogonality of these two SCM's
(although I sometimes suspect there'd be ways to make git-svn better).
There may be some provenance issues that could be addressed wrt the git
forks; maybe something like crawling github looking for git-commits that
are children of "official" apache sha1's (and persist it somewhere)
could be an idea.

Even with all their limitations, the forks provide great value to git
users. The biggest shame is that you really need to be a *good* git user
to get a smooth experience, it's not much for git-beginners who really
should start their learning with "proper" git.


View raw message