Community
Participate
Working Groups
It would be nice if Jgit would support recursive merge, so that rename detection and multiple common parents works correctly. For reference see the thread: http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg01384.html It would also fix the rename problem for the Gerrit diff view: http://groups.google.com/group/repo-discuss/browse_thread/thread/1e5f5c1ae63d7b22
yesyesyes - this is definitely a must have!
Actually multiple common parents (criss-cross merging) is not really required for 359951 and the Gerrit issue. While Git doesn't provide rename detection for the resolve strategy, I can't see why JGit couldn't add rename detection to the resolve strategy. Thus rename detection and recursive merge could be implemented independent and to reflect this, I changed the summary of this bug.
hehe, i had this thought too, and actually had a look at the resolve merger, but it was a little too complex for me to easily spot the locations to add rename detection to...
Reursive merge is tracked as 380314 *** This bug has been marked as a duplicate of bug 380314 ***
I disagree this is a duplicate. The other bug doesn't track rename. And as far as I understand the current suggested patch adds the recursive strategy without adding rename detection. Thus after 380314 is resolved, this bug will still be unresolved.
*** Bug 407872 has been marked as a duplicate of this bug. ***
*** Bug 359951 has been marked as a duplicate of this bug. ***
Also bumped into this bug on a Linux client. I voted for it.
Any progress with this?
I am interested in adding rename detection to ResolveMerger or a subclass thereof. We could at least implement a restricted case of rename/modify conflict. Currently this case appears as an unconflicted add and a delete that conflicts with the other side's modify. Enumerating all the cases and which we should resolve is a worthwhile exercise.
(In reply to David Michael Barr from comment #10) > I am interested in adding rename detection to ResolveMerger or a subclass > thereof. We could at least implement a restricted case of rename/modify > conflict. Currently this case appears as an unconflicted add and a delete > that conflicts with the other side's modify. Enumerating all the cases and > which we should resolve is a worthwhile exercise. Yes, please. Many would welcome this. You can simply try to include rename detection to merge and see how good it is. I think it's likely to be roughly as good as the rename dection is, just by adding it. It's likely we'll see opportunities for improvment in rename detection, but that another issue than adding rename detection to merge. The TDD way (it's not dead btw) would be to start by craft failing tests for some simple examples and we'll merge your solution when it's useful.
So, I shelved this for the past 2 years to focus on bringing up build infrastructure for my team. Merge work is off the critical path, so it is still important but not urgent. Such is the life of many OSS contributors. I have a prototype that sits atop ResolveMerger without modifying any JGit internals. It queues up adds and delete-modify conflicts during processEntry(). It adds an extra pass onto mergeTreeWalk() that tries to match conflicts to adds using a locality sensitive hash of the blobs. That is good enough for my use but integration with RenameDetector would be suitable for general use. I attempted to create some minimal tests using property-based testing with moderate success. That process revealed far more corner cases that I was prepared to cover. Ironically, given my interest in SCM, that work was victim to data loss. Anyhow, I'm coming back around to this and am wondering whether anyone else is actively working on it?
Any update on this? This appears to cause some issues still.
(In reply to Rikard Almgren from comment #13) > Any update on this? > > This appears to cause some issues still. Can you provide a little more information on /what/ are the actual problems? We've been using JGit for years to perform (not too-complex) merges and did not have any apparent problems except for the "poor" handling of modify/delete conflicts in the IDE on large repos.
I would be particularly interested in the rename detection. If a commit renames a file and does some minor changes to it, e.g. gitk is able to detect the rename while Jgit is not.
(In reply to Markus Duft from comment #14) > (In reply to Rikard Almgren from comment #13) > > Any update on this? > > > > This appears to cause some issues still. > > Can you provide a little more information on /what/ are the actual problems? > We've been using JGit for years to perform (not too-complex) merges and did > not have any apparent problems except for the "poor" handling of > modify/delete conflicts in the IDE on large repos. The issues we have come from Gerrit, and Gerrit's implementation of JGit, but it seems to stem from this. If you have two changes that modify the same set of files, For example, change 262969 modifies a bunch of files in folder/subfolder, including a/b/thisisaspecificfile_5.4.3.bb. Change 265305 renames that file to thisisaspecificfile_5.4.4.bb, but Gerrit(using JGit) isn't able to resolve the conflict when change 262969 has been submitted and 265305 needs to be rebased. If you download the latter change locally and rebase it with cgit no manual action is necessary.
Did you set "Allow content merges" on this project in Gerrit ?
(In reply to Matthias Sohn from comment #17) > Did you set "Allow content merges" on this project in Gerrit ? Yes.
I have started to implement this. I use merge-recursive.c from the original git implementation as a reference.
I would recommend to also write unit tests and upload them early. In my experience when discussing/reviewing complicated merge issues one can spent a lot of time describing what he wants to achieve and it's sometimes hard to understand for reviewers/testers to understand the situation. So I would recommend to also have a look at jgit's MergerTest class and see how relatively easy it is to setup merge test situations and check the results afterwards. (ok, ok, 'relatively easy' leaves room for interpretation :-)) Do you have already such kind of tests? Need help?
