Mailing-List: contact infrastructure-dev-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: infrastructure-dev@apache.org
Received-SPF: pass (nike.apache.org: domain of kristian.rosenvold@gmail.com
 designates 209.85.215.178 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=subject:from:to:in-reply-to:references:content-type:date:message-id
         :mime-version:x-mailer:content-transfer-encoding;
        b=NJd8KHNgy7WUODPK0p2ypfCLb1rSWsoa69yT6iL+t6ldFeODBbBLDT63Gf1cAK3gzn
         B8vXJTSpfjPiutuvsI3HSMS90fQ4Pu+9GZoPJ73ywZRZn1vWt2e8KOxTVNAS8LzqmDf5
         lyYr0/v3VQZTIEVj/j69igPckmuVQRU/jNwuU=
Subject: Re: Current use of GitHub
From: Kristian Rosenvold <kristian.rosenvold@gmail.com>
To: infrastructure-dev@apache.org
In-Reply-To: <910485F1-B4F2-45DA-A07D-0D2857A01447@yahoo.com>
References: <02f801cbf1ca$ad4b9290$07e2b7b0$@16degrees.com.au>
	 <80EF617B-462D-4A57-AB56-C55472952486@gmail.com>
	 <63228BD0-C74B-478B-ADD1-30C3D20933D2@yahoo.com>
	 <BANLkTiksZtTOQn3O53bkGGmxkhC+OXv4kA@mail.gmail.com>
	 <E5224E54-9714-4884-9C3F-5EDF21BFBDA7@yahoo.com>
	 <BANLkTim9vq_3Z_pau6d5h8g11VvpuLL7-w@mail.gmail.com>
	 <910485F1-B4F2-45DA-A07D-0D2857A01447@yahoo.com>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 05 Apr 2011 08:28:10 +0200
Message-ID: <1301984890.5485.34.camel@chunky>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

*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 ;)

Kristian