Re: [Qemu-devel] [6721] Refactor keymap code to avoid duplication ("Daniel P.

[Johannes Schindelin]

Hi,

On Fri, 6 Mar 2009, Anthony Liguori wrote:

> Johannes Schindelin wrote:
> > > The new file keymaps.h is missing.
> > >     
> >
> > Anthony, as you seem to use Git from time to time, you might be 
> > interested in using git-svn, to overcome such omissions.
> 
> guilt failed me here.
> 
> I have scripts that pull patches from the mailing list (basically, 
> git-am but a lot more forgiving) and converts that to a series of 
> patches for guilt.  I think use the guilt tree on top of a git tree 
> which I use to automatically build/test each patch in a series.  After 
> this, I think do more exhaustive testing of the whole series applied.
> 
> I think have another script that will apply the whole series to SVN.  
> It's smart enough to read the patch files to determine what files have 
> been added/removed and issue the appropriate svn add/rm command.  
> Basically, this is an svn-import command.
> 
> With this particular series, it didn't apply to trunk anymore so I did 
> some fixups.  Unfortunately, guilt has a long standing bug where it can 
> sometimes lose track of files introduced by a patch.  This happened so I 
> had to manually git add && guilt refresh to add the files back to the 
> patch.  The curious thing is that somehow, in the process of this, 
> instead of having diff /dev/null b/foo.h, it did diff a/foo.h b/foo.h 
> and treated foo.h as an empty file.  This means that my svn-import 
> script didn't catch it as an added file. I've fixed this by adding an 
> svn status check to ensure no stray files are around.
> 
> What I'd really like to do, is switch over to just using git-am and then 
> push the patches to a git tree.  But I jump through all of the above 
> hoops to accommodate people that send patches that aren't git-am 
> friendly (which is the majority today) and to morph command messages 
> into the format that QEMU has traditionally used.

What exactly is failing?  Are the patches not even applicable if you use 
"patch < .git/rebase-apply/patch" after a failed patch?

> One of the issues of converting over to git is that Savannah doesn't 
> really have a robust git hosting mechanism.  Each project can have one 
> tree.  I also am not sure that there's a reasonable mechanism to do 
> commit hooks to enable mailing list messages.  Savannah also requires 
> that the main code repository be hosted in Savannah so it wouldn't be an 
> option to continue using Savannah services but host the git tree 
> somewhere else.

I do not see the problem.  Why not just push to Savannah's Git repository?  
Of course, Git being distributed, you can push to an arbitrary number of 
public repositories whenever you feel like it.

BTW thanks for the creation of the stable branch.  Maybe I find time later 
this week to find out if WinXP64 guests are still broken or not.

Ciao,
Dscho