{"thread":{"id":"43141","subject":"using xdl_merge(), was Re: Resolving conflicts","startedAt":"2006-12-01T07:06:09Z","lastAt":"2006-12-06T10:47:25Z","messageCount":32,"participants":["Johannes Schindelin","Jakub Narebski","Wink Saville","Junio C Hamano","Linus Torvalds","Alan Chandler","Ramsay Jones"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"297740","messageId":"456FD461.4080002@saville.com","threadId":"43141","inReplyTo":null,"subject":"Resolving conflicts","fromName":"Wink Saville","fromEmail":"wink@saville.com","sentAt":"2006-12-01T07:06:09Z","receivedAt":"2006-12-01T07:06:09Z","isPatch":false,"sender":{"key":"wink@saville.com","avatar":"https://avatars.githubusercontent.com/u/1024284?v=4"},"body":"Sorry to be so ignorant, but I just updated to 2.6.19 using:\n\n   git-checkout master\n   git-pull\n\n   ...\n   sound/usb/usbaudio.c                          |    3\n   usr/Makefile                                  |    2\n   92 files changed, 888 insertions(+), 371 deletions(-)\n   create mode 100644 arch/mips/kernel/topology.c\n   create mode 100644 arch/um/os-Linux/execvp.c\n   create mode 100644 include/asm-arm/mach/udc_pxa2xx.h\n\nAll seemed to go I then moved back to my branch and pulled from master to my branch:\n\n   git-checkout ace\n   git-pull . master\n\nBut that failed:\n\n   Trying really trivial in-index merge...\n   fatal: Merge requires file-level merging\n   Nope.\n   Merging HEAD with 0215ffb08ce99e2bb59eca114a99499a4d06e704\n   Merging:\n   d7083db038fb98266e331a7f96198ec35a12367a A partial fix BUG 061124 (crashing when 1ms interrrupts).\n   0215ffb08ce99e2bb59eca114a99499a4d06e704 Linux 2.6.19\n   found 1 common ancestor(s):\n   1abbfb412b1610ec3a7ec0164108cee01191d9f5 [PATCH] x86_64: fix bad page state in process 'swapper'\n   Auto-merging kernel/fork.c\n   CONFLICT (content): Merge conflict in kernel/fork.c\n   Auto-merging kernel/spinlock.c\n   CONFLICT (content): Merge conflict in kernel/spinlock.c\n\n   Automatic merge failed; fix conflicts and then commit the result.\n\nI then searched the net for how to resolve conflicts, seems you\nshould start by doing a git-diff, so I did and I get this:\n\n   diff --cc kernel/fork.c\n   index d74b4a5,8cdd3e7..0000000\n   --- a/kernel/fork.c\n   +++ b/kernel/fork.c\n   diff --cc kernel/spinlock.c\n   index f4d1718,2c6c2bf..0000000\n   --- a/kernel/spinlock.c\n   +++ b/kernel/spinlock.c\n\nAnd git-status shows:\n\n   # On branch refs/heads/ace\n   #\n   # Updated but not checked in:\n   #   (will commit)\n   #\n   #       modified: Documentation/rtc.txt\n   #       modified: Makefile\n   #       modified: arch/arm/configs/assabet_defconfig\n   #       modified: arch/arm/configs/cerfcube_defconfig\n   ......\n   #       modified: sound/usb/usbaudio.c\n   #       modified: usr/Makefile\n   #\n   #\n   # Changed but not updated:\n   #   (use git-update-index to mark for commit)\n   #\n   #       unmerged: kernel/fork.c\n   #       modified: kernel/fork.c\n   #       unmerged: kernel/spinlock.c\n   #       modified: kernel/spinlock.c\n   #\n\nSo what have I done wrong?\nDid the pull complete and I just need to resolve this or\ndo I need to redo the git-pull?\n\nThanks,\n\nWink Saville\n"},{"id":"298534","messageId":"200612010730.25700.alan@chandlerfamily.org.uk","threadId":"43141","inReplyTo":"456FD461.4080002@saville.com","subject":"Re: Resolving conflicts","fromName":"Alan Chandler","fromEmail":"alan@chandlerfamily.org.uk","sentAt":"2006-12-01T07:30:25Z","receivedAt":"2006-12-01T07:30:25Z","isPatch":false,"sender":{"key":"alan@chandlerfamily.org.uk","avatar":"https://gravatar.com/avatar/1862247e5ea8eac114c842f9dc3a5db6253754e24ef7171757cf97eedce48b8c?d=mp&s=160"},"body":"On Friday 01 December 2006 07:06, Wink Saville wrote:\n...\n>    git-pull . master\n>\n> But that failed:\nI am not the worlds expert in this, but since most seem to be in bed I'll \nattempt to answer you\n\n...\n>    CONFLICT (content): Merge conflict in kernel/fork.c\n>    Auto-merging kernel/spinlock.c\n>    CONFLICT (content): Merge conflict in kernel/spinlock.c\n\nThese show that these two files had some conflicts in the contents from the \nkernel and your local branch\n...\n> And git-status shows:\n...\n>    # Changed but not updated:\n>    #   (use git-update-index to mark for commit)\n>    #\n>    #       unmerged: kernel/fork.c\n>    #       modified: kernel/fork.c\n>    #       unmerged: kernel/spinlock.c\n>    #       modified: kernel/spinlock.c\n>    #\n>\n> So what have I done wrong?\n\nNothing - its asking you to manually resolve the conflict.  \n\n> Did the pull complete and I just need to resolve this or\n> do I need to redo the git-pull?\n\nTake a look in these two files - you should see conflict markers of the form\n<<<<<<<<<<<<<<<< \nsome content\n================\nsome other content\n>>>>>>>>>>>>>>>>\n\nwhich is the contents that failed from your side and the new version of the \nkernel you pulled in.\n\nEdit so the files have sensible content\n\nthen use\n\ngit update-index <filename>\n\nto tell git that that particular conflict has been resolved.\n\n\nWhen you have done that for both files\n\njust do \n\ngit commit\n\n\n\n\n\n\n\n-- \nAlan Chandler\n"},{"id":"297593","messageId":"Pine.LNX.4.64.0611302330000.3695@woody.osdl.org","threadId":"43141","inReplyTo":"456FD461.4080002@saville.com","subject":"Re: Resolving conflicts","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-12-01T07:39:23Z","receivedAt":"2006-12-01T07:39:23Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 30 Nov 2006, Wink Saville wrote:\n> \n> I then searched the net for how to resolve conflicts, seems you\n> should start by doing a git-diff, so I did and I get this:\n> \n>   diff --cc kernel/fork.c\n>   index d74b4a5,8cdd3e7..0000000\n>   --- a/kernel/fork.c\n>   +++ b/kernel/fork.c\n>   diff --cc kernel/spinlock.c\n>   index f4d1718,2c6c2bf..0000000\n>   --- a/kernel/spinlock.c\n>   +++ b/kernel/spinlock.c\n\nHmm. That doesn't look like a conflict. If it had a real conflict, I'd \nhave expected to see it mentioned in that diff..\n\nThis may be a stupid question, but if you haven't actually ever needed to \ndo any file-level merges before, this may be the first time you've \nactually had the external 3-way \"merge\" program called, and that's one of \nthe few things that git still depends on _external_ programs for. And if \nthat program is broken or missing, you'd get bubkis.\n\n(This is hopefully getting fixed, and we'll have one less external \ndependency to worry about, but it's the only thing that springs to mind)\n\nThat's especially true since the merge-head your log shows wasn't even all \nthat long ago: there's just 80 commits since that common merge base, and \nonly two of them even change those two files, and only in rather simple \nways at that.\n\nSo my guess is that there wasn't actually a conflict at all, but the \n\"merge\" program (usually in /usr/bin/merge) returned an error for some \nreason. What does \"which merge\" and \"rpm -qf /usr/bin/merge\" say?\n\nBut you can also do \"git diff --ours\" (or \"git diff --their\") to get a \nsimple two-way diff of the end result of the merge to what you were \nlooking at.\n\n"},{"id":"295078","messageId":"456FDCB5.9040907@saville.com","threadId":"43141","inReplyTo":"200612010730.25700.alan@chandlerfamily.org.uk","subject":"Re: Resolving conflicts","fromName":"Wink Saville","fromEmail":"wink@saville.com","sentAt":"2006-12-01T07:41:41Z","receivedAt":"2006-12-01T07:41:41Z","isPatch":false,"sender":{"key":"wink@saville.com","avatar":"https://avatars.githubusercontent.com/u/1024284?v=4"},"body":"Alan Chandler wrote:\n> On Friday 01 December 2006 07:06, Wink Saville wrote:\n> \n> Take a look in these two files - you should see conflict markers of the form\n> <<<<<<<<<<<<<<<< \n> some content\n> ================\n> some other content\n> \n\nThat's what I thought but there isn't any \"<<<<<\" and git-diff also seems\nto indicate no differences:\n\nwink@winkc2d1:~/linux/linux-2.6$ git-diff kernel/fork.c\ndiff --cc kernel/fork.c\nindex d74b4a5,8cdd3e7..0000000\n--- a/kernel/fork.c\n+++ b/kernel/fork.c\nwink@winkc2d1:~/linux/linux-2.6$\n\n\nwink@winkc2d1:~/linux/linux-2.6$ git-diff kernel/spinlock.c\ndiff --cc kernel/spinlock.c\nindex f4d1718,2c6c2bf..0000000\n--- a/kernel/spinlock.c\n+++ b/kernel/spinlock.c\nwink@winkc2d1:~/linux/linux-2.6$\n\nThanks,\n\n"},{"id":"295356","messageId":"456FDF24.1070001@saville.com","threadId":"43141","inReplyTo":"Pine.LNX.4.64.0611302330000.3695@woody.osdl.org","subject":"Re: Resolving conflicts","fromName":"Wink Saville","fromEmail":"wink@saville.com","sentAt":"2006-12-01T07:52:04Z","receivedAt":"2006-12-01T07:52:04Z","isPatch":false,"sender":{"key":"wink@saville.com","avatar":"https://avatars.githubusercontent.com/u/1024284?v=4"},"body":"Linus Torvalds wrote:\n> \n> On Thu, 30 Nov 2006, Wink Saville wrote:\n>> I then searched the net for how to resolve conflicts, seems you\n>> should start by doing a git-diff, so I did and I get this:\n>>\n>>   diff --cc kernel/fork.c\n>>   index d74b4a5,8cdd3e7..0000000\n>>   --- a/kernel/fork.c\n>>   +++ b/kernel/fork.c\n>>   diff --cc kernel/spinlock.c\n>>   index f4d1718,2c6c2bf..0000000\n>>   --- a/kernel/spinlock.c\n>>   +++ b/kernel/spinlock.c\n> \n> Hmm. That doesn't look like a conflict. If it had a real conflict, I'd \n> have expected to see it mentioned in that diff..\n> \n> This may be a stupid question, but if you haven't actually ever needed to \n> do any file-level merges before, this may be the first time you've \n> actually had the external 3-way \"merge\" program called, and that's one of \n> the few things that git still depends on _external_ programs for. And if \n> that program is broken or missing, you'd get bubkis.\n> \n> (This is hopefully getting fixed, and we'll have one less external \n> dependency to worry about, but it's the only thing that springs to mind)\n> \n> That's especially true since the merge-head your log shows wasn't even all \n> that long ago: there's just 80 commits since that common merge base, and \n> only two of them even change those two files, and only in rather simple \n> ways at that.\n> \n> So my guess is that there wasn't actually a conflict at all, but the \n> \"merge\" program (usually in /usr/bin/merge) returned an error for some \n> reason. What does \"which merge\" and \"rpm -qf /usr/bin/merge\" say?\n> \n> But you can also do \"git diff --ours\" (or \"git diff --their\") to get a \n> simple two-way diff of the end result of the merge to what you were \n> looking at.\n> \n> \t\tLinus\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n> \n\nEarlier had a problem with git wanting merge but didn't have it and\ncouldn't figure out which package it was in Ubuntu:( So I symlinked merge\nto kdiff3 which worked at the time:\n\nwink@winkc2d1:~/linux/linux-2.6$ ls -al /usr/bin/merge\nlrwxrwxrwx 1 root root 6 2006-11-17 19:24 /usr/bin/merge -> kdiff3\n\nBut doesn't/didn't work this time.\n\nI tried \"git diff --ours\"\n\nwink@winkc2d1:~/linux/linux-2.6$ git diff --ours\n* Unmerged path kernel/fork.c\ndiff --git a/kernel/fork.c b/kernel/fork.c\n* Unmerged path kernel/spinlock.c\ndiff --git a/kernel/spinlock.c b/kernel/spinlock.c\nwink@winkc2d1:~/linux/linux-2.6$\n\nWink\n\nNot too helpful:(\n"},{"id":"297586","messageId":"Pine.LNX.4.64.0611302348370.3695@woody.osdl.org","threadId":"43141","inReplyTo":"Pine.LNX.4.64.0611302330000.3695@woody.osdl.org","subject":"Re: Resolving conflicts","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-12-01T07:53:21Z","receivedAt":"2006-12-01T07:53:21Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 30 Nov 2006, Linus Torvalds wrote:\n> \n> So my guess is that there wasn't actually a conflict at all, but the \n> \"merge\" program (usually in /usr/bin/merge) returned an error for some \n> reason. What does \"which merge\" and \"rpm -qf /usr/bin/merge\" say?\n\nSide note: the historically more common failure was to not have a merge \nprogram at all, but exactly because that was common, we check for that and \ncomplain about it. So that's not it for you - you do have a 'merge' \nprogram somewhere that git found.\n\nBut if it returns the wrong error code, or doesn't do anything at all (ie \nyou have \"merge\", but it's not the 3-way merge we expect, or it doesn't \ntake the \"-L\" argument we use, or it's simply buggy) then that might \nexplain the behaviour you report.\n\nOr it might be something totally different. This is just a wild theory.\n\n"},{"id":"296518","messageId":"Pine.LNX.4.64.0611302353580.3695@woody.osdl.org","threadId":"43141","inReplyTo":"456FDF24.1070001@saville.com","subject":"Re: Resolving conflicts","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-12-01T07:57:17Z","receivedAt":"2006-12-01T07:57:17Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 30 Nov 2006, Wink Saville wrote:\n> \n> Earlier had a problem with git wanting merge but didn't have it and\n> couldn't figure out which package it was in Ubuntu:( So I symlinked merge\n> to kdiff3 which worked at the time:\n\nAhh. I'm pretty sure that is it.\n\nNo, kdiff3 probably doesn't have the same semantics, so better get the \n\"real\" merge. It's almost certainly in the rcs package, so \"emerge rcs\" \nshould do it.\n\nOr whatever system Ubuntu uses. \n\n"},{"id":"298624","messageId":"Pine.LNX.4.64.0611302359400.3695@woody.osdl.org","threadId":"43141","inReplyTo":"Pine.LNX.4.64.0611302353580.3695@woody.osdl.org","subject":"Re: Resolving conflicts","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-12-01T08:00:43Z","receivedAt":"2006-12-01T08:00:43Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 30 Nov 2006, Linus Torvalds wrote:\n> \n> No, kdiff3 probably doesn't have the same semantics, so better get the \n> \"real\" merge. It's almost certainly in the rcs package, so \"emerge rcs\" \n> should do it.\n\n..and just to be safe, remove the symlink first, so that you don't end up \noverwriting the \"kdiff3\" binary by mistake when you install the real \n\"merge\". Not that I think emerge is quite that stupid a package manager, \nbut anyway..\n\n"},{"id":"296461","messageId":"200612010810.25232.alan@chandlerfamily.org.uk","threadId":"43141","inReplyTo":"456FDCB5.9040907@saville.com","subject":"Re: Resolving conflicts","fromName":"Alan Chandler","fromEmail":"alan@chandlerfamily.org.uk","sentAt":"2006-12-01T08:10:25Z","receivedAt":"2006-12-01T08:10:25Z","isPatch":false,"sender":{"key":"alan@chandlerfamily.org.uk","avatar":"https://gravatar.com/avatar/1862247e5ea8eac114c842f9dc3a5db6253754e24ef7171757cf97eedce48b8c?d=mp&s=160"},"body":"On Friday 01 December 2006 07:41, Wink Saville wrote:\n> Alan Chandler wrote:\n> > On Friday 01 December 2006 07:06, Wink Saville wrote:\n> >\n> > Take a look in these two files - you should see conflict markers of the\n> > form <<<<<<<<<<<<<<<<\n> > some content\n> > ================\n> > some other content\n>\n> That's what I thought but there isn't any \"<<<<<\" and git-diff also seems\n> to indicate no differences:\n\nThis is at the limit of my understanding, but perhaps file permission problems \ncould have been the cause (was also thinking white space - but to my \nrecollection is that that DOES cause resolution markers) \n\nI think you'll have to wait for experts from the list to comment.\n-- \nAlan Chandler\n"},{"id":"298603","messageId":"200612010813.41001.alan@chandlerfamily.org.uk","threadId":"43141","inReplyTo":"Pine.LNX.4.64.0611302359400.3695@woody.osdl.org","subject":"Re: Resolving conflicts","fromName":"Alan Chandler","fromEmail":"alan@chandlerfamily.org.uk","sentAt":"2006-12-01T08:13:40Z","receivedAt":"2006-12-01T08:13:40Z","isPatch":false,"sender":{"key":"alan@chandlerfamily.org.uk","avatar":"https://gravatar.com/avatar/1862247e5ea8eac114c842f9dc3a5db6253754e24ef7171757cf97eedce48b8c?d=mp&s=160"},"body":"On Friday 01 December 2006 08:00, Linus Torvalds wrote:\n> On Thu, 30 Nov 2006, Linus Torvalds wrote:\n> > No, kdiff3 probably doesn't have the same semantics, so better get the\n> > \"real\" merge. It's almost certainly in the rcs package, so \"emerge rcs\"\n> > should do it.\n>\n> ..and just to be safe, remove the symlink first, so that you don't end up\n> overwriting the \"kdiff3\" binary by mistake when you install the real\n> \"merge\". Not that I think emerge is quite that stupid a package manager,\n> but anyway..\n\nUbuntu is a Debian based.  I think it uses Synaptic as its package manager gui \nwith the standard Debian apt-xxx tools underneath.\n-- \nAlan Chandler\n"},{"id":"298302","messageId":"456FE642.6020102@saville.com","threadId":"43141","inReplyTo":"Pine.LNX.4.64.0611302359400.3695@woody.osdl.org","subject":"Re: Resolving conflicts","fromName":"Wink Saville","fromEmail":"wink@saville.com","sentAt":"2006-12-01T08:22:26Z","receivedAt":"2006-12-01T08:22:26Z","isPatch":false,"sender":{"key":"wink@saville.com","avatar":"https://avatars.githubusercontent.com/u/1024284?v=4"},"body":"Linus Torvalds wrote:\n> \n> On Thu, 30 Nov 2006, Linus Torvalds wrote:\n>> No, kdiff3 probably doesn't have the same semantics, so better get the \n>> \"real\" merge. It's almost certainly in the rcs package, so \"emerge rcs\" \n>> should do it.\n> \n> ..and just to be safe, remove the symlink first, so that you don't end up \n> overwriting the \"kdiff3\" binary by mistake when you install the real \n> \"merge\". Not that I think emerge is quite that stupid a package manager, \n> but anyway..\n> \n> \t\tLinus\n> \n\nUbuntu is debian based and I use Synaptic GUI, a front end to apt-get. My earlier problem\nwas I couldn't find which package \"merge\" was in. But now I just figured it out by going\nto debian.org and using \"Search the contents of packages\" for \"merge\". Turns out \"merge\"\nis in devel/rcs which of course the whole world knows, unless your a neophyte like me:)\n\nAny way after getting the real merge, I reverted the first pull and re-did it and all was well:\n\nwink@winkc2d1:~/linux/linux-2.6$ git-checkout -f\nwink@winkc2d1:~/linux/linux-2.6$ git-status\n# On branch refs/heads/ace\nnothing to commit\nwink@winkc2d1:~/linux/linux-2.6$ git-pull . master\nTrying really trivial in-index merge...\nfatal: Merge requires file-level merging\nNope.\nMerging HEAD with 0215ffb08ce99e2bb59eca114a99499a4d06e704\nMerging:\nd7083db038fb98266e331a7f96198ec35a12367a A partial fix BUG 061124 (crashing when 1ms interrrupts).\n0215ffb08ce99e2bb59eca114a99499a4d06e704 Linux 2.6.19\nfound 1 common ancestor(s):\n1abbfb412b1610ec3a7ec0164108cee01191d9f5 [PATCH] x86_64: fix bad page state in process 'swapper'\nAuto-merging kernel/fork.c\nAuto-merging kernel/spinlock.c\n\nMerge made by recursive.\n  Documentation/rtc.txt                         |  463 ++++++++++++++++---------\n  Makefile                                      |    2\n  arch/arm/configs/assabet_defconfig            |    1\n  arch/arm/configs/cerfcube_defconfig           |    1\n  arch/arm/configs/corgi_defconfig              |    1\n......\n  sound/pci/emu10k1/emu10k1_main.c              |    1\n  sound/pci/hda/patch_realtek.c                 |    2\n  sound/pci/hda/patch_sigmatel.c                |   14 -\n  sound/usb/usbaudio.c                          |    3\n  usr/Makefile                                  |    2\n  92 files changed, 888 insertions(+), 371 deletions(-)\n  create mode 100644 arch/mips/kernel/topology.c\n  create mode 100644 arch/um/os-Linux/execvp.c\n  create mode 100644 include/asm-arm/mach/udc_pxa2xx.h\n\n\n\nThank you very much,\n\nWink\n"},{"id":"298356","messageId":"200612012347.55294.alan@chandlerfamily.org.uk","threadId":"43141","inReplyTo":"456FE642.6020102@saville.com","subject":"Re: Resolving conflicts","fromName":"Alan Chandler","fromEmail":"alan@chandlerfamily.org.uk","sentAt":"2006-12-01T23:47:55Z","receivedAt":"2006-12-01T23:47:55Z","isPatch":false,"sender":{"key":"alan@chandlerfamily.org.uk","avatar":"https://gravatar.com/avatar/1862247e5ea8eac114c842f9dc3a5db6253754e24ef7171757cf97eedce48b8c?d=mp&s=160"},"body":"On Friday 01 December 2006 08:22, Wink Saville wrote:\n\n> Ubuntu is debian based and I use Synaptic GUI, a front end to apt-get. My\n> earlier problem was I couldn't find which package \"merge\" was in. But now I\n> just figured it out by going to debian.org and using \"Search the contents\n> of packages\" for \"merge\". Turns out \"merge\" is in devel/rcs which of course\n> the whole world knows, unless your a neophyte like me:)\n\nI'm actually using Debian Unstable and basically use the git-core package. Its \nat version 1.4.4.1 - so right up to date, and of course resolves all \ndependencies automatically.\n\nDoesn't Ubuntu have git-core in its repository?\n\n-- \nAlan Chandler\n"},{"id":"294085","messageId":"4570ED29.6030507@saville.com","threadId":"43141","inReplyTo":"200612012347.55294.alan@chandlerfamily.org.uk","subject":"Re: Resolving conflicts","fromName":"Wink Saville","fromEmail":"wink@saville.com","sentAt":"2006-12-02T03:04:09Z","receivedAt":"2006-12-02T03:04:09Z","isPatch":false,"sender":{"key":"wink@saville.com","avatar":"https://avatars.githubusercontent.com/u/1024284?v=4"},"body":"Alan Chandler wrote:\n> On Friday 01 December 2006 08:22, Wink Saville wrote:\n> \n>> Ubuntu is debian based and I use Synaptic GUI, a front end to apt-get. My\n>> earlier problem was I couldn't find which package \"merge\" was in. But now I\n>> just figured it out by going to debian.org and using \"Search the contents\n>> of packages\" for \"merge\". Turns out \"merge\" is in devel/rcs which of course\n>> the whole world knows, unless your a neophyte like me:)\n> \n> I'm actually using Debian Unstable and basically use the git-core package. Its \n> at version 1.4.4.1 - so right up to date, and of course resolves all \n> dependencies automatically.\n> \n> Doesn't Ubuntu have git-core in its repository?\n> \nIt was an older version, so I started at the source.\n\nW\n"},{"id":"295623","messageId":"Pine.LNX.4.64.0612012018490.3476@woody.osdl.org","threadId":"43141","inReplyTo":"456FDF24.1070001@saville.com","subject":"Re: Resolving conflicts","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-12-02T04:30:35Z","receivedAt":"2006-12-02T04:30:35Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n[ Tangentially related.. ]\n\nOn Thu, 30 Nov 2006, Wink Saville wrote:\n> \n> Earlier had a problem with git wanting merge but didn't have it and\n> couldn't figure out which package it was in Ubuntu:( So I symlinked merge\n> to kdiff3 which worked at the time:\n\nBtw, what's the status of the xdl_merge() thing in \"pu\"?\n\nIt would be lovely if this could be one less thing we ever need to worry \nabout, just because we just do it ourselves. But quite frankly, I've never \nlooked at the RCS merge logic, so while I peeked at the xdl_merge patch \nitself, I have absolutely zero way of judging it.\n\nBut the patch in \"pu\" to make merge-recursive use it looks pretty, and \nremoves more lines than it adds, and the xdl_merge() code itself _looked_ \nsane even if I can't judge the algorithm, so... \n\nAnyway, here's one vote for trying to move this thing into \"next\" (first\nasking whether all of Dscho's fixup patches got merged too?). \n\nI realize that git-cvsserver (and my toy merge-file.c that isn't used by \nanything real) also use the external merge program, so we can't remove the \ndependency entirely (both in git.spec.in and documentation) without fixing \nthose too, but at least we would _practically_ be able to ignore it for \nall normal users. And cvsserver would probably be quite fixable too..\n\n"},{"id":"295649","messageId":"7vejri20mf.fsf@assigned-by-dhcp.cox.net","threadId":"43141","inReplyTo":"Pine.LNX.4.64.0612012018490.3476@woody.osdl.org","subject":"Re: Resolving conflicts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-02T07:55:04Z","receivedAt":"2006-12-02T07:55:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> [ Tangentially related.. ]\n>\n> On Thu, 30 Nov 2006, Wink Saville wrote:\n>> \n>> Earlier had a problem with git wanting merge but didn't have it and\n>> couldn't figure out which package it was in Ubuntu:( So I symlinked merge\n>> to kdiff3 which worked at the time:\n>\n> Btw, what's the status of the xdl_merge() thing in \"pu\"?\n\nI am *BEHIND*.  There are too many distractions these days\n(read: day job) and I haven't touched git in any significant\nways for the last several days.\n\nI haven't looked at the code any further than minimally checking\nits external interface to be able to interface it with\nmerge-recursive and no more.  Namely:\n\n - I haven't read the algorithm to judge its correctness;\n\n - I haven't looked for leaks;\n\n - I haven't used the resulting merge-recursive in any real\n   merge; some of our tests do rely on a correctly working\n   merge-recursive, so it is not like the algorithm is always\n   emitting \"boo ha ha\" and returning no conflicts ;-).\n\n - I haven't benched it to see how much performance is gained\n   by bypassing an extra fork+exec.\n\nAmong the four patches Johannes sent out to the list and Davide,\none was already in his original patch I have in 'pu', another\nmakes the same return value change I did myself when interfacing\nthe code with merge-recursive.  I have queued the remaining two\nin 'pu', so there should be nothing missing.\n\nOne of them is marked as \"fix off by one error\" but it was about\nmore than off by one (the code walks two arrays using one index\nfor each, but the original code incorrectly used the same index\nto access both arrays at one point, which was also fixed).  I\ndid mind the lack of explanation and wanted to reword the log\nmessage, but as I said, I haven't read the algorithm to\nunderstand what the code is doing enough, so I cannot write\nanything useful there yet X-<, which is one of the reasons why\nit is still queued in 'pu'.\n\n\n"},{"id":"293908","messageId":"Pine.LNX.4.63.0612021131140.28348@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43141","inReplyTo":"7vejri20mf.fsf@assigned-by-dhcp.cox.net","subject":"using xdl_merge(), was Re: Resolving conflicts","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-02T10:49:06Z","receivedAt":"2006-12-02T10:49:06Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 1 Dec 2006, Junio C Hamano wrote:\n\n> Linus Torvalds <torvalds@osdl.org> writes:\n> \n> > [ Tangentially related.. ]\n> >\n> > On Thu, 30 Nov 2006, Wink Saville wrote:\n> >> \n> >> Earlier had a problem with git wanting merge but didn't have it and\n> >> couldn't figure out which package it was in Ubuntu:( So I symlinked merge\n> >> to kdiff3 which worked at the time:\n> >\n> > Btw, what's the status of the xdl_merge() thing in \"pu\"?\n> \n> I haven't looked at the code any further than minimally checking\n> its external interface to be able to interface it with\n> merge-recursive and no more.  Namely:\n> \n>  - I haven't read the algorithm to judge its correctness;\n\nWith my track record of blamable patches, that should be done by somebody \nelse than me.\n\n>  - I haven't looked for leaks;\n\nNeither have I.\n\n>  - I haven't used the resulting merge-recursive in any real\n>    merge; some of our tests do rely on a correctly working\n>    merge-recursive, so it is not like the algorithm is always\n>    emitting \"boo ha ha\" and returning no conflicts ;-).\n\nI have. There is a subtle difference to merge, but it might be serious \nenough:\n\ndiff --just-made-up orig new1\n Hello world\n+This conflicts\n Bye bye world\n+This does not conflict\n\ndiff --just-made-up orig new2\n Hello world\n+This is different in new2\n Bye bye world\n\nIf my interpretation of the test is correct, then the last line of new1 \nwill _not_ conflict with xdl_merg( as is, but with RCS merge. I will fix \nthat shortly.\n\n>  - I haven't benched it to see how much performance is gained\n>    by bypassing an extra fork+exec.\n\nThere is room for improvement, but I get shaky numbers betwen 31% and \n118% (runtime git-merge-recursive xdl_merge() / RCS merge). These are \nextremely ad-hoc generated numbers, so handle with care. My \ngut feeling is that a few improvements in the code will give a rough \n30%-50% in the average case.\n\nThese improvements include not parsing orig twice, and compacting the \nmerge script before applying it.\n\n> Among the four patches Johannes sent out to the list and Davide,\n> one was already in his original patch I have in 'pu', another\n> makes the same return value change I did myself when interfacing\n> the code with merge-recursive.\n\nYeah, sorry. When I sent the patches, I did not see xdl_merge() in pu.\n\n> I have queued the remaining two in 'pu', so there should be nothing \n> missing.\n> \n> One of them is marked as \"fix off by one error\" but it was about\n> more than off by one (the code walks two arrays using one index\n> for each, but the original code incorrectly used the same index\n> to access both arrays at one point, which was also fixed).  I\n> did mind the lack of explanation and wanted to reword the log\n> message, but as I said, I haven't read the algorithm to\n> understand what the code is doing enough, so I cannot write\n> anything useful there yet X-<, which is one of the reasons why\n> it is still queued in 'pu'.\n\nSorry again. I fixed that bug in the middle of the night, and committed \nthe next day, trying to deduct what I fixed.\n\nAgain, I do not see the patches in pu, though. I will concoct a nice \ncommit message later today, okay?\n\nLinus, you raised the concern that git-cvsserer still relies on \nexternal merge. I'd just bastardize git-merge-one-file to work as a \nreplacement of RCS merge (just like git apply works as a replacement of \npatch), in addition to its original function.\n\nCiao,\nDscho\n"},{"id":"298105","messageId":"4575B32F.5060108@ramsay1.demon.co.uk","threadId":"43141","inReplyTo":"Pine.LNX.4.63.0612021131140.28348@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: using xdl_merge(), was Re: Resolving conflicts","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsay1.demon.co.uk","sentAt":"2006-12-05T17:58:07Z","receivedAt":"2006-12-05T17:58:07Z","isPatch":false,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"Johannes Schindelin wrote:\n> On Fri, 1 Dec 2006, Junio C Hamano wrote:\n>> Linus Torvalds <torvalds@osdl.org> writes:\n>>> On Thu, 30 Nov 2006, Wink Saville wrote:\n>>>> Earlier had a problem with git wanting merge but didn't have it and\n>>>> couldn't figure out which package it was in Ubuntu:( So I symlinked merge\n>>>> to kdiff3 which worked at the time:\n>>> Btw, what's the status of the xdl_merge() thing in \"pu\"?\n>> I haven't looked at the code any further than minimally checking\n>> its external interface to be able to interface it with\n>> merge-recursive and no more.  Namely:\n>>\n>>  - I haven't read the algorithm to judge its correctness;\n> \n> With my track record of blamable patches, that should be done by somebody \n> else than me.\n> \n\nHave you had time to look at my test cases?\nAs I said, I found them very useful when debugging\nmy git-diff3 code, and (hopefully) you will find them\nto be equally useful.\n\n> Ciao,\n> Dscho\n> \n\nAll the best,\n\nRamsay\n\n"},{"id":"295150","messageId":"Pine.LNX.4.64.0612051023460.3542@woody.osdl.org","threadId":"43141","inReplyTo":"4575B32F.5060108@ramsay1.demon.co.uk","subject":"Re: using xdl_merge(), was Re: Resolving conflicts","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-12-05T18:28:53Z","receivedAt":"2006-12-05T18:28:53Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 5 Dec 2006, Ramsay Jones wrote:\n>\n> Have you had time to look at my test cases?\n> As I said, I found them very useful when debugging\n> my git-diff3 code, and (hopefully) you will find them\n> to be equally useful.\n\nIt might be interesting to also do a simple test:\n\n - take every single merge in git (or the kernel, if you want even more)\n\n - ignore all the trivial ones that didn't have any file-level merging at \n   all (ie done entirely in the index)\n\n - for all the rest, just compare what the end result is when re-doing the \n   merge with \"xdl_merge\" vs \"external 3-way merge\".\n\n[ Side note: DO NOT COMPARE AGAINST THE ACTUAL RESULT IN GIT OR IN THE \n  KERNEL ARCHIVE! Those will obviously have been fixed up by humans in the \n  event of a data conflict, and sometimes even in the _absense_ of a data \n  conflict (ie \"git commit --amend\" to fix up something that got mismerged \n  perfectly automatically or whatever).\n\n  So a script should literally re-do the merge two ways, and compare the \n  end result ]\n\nIs that any \"proof\"? Of course not. And it will probably show differences \ndue to any conflict handling, but a lot of the time you'd expect to get \nexactly the same end result, so the occasional differences are going to be \njust all the more interesting (\"it resolved differently, but it was \nan equally good resolve\" is interesting data on its own).\n\nAnybody want to write a small script to do this?\n\n"},{"id":"297845","messageId":"Pine.LNX.4.63.0612051926360.28348@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43141","inReplyTo":"4575B32F.5060108@ramsay1.demon.co.uk","subject":"Re: using xdl_merge(), was Re: Resolving conflicts","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-05T18:36:36Z","receivedAt":"2006-12-05T18:36:36Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 5 Dec 2006, Ramsay Jones wrote:\n\n> Have you had time to look at my test cases?\n\nNot really. Besides, I did _not_ implement a full diff3, but _just_ the \nmerge. I.e. my function does not output anything, but (in theory) fills a \nbuffer with what merge would have written into the first file.\n\nHowever, once I understand how your tests work, I'll try to concoct a test \nscript for git-with-xdl_merge.\n\nCiao,\n"},{"id":"296162","messageId":"7vwt56gp45.fsf@assigned-by-dhcp.cox.net","threadId":"43141","inReplyTo":"Pine.LNX.4.64.0612051023460.3542@woody.osdl.org","subject":"Re: using xdl_merge(), was Re: Resolving conflicts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-05T18:43:38Z","receivedAt":"2006-12-05T18:43:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> On Tue, 5 Dec 2006, Ramsay Jones wrote:\n>>\n>> Have you had time to look at my test cases?\n>> As I said, I found them very useful when debugging\n>> my git-diff3 code, and (hopefully) you will find them\n>> to be equally useful.\n>\n> It might be interesting to also do a simple test:\n>\n>  - take every single merge in git (or the kernel, if you want even more)\n>\n>  - ignore all the trivial ones that didn't have any file-level merging at \n>    all (ie done entirely in the index)\n>\n>  - for all the rest, just compare what the end result is when re-doing the \n>    merge with \"xdl_merge\" vs \"external 3-way merge\".\n>\n> [ Side note: DO NOT COMPARE AGAINST THE ACTUAL RESULT IN GIT OR IN THE \n>   KERNEL ARCHIVE! Those will obviously have been fixed up by humans in the \n>   event of a data conflict, and sometimes even in the _absense_ of a data \n>   conflict (ie \"git commit --amend\" to fix up something that got mismerged \n>   perfectly automatically or whatever).\n>\n>   So a script should literally re-do the merge two ways, and compare the \n>   end result ]\n>\n> Is that any \"proof\"? Of course not. And it will probably show differences \n> due to any conflict handling, but a lot of the time you'd expect to get \n> exactly the same end result, so the occasional differences are going to be \n> just all the more interesting (\"it resolved differently, but it was \n> an equally good resolve\" is interesting data on its own).\n>\n> Anybody want to write a small script to do this?\n>\n> \t\tLinus\n\nI was planning to do this today anyway.  Thanks for the\nreminder.\n"},{"id":"295976","messageId":"Pine.LNX.4.63.0612051949290.28348@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43141","inReplyTo":"Pine.LNX.4.64.0612051023460.3542@woody.osdl.org","subject":"Re: using xdl_merge(), was Re: Resolving conflicts","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-05T18:53:09Z","receivedAt":"2006-12-05T18:53:09Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 5 Dec 2006, Linus Torvalds wrote:\n\n>  - take every single merge in git (or the kernel, if you want even more)\n\nI tried that already. Only to find that the first merge I tested showed \none change between RCS merge and xdl_merge(): xdl_merge() does not yet \ntake context into account, so these two diffs\n\n@@ bla\n Ten\n+weary\n footsore\n+wanderers\n all\n in\n a\n\nand\n\n@@ blub\n Ten\n+weird\n footsore\n all\n in\n a\n\nwill conflict only for the weary/weird lines, _not_ for wanderers.\n\nBesides, my recent patch series was gained exactly by that test. Though I \ndid not extend that test to the Linux repo, and I am by no means finished \nwith the git one.\n\nCiao,\n"},{"id":"297254","messageId":"7vac22glzz.fsf@assigned-by-dhcp.cox.net","threadId":"43141","inReplyTo":"Pine.LNX.4.63.0612051949290.28348@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: using xdl_merge(), was Re: Resolving conflicts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-05T19:50:56Z","receivedAt":"2006-12-05T19:50:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> On Tue, 5 Dec 2006, Linus Torvalds wrote:\n>\n>>  - take every single merge in git (or the kernel, if you want even more)\n\nThe attached is the script I am using.  The test checks the\noutput from 'master' (merge from RCS) and 'next' (with xdl-merge)\nand also tries to see how different the conflicts look like.\n\nIn the git.git archive, there is no \"clean\" merge on which\n'master' and 'next' did not agree.  It is not a proof of\ncorrectness at all but it gives a sense of assurance.\n\nHowever, the conflict 'next' leaves seems a bit suspicious.\nTrying to reproduce\n\n\t56f9686c4d1e1d586b731b815bd98d70f84ecda4\n\ngives an interesting illustration.\n\nHere is one conflicted hunk from that merge (RCS merge)\n\n-- 8< -- RCS merge conflict hunk, diff from the 1st parent -- 8< --\n \n--- a/Makefile\n+++ b/Makefile\n@@ -232,8 +232,13 @@ LIB_FILE=libgit.a\n XDIFF_LIB=xdiff/lib.a\n \n LIB_H = \\\n+<<<<<<< HEAD/Makefile\n \tarchive.h blob.h cache.h commit.h csum-file.h delta.h \\\n \tdiff.h object.h pack.h pkt-line.h quote.h refs.h \\\n+=======\n+\tblob.h cache.h commit.h csum-file.h delta.h \\\n+\tdiff.h object.h pack.h pkt-line.h quote.h refs.h sideband.h \\\n+>>>>>>> d47f3db75c58139cdcbca5cc63b17bf5db293b6a/Makefile\n \trun-command.h strbuf.h tag.h tree.h git-compat-util.h revision.h \\\n \ttree-walk.h log-tree.h dir.h path-list.h unpack-trees.h builtin.h\n \n-- >8 -- RCS merge conflict hunk, diff from the 1st parent -- >8 --\n\n-- 8< -- JS merge conflict hunk, diff from the 1st parent -- 8< --\n\n--- a/Makefile\n+++ b/Makefile\n@@ -232,8 +232,14 @@ LIB_FILE=libgit.a\n XDIFF_LIB=xdiff/lib.a\n \n LIB_H = \\\n+<<<<<<< HEAD/Makefile\n \tarchive.h blob.h cache.h commit.h csum-file.h delta.h \\\n \tdiff.h object.h pack.h pkt-line.h quote.h refs.h \\\n+=======\n+\tblob.h cache.h commit.h csum-file.h delta.h \\\n+\tdiff.h object.h pack.h pkt-line.h quote.h refs.h sideband.h \\\n+>>>>>>> d47f3db75c58139cdcbca5cc63b17bf5db293b6a/Makefile\n+\tdiff.h object.h pack.h pkt-line.h quote.h refs.h sideband.h \\\n \trun-command.h strbuf.h tag.h tree.h git-compat-util.h revision.h \\\n \ttree-walk.h log-tree.h dir.h path-list.h unpack-trees.h builtin.h\n \n-- >8 -- JS merge conflict hunk, diff from the 1st parent -- >8 --\n\nNotice that there is one duplicated line after the closing\nconflict marker?\n\n\n-- 8< -- remerge.sh test script -- 8< --\n#!/bin/sh\n# Leaves things to be examined in /var/tmp/remerge-$$/\n\nogit=$HOME/git-master/bin/git\nngit=$HOME/git-next/bin/git\ntmp=/var/tmp/remerge-$$-tmp\n\ntrap 'rm -f $tmp-*' 0\n\n# Revlist\nif ! test -f ./+RL\nthen\n\tgit rev-list --parents HEAD |\n\tperl -n -e 'if (/^[0-9a-f]{40} [0-9a-f]{40} [0-9a-f]{40}$/) {\n\t\tprint;\n\t}' >./+RL\nfi\n\ntry_one () {\n\t# should be on a discardable branch.\n\n\tgit=$1 parent1=$2 parent2=$3\n\t$git reset --hard \"$parent1\"\n\t\n\tif $git merge \"$parent2\"\n\tthen\n\t\techo clean merge\n\t\t$git diff-tree -r --raw \"$parent1\" HEAD \n\telse\n\t\techo conflicted merge\n\t\t$git ls-files -u\n\t\t$git diff --binary -p \"$parent1\"\n\tfi\n}\n\n# Make sure we do not trash anything important\ncurrent=`git symbolic-ref HEAD`\nif test \"z$current\" != zrefs/heads/remerge-test\nthen\n\tgit checkout -b remerge-test ||\n        git checkout remerge-test\n\n        current=`git symbolic-ref HEAD`\n        test \"z$current\" = zrefs/heads/remerge-test || exit\nfi\n\nwhile read result parent1 parent2\ndo\n\ttry_one $ogit $parent1 $parent2 >$tmp-1 2>/dev/null\n\ttry_one $ngit $parent1 $parent2 >$tmp-2 2>/dev/null\n\tif diff $tmp-1 $tmp-2\n\tthen\n\t\techo \"Ok\"\n\telse\n\t\techo \"Bad $result\"\n\t\tmkdir -p $tmp/$result\n\t\tmv $tmp-1 $tmp/$result/ogit\n\t\tmv $tmp-2 $tmp/$result/ngit\n\tfi\n\t$git reset --hard\ndone < ./+RL\n\n"},{"id":"297656","messageId":"Pine.LNX.4.63.0612052209030.28348@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43141","inReplyTo":"7vac22glzz.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] xdl_merge(): fix and simplify conflict handling","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-05T21:15:35Z","receivedAt":"2006-12-05T21:15:35Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nSuppose you have changes in new1 to the original lines 10-20,\nand changes in new2 to the original lines 15-25, then the\nchanges to 10-25 conflict. But it is possible that the next\nchanges in new1 still overlap with this change to new2.\n\nSo, in the next iteration we have to look at the same change\nto new2 again.\n\nThe old code tried to be a bit too clever. The new code is\nshorter and more to the point: do not fiddle with the ranges\nat all.\n\nAlso, xdl_append_merge() tries harder to combine conflicts.\nThis is necessary, because with the above simplification,\nsome conflicts would not be recognized as conflicts otherwise:\n\nIn the above scenario, it is possible that there is no other\nchange to new1. Absent the combine logic, the change in new2\nwould be recorded _again_, but as a non-conflict.\n\nSigned-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>\n---\n\n\tOn Tue, 5 Dec 2006, Junio C Hamano wrote:\n\n\t> However, the conflict 'next' leaves seems a bit suspicious.\n\t> Trying to reproduce\n\t> \n\t> \t56f9686c4d1e1d586b731b815bd98d70f84ecda4\n\t> \n\t> gives an interesting illustration.\n\n\tThis is fixed now.\n\n xdiff/xmerge.c |   21 +++++----------------\n 1 files changed, 5 insertions(+), 16 deletions(-)\n\ndiff --git a/xdiff/xmerge.c b/xdiff/xmerge.c\nindex 1fe7a1b..352207e 100644\n--- a/xdiff/xmerge.c\n+++ b/xdiff/xmerge.c\n@@ -38,8 +38,9 @@ static int xdl_append_merge(xdmerge_t **merge, int mode,\n \t\tlong i1, long chg1, long i2, long chg2)\n {\n \txdmerge_t *m = *merge;\n-\tif (m && mode == m->mode &&\n-\t\t\t(i1 == m->i1 + m->chg1 || i2 == m->i2 + m->chg2)) {\n+\tif (m && (i1 <= m->i1 + m->chg1 || i2 <= m->i2 + m->chg2)) {\n+\t\tif (mode != m->mode)\n+\t\t\tm->mode = 0;\n \t\tm->chg1 = i1 + chg1 - m->i1;\n \t\tm->chg2 = i2 + chg2 - m->i2;\n \t} else {\n@@ -313,22 +314,10 @@ static int xdl_do_merge(xdfenv_t *xe1, xdchange_t *xscr1, const char *name1,\n \t\ti1 = xscr1->i1 + xscr1->chg1;\n \t\ti2 = xscr2->i1 + xscr2->chg1;\n \n-\t\tif (i1 > i2) {\n-\t\t\txscr1->chg1 -= i1 - i2;\n-\t\t\txscr1->i1 = i2;\n-\t\t\txscr1->i2 += xscr1->chg2;\n-\t\t\txscr1->chg2 = 0;\n+\t\tif (i1 >= i2)\n \t\t\txscr2 = xscr2->next;\n-\t\t} else if (i2 > i1) {\n-\t\t\txscr2->chg1 -= i2 - i1;\n-\t\t\txscr2->i1 = i1;\n-\t\t\txscr2->i2 += xscr2->chg2;\n-\t\t\txscr2->chg2 = 0;\n-\t\t\txscr1 = xscr1->next;\n-\t\t} else {\n+\t\tif (i2 >= i1)\n \t\t\txscr1 = xscr1->next;\n-\t\t\txscr2 = xscr2->next;\n-\t\t}\n \t}\n \twhile (xscr1) {\n \t\tif (!changes)\n-- \n1.4.4.1.g394ac-dirty\n"},{"id":"294928","messageId":"7vvekqf0yh.fsf@assigned-by-dhcp.cox.net","threadId":"43141","inReplyTo":"Pine.LNX.4.63.0612052209030.28348@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] xdl_merge(): fix and simplify conflict handling","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-05T22:10:46Z","receivedAt":"2006-12-05T22:10:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thanks.\n\nLooking at some other cases after applying your patch, I noticed\nthat I really like one thing that your version does over what\nRCS merge does.\n\nWith RCS merge, a run of lines that are modified the same way in\nboth branches appear twice, like this:\n\n\t<<< orig\n        alpha\n        bravo\n        charlie\n        ...\n\tx-ray\n\tyankee\n        zulu\n        ===\n        alpha\n        bravo\n        charlie\n        ...\n        x-ray\n        yankee\n        zebra\n        >>> new\n\nThe common part at the beginning (or at the end for that\nmatter) can be hoisted outside, to produce:\n\n        alpha\n        bravo\n        charlie\n        ...\n\tx-ray\n\tyankee\n\t<<< orig\n        zulu\n        ===\n        zebra\n        >>> new\n\nand your version seems to get this right.\n\nWhen I had to deal with this kind of conflicts, I ended up\nsplitting the buffer in two, and ran M-x compare-windows to find\nthe true differences between the choices.  It was frustrating.\n(I admit a big reason is I do not normally work in X environment\nand do not tend to use xdiff -U or Kompare).\n\nThis is especially noticeable when recreating diff-delta.c merge\nconflict in commit b485db98.  It's fun to see this large hunk\nreduced down to only two lines ;-).\n\n<<<<<<< HEAD/diff-delta.c\n\t/*\n\t * Determine a limit on the number of entries in the same hash\n\t * bucket.  This guard us against patological data sets causing\n\t * really bad hash distribution with most entries in the same hash\n\t * bucket that would bring us to O(m*n) computing costs (m and n\n\t * corresponding to reference and target buffer sizes).\n\t *\n\t * The more the target buffer is large, the more it is important to\n\t * have small entry lists for each hash buckets.  With such a limit\n\t * the cost is bounded to something more like O(m+n).\n\t */\n\thlimit = (1 << 26) / trg_bufsize;\n\tif (hlimit < 16)\n\t\thlimit = 16;\n\n\t/*\n\t * Now make sure none of the hash buckets has more entries than\n\t * we're willing to test.  Otherwise we short-circuit the entry\n\t * list uniformly to still preserve a good repartition across\n\t * the reference buffer.\n\t */\n\tfor (i = 0; i < hsize; i++) {\n\t\tif (hash_count[i] < hlimit)\n\t\t\tcontinue;\n\t\tentry = hash[i];\n\t\tdo {\n\t\t\tstruct index *keep = entry;\n\t\t\tint skip = hash_count[i] / hlimit / 2;\n\t\t\tdo {\n\t\t\t\tentry = entry->next;\n\t\t\t} while(--skip && entry);\n\t\t\tkeep->next = entry;\n\t\t} while(entry);\n\t}\n\tfree(hash_count);\n\n\treturn hash;\n=======\n\t/*\n\t * Determine a limit on the number of entries in the same hash\n\t * bucket.  This guard us against patological data sets causing\n\t * really bad hash distribution with most entries in the same hash\n\t * bucket that would bring us to O(m*n) computing costs (m and n\n\t * corresponding to reference and target buffer sizes).\n\t *\n\t * The more the target buffer is large, the more it is important to\n\t * have small entry lists for each hash buckets.  With such a limit\n\t * the cost is bounded to something more like O(m+n).\n\t */\n\thlimit = (1 << 26) / trg_bufsize;\n\tif (hlimit < 16)\n\t\thlimit = 16;\n\n\t/*\n\t * Now make sure none of the hash buckets has more entries than\n\t * we're willing to test.  Otherwise we short-circuit the entry\n\t * list uniformly to still preserve a good repartition across\n\t * the reference buffer.\n\t */\n\tfor (i = 0; i < hsize; i++) {\n\t\tif (hash_count[i] < hlimit)\n\t\t\tcontinue;\n\t\tentry = hash[i];\n\t\tdo {\n\t\t\tstruct index *keep = entry;\n\t\t\tint skip = hash_count[i] / hlimit / 2;\n\t\t\tdo {\n\t\t\t\tentry = entry->next;\n\t\t\t} while(--skip && entry);\n\t\t\tkeep->next = entry;\n\t\t} while(entry);\n\t}\n\tfree(hash_count);\n\n\treturn hash-1;\n>>>>>>> 38fd0721d0a2a1a723bc28fc0817e3571987b1ef/diff-delta.c\n\n"},{"id":"295851","messageId":"Pine.LNX.4.63.0612052320320.28348@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43141","inReplyTo":"7vvekqf0yh.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] xdl_merge(): fix and simplify conflict handling","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-05T22:24:41Z","receivedAt":"2006-12-05T22:24:41Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 5 Dec 2006, Junio C Hamano wrote:\n\n> Looking at some other cases after applying your patch, I noticed that I \n> really like one thing that your version does over what RCS merge does.\n\nGee, thanks!\n\nActually, this was what I intended to do first when somebody submitted a \nbuiltin merge: Be clever about what is a conflict and what not.\n\nSpeaking about a builtin merge: I like the fact that git-apply also works \noutside of git repositories. It makes life easier to have a sane patcher \naround.\n\nNow, I'd like the same with git-diff, and an RCS merge replacement... Of \ncourse, what with all those porcelainish commands we should not add new \ncommands, but enhance existing ones. Any ideas which ones?\n\nCiao,\nDscho\n"},{"id":"293945","messageId":"el4rko$aqe$1@sea.gmane.org","threadId":"43141","inReplyTo":"7vvekqf0yh.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] xdl_merge(): fix and simplify conflict handling","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-05T22:27:37Z","receivedAt":"2006-12-05T22:27:37Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Looking at some other cases after applying your patch, I noticed\n> that I really like one thing that your version does over what\n> RCS merge does.\n\nIs it with \"try harder\" option?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"295054","messageId":"Pine.LNX.4.63.0612052327210.28348@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43141","inReplyTo":"el4rko$aqe$1@sea.gmane.org","subject":"Re: [PATCH] xdl_merge(): fix and simplify conflict handling","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-05T22:27:44Z","receivedAt":"2006-12-05T22:27:44Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 5 Dec 2006, Jakub Narebski wrote:\n\n> Junio C Hamano wrote:\n> \n> > Looking at some other cases after applying your patch, I noticed\n> > that I really like one thing that your version does over what\n> > RCS merge does.\n> \n> Is it with \"try harder\" option?\n\nYes, it uses the XDL_MERGE_ZEALOUS option.\n\nCiao,\nDscho\n"},{"id":"295791","messageId":"7v3b7ueyxc.fsf@assigned-by-dhcp.cox.net","threadId":"43141","inReplyTo":"Pine.LNX.4.63.0612052320320.28348@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] xdl_merge(): fix and simplify conflict handling","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-05T22:54:39Z","receivedAt":"2006-12-05T22:54:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> Speaking about a builtin merge: I like the fact that git-apply also works \n> outside of git repositories. It makes life easier to have a sane patcher \n> around.\n\nWell, git-apply is designed as a better \"patch\", so it is\nnatural that it works in a non-git directory [*1*].\n\nI am not sure what you mean by a builtin merge that works\noutside the context of git.  Do you mean a pure RCS merge\nreplacement that takes three files and spits out the result in\none of them?  If so that would probably deserve to be a separate\ncommand, because I do not think of a use for such a thing inside\ngit.  We've done merge-recursive.c already so it would not need\nan external 'merge'.  If somebody is so inclined to to do the\n\"merge-resolve\" strategy, I think the right way is to make a\nsingle program that does what git-merge-index and merge-one-file\ndoes without fork nor exec, so it would not need an external\n'merge' either.\n\n> Now, I'd like the same with git-diff, and an RCS merge replacement...\n\nYes, back when I was actively hacking git-diff, I dreamt about a\nvariant that takes two or more (non-git managed) directories and\ndoes an equivalent of diff-tree with -M/-C/.../-c/--cc.  It\nwould be cool and useful.\n\nI understand your aversion to new commands, but I do not think\nyou can avoid it if what you mean is an RCS merge replacement.\n\nThe diff that works on \"two or more directories without anything\ngit\" could be just a new option to \"git diff\", though.\n\nBut I am not going to do it myself; it's usually a lot faster\nfor me to just do \"git init-db; git add . \" on an extracted\ntarball.\n\n[Footnote]\n\n*1* ... and that is one of the reasons why it does not even try\nto read the index unless it is told to do so.\n\nAnd we should not make it \"detect we are in git repository\" and\ndefault to --index either.  Often running without --index is\nuseful inside a git repository.  I would say roughly 50% of the\ntime I use the command with --index and the rest without, so\n\"more often\" argument unfortunately does not apply to \"apply\".\n\nI wish it were \"2% without --index, 98% with --index\".  Then we\ncould easily say \"add '--no-index if you do not want to\".\n\n\n"},{"id":"296838","messageId":"7vwt5573sy.fsf@assigned-by-dhcp.cox.net","threadId":"43141","inReplyTo":"7vac22glzz.fsf@assigned-by-dhcp.cox.net","subject":"Re: using xdl_merge(), was Re: Resolving conflicts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-06T09:48:45Z","receivedAt":"2006-12-06T09:48:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n>\n>> On Tue, 5 Dec 2006, Linus Torvalds wrote:\n>>\n>>>  - take every single merge in git (or the kernel, if you want even more)\n>\n> The attached is the script I am using.  The test checks the\n> output from 'master' (merge from RCS) and 'next' (with xdl-merge)\n> and also tries to see how different the conflicts look like.\n>\n> In the git.git archive, there is no \"clean\" merge on which\n> 'master' and 'next' did not agree.  It is not a proof of\n> correctness at all but it gives a sense of assurance.\n\nAnd all merges in linux-2.6.git archive either result in\nconflict with both 'merge' implementations, or cleanly resolves\nthe same way with both 'merge' implementations.  I have not\ncompared the conflicted cases yet, but at least it gives me a\nwarm fuzzy feeling to see that autocommitted stuff are sensible.\n"},{"id":"294377","messageId":"Pine.LNX.4.63.0612061058360.28348@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43141","inReplyTo":"7vwt5573sy.fsf@assigned-by-dhcp.cox.net","subject":"Re: using xdl_merge(), was Re: Resolving conflicts","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-06T10:02:10Z","receivedAt":"2006-12-06T10:02:10Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 6 Dec 2006, Junio C Hamano wrote:\n\n> Junio C Hamano <junkio@cox.net> writes:\n> \n> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> >\n> >> On Tue, 5 Dec 2006, Linus Torvalds wrote:\n> >>\n> >>>  - take every single merge in git (or the kernel, if you want even more)\n> >\n> > The attached is the script I am using.  The test checks the\n> > output from 'master' (merge from RCS) and 'next' (with xdl-merge)\n> > and also tries to see how different the conflicts look like.\n> >\n> > In the git.git archive, there is no \"clean\" merge on which\n> > 'master' and 'next' did not agree.  It is not a proof of\n> > correctness at all but it gives a sense of assurance.\n> \n> And all merges in linux-2.6.git archive either result in\n> conflict with both 'merge' implementations, or cleanly resolves\n> the same way with both 'merge' implementations.  I have not\n> compared the conflicted cases yet, but at least it gives me a\n> warm fuzzy feeling to see that autocommitted stuff are sensible.\n\nThank you! Slowly I also get a warm fuzzy feeling...\n\nMy idea, to have an inbuilt work-alike to RCS merge, was not only \ninstigated by my liking the zealous option, but also to be able to add \nrelatively fast tests.\n\nOriginally, I thought that building in git-merge-one-file, and enhancing \nit to recognize by the parameters if it should act as a merge replacement, \nwould be the way to go. Should I do this, or rather add \nbuiltin-merge-file?\n\nCiao,\nDscho\n"},{"id":"297859","messageId":"7vlkll72no.fsf@assigned-by-dhcp.cox.net","threadId":"43141","inReplyTo":"Pine.LNX.4.63.0612061058360.28348@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: using xdl_merge(), was Re: Resolving conflicts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-06T10:13:31Z","receivedAt":"2006-12-06T10:13:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> Originally, I thought that building in git-merge-one-file, and enhancing \n> it to recognize by the parameters if it should act as a merge replacement, \n> would be the way to go. Should I do this, or rather add \n> builtin-merge-file?\n\nAll in-tree users of git-merge-one-file is of this pattern:\n\n\tgit merge-index -o git-merge-one-file -a\n\nso I was hoping we can capture this whole thing as a single\ncommand (merge-index would fork+exec a merge-one-file per\nunmerged path), instead of doing merge-one-file as a built-in.\n\nIn any case, the way your xdl-merge engine is done, it should be\nalmost trivial to write a pure 'RCS merge replacement' as a\ntotally separate program -- the bulk of the new code would be\nparsing parameters, opening the three input files, populating\nmmfile structures and writing the result out, and there would be\nalmost no \"smart\" in that part of the code you would want to\nshare with the git-aware version.\n\n\n\n"},{"id":"297075","messageId":"Pine.LNX.4.63.0612061145220.28348@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43141","inReplyTo":"7vlkll72no.fsf@assigned-by-dhcp.cox.net","subject":"Re: using xdl_merge(), was Re: Resolving conflicts","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-06T10:47:25Z","receivedAt":"2006-12-06T10:47:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 6 Dec 2006, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > Originally, I thought that building in git-merge-one-file, and enhancing \n> > it to recognize by the parameters if it should act as a merge replacement, \n> > would be the way to go. Should I do this, or rather add \n> > builtin-merge-file?\n> \n> All in-tree users of git-merge-one-file is of this pattern:\n> \n> \tgit merge-index -o git-merge-one-file -a\n> \n> so I was hoping we can capture this whole thing as a single\n> command (merge-index would fork+exec a merge-one-file per\n> unmerged path), instead of doing merge-one-file as a built-in.\n\nYes, this was also my thinking. But notice how git-merge-one-file does \nmuch more than just merge? So, you end up rewriting it in C anyway, if you \nwant to make merge-index not fork unless \"-o cmd\" is passed.\n\n> In any case, the way your xdl-merge engine is done, it should be almost \n> trivial to write a pure 'RCS merge replacement' as a totally separate \n> program -- the bulk of the new code would be parsing parameters, opening \n> the three input files, populating mmfile structures and writing the \n> result out, and there would be almost no \"smart\" in that part of the \n> code you would want to share with the git-aware version.\n\nActually, I just did that. I will add some test cases (to reflect your \noption (3) in another thread), and submit.\n\nCiao,\nDscho\n"}]}