SVN vs. git, status update

[Felipe Balbi]

On Tue, 11 Mar 2008 04:53:30 -0300, Werner Almesberger
<werner at openmoko.org> wrote:
> A while ago, Andy and I had some discussion about whether we should
> continue to use SVN and quilt or switch to git. SVN and quilt have
> served us well in the past, but they have their quirks, and git is
> nowadays considered the standard SCM for kernel development.
> 
> Back then, I suggested to postpone this discussion until we've sent
> GTA02 off to the factory, since it would be too risky to change
> repositories at a time when everyone is in release crunch.
> 
> Well, GTA02 isn't quite done yet (but coming along nicely - seems
> that we're fixing more bugs than finding new ones these days, which
> is very unusual for OpenMoko ;-), but we had the opportunity to
> discuss this issue face to face in Taipei in the last weeks.
> 
> The conclusions were these: there's little that speaks against using
> git as repository per se. In fact, it should be better than SVN in
> many regards.
> 
> The big unknown is how we can use git and still produce sequential
> patches, i.e., the sort that goes something like
> 
> [PATCH 0/2] OpenMoko foo, overview
> [PATCH 1/2] OpenMoko foo, platform code
> [PATCH 2/2] OpenMoko foo, GTA03-specific
> 
> We need this for upstream merging. In SVN+quilt, these patches are
> in fact what resides in the repository, but there's no trivial way
> to extract such patches from a git repository if we have overlapping
> changes.

Not that difficult, you just need to keep a branch with openmoko patches on
top
once in a while issue git rebase master on that branch

> 
> Since we couldn't find an immediate answer, we decided on the
> following course of action:
> 
> - for now, change nothing, i.e., we keep SVN+quilt and git in parallel
> 
> - once we're good for MP, I'll take a few weeks off. Matt has
>   volunteered to act as caretaker for the SVN+quilt repository during
>   my absence. (Thanks, Matt !)
> 
> - we keep on thinking about a good way to synthesize such patches from
>   a git repository, including any specific workflow this may need
> 
> - when I return, we migrate the current patches from SVN into git (in
>   applied form, of course, not as patch files)

that should be easy but the problem is setting correct commit messages,
from
Andy tree I can see a lot of wrong names, missing Signed-off-by and null
commit messages, that should be unacceptable after switching to git.

> 
> - from then on, we proceed with git, using a workflow that allows us
>   to synthesize patches as we need

Do we really need this ? I mean, we could format patches once in a while
and send to Russel King's review, after that, send to mainline for
integration.

> - around that time, we also start cleaning up patches and pushing
>   them upstream. Details of how we approach this are still under
>   discussion.

It's an arm architecture so a condensed diff, I mean diff -uRN
openmoko-tree/ linux-2.6-tree/,
should be sent to Russel King's patch review system.
It can be find here:
http://www.arm.linux.org.uk/developer/patches/

> I already have some ideas for how we can synthesize those patches.
> Andy, I think you'll like them :) Very light on the workflow. I'll
> write about them in a bit.

well, git rebase would be a way, the problem is that git rebase rewrites
git history
and if you wanna keep this patches published you have to delete remote
branch and git push
it again after git rebase.

If nobody wanna do this dirty job I could help integrating patches into a
clean git tree and
keeping it up to date with mainline.

We could start defining merge schedules, for now it could be every week or
when something really big
should be taken care of.

-- 
Best Regards,

Felipe Balbi
http://felipebalbi.com
me at felipebalbi.com