Anyone? Please? Even a code pointer into git-svn's mergeinfo handling would be a start... Avish On Thu, Mar 1, 2012 at 5:05 PM, Avishay Lavie <some.avish@xxxxxxxxx> wrote: > > Hello, > > I'm using git-svn from git 1.7.8.msysgit.0 with svn.pushmergeinfo set. > So far, it works beautifully and really closes the gap for developers > to be able to work with git-svn, including merging/reintegrating SVN > branches. > However, there seem to be a subtle bug in git-svn's behavior, where > the svn:mergeinfo property on a branch references commits from the > same branch, effectively saying "this branch was merged onto itself". > SVN then gets confused at this in subtle ways which ultimately cause > it to fail. > > The following workflow reproduces the issue: > > 1. Work on some branch (git checkout my-branch) > 2. Merge trunk into your branch (git merge trunk && git svn dcommit) > 3. Reintegrate the branch back to trunk (git checkout master && git > merge my-branch && git svn dcommit) > 4. Someone else reintegrates a different branch into trunk using a > regular SVN client (non-git). > 5. A third someone merges trunk into their branch using a regular SVN > client. > 6. That third someone now tries to merge trunk into their branch > again, using SVN. > > What we noticed happens is the following: > * Step #2 adds svn:mergeinfo on your branch to represent the commits > merged in from trunk (this is normal and desired). > * Step #3 copies these references from the svn:mergeinfo on the merged > branch back into the svn:mergeinfo property on trunk, so we end up > with trunk's mergeinfo referencing its own commits (this is the buggy > behavior -- when reintegrating with SVN, this part doesn't happen). > * In step #4, SVN detects the self-referencing mergeinfo property on > trunk and removes it, leaving only mergeinfo for the other branches > (this is also desirable behavior on SVN's part, since a branch > shouldn't include any mergeinfo references to itself). > * In step #5, SVN tries to apply the changes made on trunk to the > target branch, including the previous merge which removed some > mergeinfo references. This removes the same trunk commits from the > mergeinfo property on the target branch, leaving "holes" in mergeinfo > property for trunk on that branch. > * In step #6, SVN detects that the mergeinfo property for trunk on the > target branch has holes in it, and tries to merge those revisions from > trunk again. This causes tree conflicts and other noise which fails > the merge. > > As I see it, the bug here is the creation of self-referencing > mergeinfo properties in step #3; SVN doesn't exhibit this behavior and > this is what causes the problems later on. > I think a general solution is to never add an svn:mergeinfo line > referencing the branch being dcommitted into. > > Can anyone confirm this is indeed a bug, suggest a fix or workaround > and/or point me at the relevant code? > > Thank you, > > Avish -- 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