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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html