git-cherry like operation for SVN imports

git-cherry like operation for SVN imports

[Stephen Bash]

Hi all-

At my day job we've got about 17k commits in our Git repository (covering ~13 years) that were imported from Subversion.  Recently we've had a few regression issues come up that we thought were fixed in older (pre-Git) releases, and we're having a hard time pinning down if/when they got merged back to the mainline development branch.

In a pure Git world, I would use either git branch --contains or git-cherry...

Unfortunately during our SVN->Git process we didn't have SVN mergeinfo, so none of the Subversion merges were captured in Git (the diffs are correct, but the DAG is not).  So right away git {branch,tag} --contains is out the window (I think).  The next obvious choice is git-cherry, but (at least in our process) SVN merges are a single commit that roll up a series of diffs so the patch-id of the merge doesn't match the patch-id of the original commit (at least I haven't found a way to make this work).

One possible solution proposed by a coworker was do something like patch-id, but at the hunk level.  This has promise, but I'm not convinced that the hunks showing up in the merge commit would match those in the original (but I'm no expert when it comes to diff logic).

Does anyone have any experience with this type of problem?  Any suggestions on how we can make this work?

Thanks,
Stephen

Re: git-cherry like operation for SVN imports

[Michael J Gruber]

Stephen Bash venit, vidit, dixit 25.02.2011 16:43:
> Hi all-
> 
> At my day job we've got about 17k commits in our Git repository (covering ~13 years) that were imported from Subversion.  Recently we've had a few regression issues come up that we thought were fixed in older (pre-Git) releases, and we're having a hard time pinning down if/when they got merged back to the mainline development branch.
> 
> In a pure Git world, I would use either git branch --contains or git-cherry...
> 
> Unfortunately during our SVN->Git process we didn't have SVN mergeinfo, so none of the Subversion merges were captured in Git (the diffs are correct, but the DAG is not).  So right away git {branch,tag} --contains is out the window (I think).  The next obvious choice is git-cherry, but (at least in our process) SVN merges are a single commit that roll up a series of diffs so the patch-id of the merge doesn't match the patch-id of the original commit (at least I haven't found a way to make this work).
> 
> One possible solution proposed by a coworker was do something like patch-id, but at the hunk level.  This has promise, but I'm not convinced that the hunks showing up in the merge commit would match those in the original (but I'm no expert when it comes to diff logic).
> 
> Does anyone have any experience with this type of problem?  Any suggestions on how we can make this work?

If your merges coalesce several commits you're out of luck with cherry.

I guess I would try to find a "signature hunk" (characteristic for fix
you're after) and try "log -S" with that. I mean, if anything else
fails, it's time for the pickaxe ;)

Michael