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 06:28:10 GMT
*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.

There are several strategies for collaboration even in this scenario,
but all of them only caters for "known" collaborators; in a small
group of people you can decide to work git-only on a branch that
*stays* anchored at a specific svn version for the scope of the
collaboration. Or you can have one person in the group run git rerere 
and have her do all the update-merges from svn trunk (but still stay on
a separate branch for the scope of the collaboration). This person
(and only her!) should be able to do a rebase & squash at the end of the
collaboration effort and commit back to svn. 

Most people are aware that git creates SHA1 hashes for each commit.
But git also creates SHA1 hashes of the *diff content* used in diff
based operations such as rebase, which means that you can actually
safely move an unmodified diff around in history and expect other users
to be able to recover from it (at least strong git users;). This is the
reason squashing is even more frowned upon, when you squash you also
change the SHA1 of the diff, meaning it becomes much harder
(impossible?) to follow rebases. But still, we squash when committing 
to svn.

But given the way we tag our svn commits with jira references, 
it's generally possible for an informed git-svn user to understand
the rebases/squashes going on. But it's definitely not for the
git beginners and IMO it's a bit of a half-perverted git workflow that
makes git look bad.

But these are the constraints of working with svn-backed git and I have
no indication they will go away. The only real "solution" to this 
problem is ditching svn as backing store, something I truely hope
will be done in due time, but I suppose that's a different discussion.
Github does a good git-backed svn ;)


View raw message