{"thread":{"id":"2394","subject":"Re: Expected Behavior?","startedAt":"2005-11-08T03:43:15Z","lastAt":"2005-11-10T23:22:10Z","messageCount":28,"participants":["Jon Loeliger","Junio C Hamano","Petr Baudis","Fredrik Kuivinen","Martin Langhoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"11300","messageId":"E1EZKOB-0002j5-VY@jdl.com","threadId":"2394","inReplyTo":null,"subject":"Re: Expected Behavior?","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2005-11-08T03:43:15Z","receivedAt":"2005-11-08T03:43:15Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"> Yup, it uses \"git-ls-files --others\", which considers that\n> unmerged paths do not \"exist\" in the index.  This is wrong.\n> \n> The attached is a patch to fix ls-files.\n> \n> I also think that file3 should not appear in \"Updated but not\n> checked in (will commit)\" list -- we are _not_ going to commit\n> unmerged paths until you tell git what you want to do with\n> them.  The patch in the next message fixes it.\n\nPatch looks good here!  Thanks!\n\n    % git status\n    #\n    # Updated but not checked in:\n    #   (will commit)\n    #\n    #       modified: file1\n    #       deleted:  file2\n    #\n    #\n    # Changed but not updated:\n    #   (use git-update-index to mark for commit)\n    #\n    #       unmerged: file3\n    #\n\nBut I have a lingering question.  Same script as before.\n\n    % git diff file3\n    * Unmerged path file3\n\n    % cat file3\n    Stuff for a conflict.\n\nWhy didn't file3 show something like:\n\n    % cat file3\n    <<<<<\n    Stuff for a conflict.\n    =====\n    Another file!\n    >>>>>\n\nThat is, after the merge, file3 appears to have simply kept\nthe contents of the current, master branch.  Why wasn't the\ndev branch represented here?\n\nI _almost_ think I get it, and then *poof*...\n\nThanks,\njdl\n"},{"id":"11304","messageId":"7vwtjjllw4.fsf@assigned-by-dhcp.cox.net","threadId":"2394","inReplyTo":"E1EZKOB-0002j5-VY@jdl.com","subject":"Re: Expected Behavior?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-08T06:00:11Z","receivedAt":"2005-11-08T06:00:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Loeliger <jdl@freescale.com> writes:\n\n> That is, after the merge, file3 appears to have simply kept\n> the contents of the current, master branch.  Why wasn't the\n> dev branch represented here?\n>\n> I _almost_ think I get it, and then *poof*...\n\nAutomerge completely punted for this path, and at this point, it\nis still unmerged:\n\n------------\n$ git ls-files --unmerged\n100644 c4da0eb.... 2       file3\n100644 fbc2aa4.... 3       file3\n------------\n\nThree-way \"git-read-tree -m -u O A B\" (O is for old, A is ours\nand B is hers) puts O in stage1, A in stage2 and B in stage3.\nThis path did not exist in O so we only have them in stage2 and\nstage3.  You could compare the stages like this:\n\n------------\n$ git diff-stages -p 2 3 file3\ndiff --git a/file3 b/file3\nindex c4da0eb..fbc2aa4 100644\n--- a/file3\n+++ b/file3\n@@ -1 +1 @@\n-Stuff for a conflict.\n+Another file!\n------------\n\nWhen we do a file-level merge (and possibly leave conflicts), we\nregister _our_ version in the index and leave the merge result\nin the working tree.  However, when O is empty like this case,\nwe leave the conflicting path simply unmerged and do not touch\nthe working tree.  We say \"ERROR: not handling case\" when this\nhappens.\n\nNobody complained so far about this, probably because two side\nadding different versions is rare enough.  And the reasoning\nbehind the current behaviour is probably because the tool cannot\nautomerge them sensibly anyway.  Leaving the SHA1 in index file\nmight probably be easier to clean up by hand (e.g. see ls-files\n--unmerged, and cut&paste the desired SHA1 to 'git-cat-file\nblob' command line, or something silly like that).  But if we\nwere to go that route, adding --stage=[123] flag so that the\nuser can say 'git-checkout-index --stage=3 file3'might have\nhelped a bit more.\n\nWe could instead use the attached patch to get the behaviour you\nare expecting.  I have a feeling that the result from this might\nbe a little more intuitive and easier to resolve by hand than\nthe current one.  Although we may end up unresolvable mess in\nfile3 if either side is binary, in that case the user can still\nsift through 'diff-tree A B file3' output to find out the\nrelevant SHA1 to recover the blobs from both sides by hand\nanyway.  Does anybody have strong opinion on this?\n\n--\n[PATCH] merge with /dev/null as base, instead of not handling O=='' case\n\nInstead of leaving the path unmerged in a case where each side\nadds different version of the same path, attempt to merge it\nwith empty base and leave \"our\" version in the index file, just\nlike we do for the case in conflicting merge.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n\n---\ndiff --git a/git-merge-one-file.sh b/git-merge-one-file.sh\nindex 5419e59..32e17cb 100755\n--- a/git-merge-one-file.sh\n+++ b/git-merge-one-file.sh\n@@ -56,9 +56,18 @@ case \"${1:-.}${2:-.}${3:-.}\" in\n #\n # Modified in both, but differently.\n #\n-\"$1$2$3\")\n-\techo \"Auto-merging $4.\"\n-\torig=`git-unpack-file $1`\n+\"$1$2$3\" | \".$2$3\")\n+\tcase \"$1\" in\n+\t'')\n+\t\techo \"Added $4 in both, but differently.\"\n+\t\torig=`git-unpack-file $2`\n+\t\t: >$orig\n+\t\t;;\n+\t*)\n+\t\techo \"Auto-merging $4.\"\n+\t\torig=`git-unpack-file $1`\n+\t\t;;\n+\tesac\n \tsrc2=`git-unpack-file $3`\n \n \t# We reset the index to the first branch, making\n@@ -73,6 +82,9 @@ case \"${1:-.}${2:-.}${3:-.}\" in\n \t\techo \"ERROR: Permissions conflict: $5->$6,$7.\"\n \t\tret=1\n \tfi\n+\tif [ \"$1\" = '' ]; then\n+\t\tret=1\n+\tfi\n \n \tif [ $ret -ne 0 ]; then\n \t\techo \"ERROR: Merge conflict in $4.\"\n"},{"id":"11313","messageId":"20051108095600.GA1431@pasky.or.cz","threadId":"2394","inReplyTo":"7vwtjjllw4.fsf@assigned-by-dhcp.cox.net","subject":"Re: Expected Behavior?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-08T09:56:00Z","receivedAt":"2005-11-08T09:56:00Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Nov 08, 2005 at 07:00:11AM CET, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n> Nobody complained so far about this, probably because two side\n> adding different versions is rare enough.  And the reasoning\n> behind the current behaviour is probably because the tool cannot\n> automerge them sensibly anyway.  Leaving the SHA1 in index file\n> might probably be easier to clean up by hand (e.g. see ls-files\n> --unmerged, and cut&paste the desired SHA1 to 'git-cat-file\n> blob' command line, or something silly like that).  But if we\n> were to go that route, adding --stage=[123] flag so that the\n> user can say 'git-checkout-index --stage=3 file3'might have\n> helped a bit more.\n\n#\n# Added in both (different in each).\n#\n\".$id1$id2\")\n        #echo \"Adding $file\"\n        filev=\"$file\"\n        while [ -e \"$filev~1\" ] || [ -e \"$filev~2\" ]; do\n                filev=\"$filev~\"\n        done\n        error \"File $file added in both branches, but different in each!\"\n        error \"Conflicting versions saved as '$filev~1' and '$filev~2'.\"\n        git-update-index --add --cacheinfo \"$mode1\" \"$id1\" \"$file\" &&\n                git-checkout-index -u -f -- \"$file\" &&\n                mv \"$file\" \"$filev~1\" ||\n                error \"Cannot create '$filev~1'\"\n        git-update-index --add --cacheinfo \"$mode2\" \"$id2\" \"$file\" &&\n                git-checkout-index -u -f -- \"$file\" &&\n                mv \"$file\" \"$filev~2\" ||\n                error \"Cannot create '$filev~2'\"\n        exit 1\n        ;;\n\nis what Cogito's automerger does. It ain't very pretty, but it works.\n:-) (At least it seems to.) I yet need to add some conflicts tracking to\nCogito to prevent accidental checking in of conflicts.\n\n> We could instead use the attached patch to get the behaviour you\n> are expecting.  I have a feeling that the result from this might\n> be a little more intuitive and easier to resolve by hand than\n> the current one.  Although we may end up unresolvable mess in\n> file3 if either side is binary, in that case the user can still\n> sift through 'diff-tree A B file3' output to find out the\n> relevant SHA1 to recover the blobs from both sides by hand\n> anyway.  Does anybody have strong opinion on this?\n\nI think having\n\n\t<<<<<\n\tfile1\n\t=====\n\tfile2\n\t>>>>>\n\nis an awful PITA to resolve, especially when the files actually are\nsimilar. Running some vimdiff (or just diff and possibly applying either\nway) on two separate files is much more convenient.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11347","messageId":"20051108210332.GB23265@c165.ib.student.liu.se","threadId":"2394","inReplyTo":"7vwtjjllw4.fsf@assigned-by-dhcp.cox.net","subject":"Re: Expected Behavior?","fromName":"Fredrik Kuivinen","fromEmail":"freku045@student.liu.se","sentAt":"2005-11-08T21:03:32Z","receivedAt":"2005-11-08T21:03:32Z","isPatch":false,"sender":{"key":"frekui@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13770967?v=4"},"body":"On Mon, Nov 07, 2005 at 10:00:11PM -0800, Junio C Hamano wrote:\n> Jon Loeliger <jdl@freescale.com> writes:\n> \n> > That is, after the merge, file3 appears to have simply kept\n> > the contents of the current, master branch.  Why wasn't the\n> > dev branch represented here?\n> >\n> > I _almost_ think I get it, and then *poof*...\n> \n> Automerge completely punted for this path, and at this point, it\n> is still unmerged:\n> \n> ------------\n> $ git ls-files --unmerged\n> 100644 c4da0eb.... 2       file3\n> 100644 fbc2aa4.... 3       file3\n> ------------\n> \n> Three-way \"git-read-tree -m -u O A B\" (O is for old, A is ours\n> and B is hers) puts O in stage1, A in stage2 and B in stage3.\n> This path did not exist in O so we only have them in stage2 and\n> stage3.  You could compare the stages like this:\n> \n\nJon: You could try to this merge with the recursive merge strategy\n(git merge -s recursive 'merge message' master dev) If you do, you\n_should_ get something like:\n\n    CONFLICT (add/add): File file3 added non-identically in both\n    branches. Adding as file3_master and file3_dev instead.\n\nYou will then end up with file3_master and file3_dev in your working\ntree, which corresponds to file3 in the master branch and file3 in the\ndev branch, respectively.\n\n\n- Fredrik\n"},{"id":"11349","messageId":"7v7jbig6m7.fsf@assigned-by-dhcp.cox.net","threadId":"2394","inReplyTo":"20051108210332.GB23265@c165.ib.student.liu.se","subject":"Re: Expected Behavior?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-08T21:41:20Z","receivedAt":"2005-11-08T21:41:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Fredrik Kuivinen <freku045@student.liu.se> writes:\n\n> Jon: You could try to this merge with the recursive merge strategy\n> (git merge -s recursive 'merge message' master dev) If you do, you\n> _should_ get something like:\n>\n>     CONFLICT (add/add): File file3 added non-identically in both\n>     branches. Adding as file3_master and file3_dev instead.\n>\n> You will then end up with file3_master and file3_dev in your working\n> tree, which corresponds to file3 in the master branch and file3 in the\n> dev branch, respectively.\n\nOops, I missed that part.  This is unsafe in theory, if you\ncould overwrite existing file3_master or file3_dev.  Does that\nmatter in practice?\n"},{"id":"11355","messageId":"20051108225320.GB4805@c165.ib.student.liu.se","threadId":"2394","inReplyTo":"7v7jbig6m7.fsf@assigned-by-dhcp.cox.net","subject":"Re: Expected Behavior?","fromName":"Fredrik Kuivinen","fromEmail":"freku045@student.liu.se","sentAt":"2005-11-08T22:53:20Z","receivedAt":"2005-11-08T22:53:20Z","isPatch":false,"sender":{"key":"frekui@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13770967?v=4"},"body":"On Tue, Nov 08, 2005 at 01:41:20PM -0800, Junio C Hamano wrote:\n> Fredrik Kuivinen <freku045@student.liu.se> writes:\n> \n> > Jon: You could try to this merge with the recursive merge strategy\n> > (git merge -s recursive 'merge message' master dev) If you do, you\n> > _should_ get something like:\n> >\n> >     CONFLICT (add/add): File file3 added non-identically in both\n> >     branches. Adding as file3_master and file3_dev instead.\n> >\n> > You will then end up with file3_master and file3_dev in your working\n> > tree, which corresponds to file3 in the master branch and file3 in the\n> > dev branch, respectively.\n> \n> Oops, I missed that part.  This is unsafe in theory, if you\n> could overwrite existing file3_master or file3_dev.  Does that\n> matter in practice?\n> \n\nIt wont overwrite any existing files. If there is a file named\n'file3_master' then the new file will be named 'file3_master_1' and if\nthat file also exists the new file will be named 'file3_master_2', and\nso on.\n\n- Fredrik\n"},{"id":"11376","messageId":"7vmzkenzcx.fsf@assigned-by-dhcp.cox.net","threadId":"2394","inReplyTo":"20051108225320.GB4805@c165.ib.student.liu.se","subject":"Re: Expected Behavior?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-09T05:50:54Z","receivedAt":"2005-11-09T05:50:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Fredrik Kuivinen <freku045@student.liu.se> writes:\n\n>> Oops, I missed that part.  This is unsafe in theory, if you\n>> could overwrite existing file3_master or file3_dev.  Does that\n>> matter in practice?\n>\n> It wont overwrite any existing files. If there is a file named\n> 'file3_master' then the new file will be named 'file3_master_1' and if\n> that file also exists the new file will be named 'file3_master_2', and\n> so on.\n\nAnother thing to watch out is that a branch name could have a\nslash in it.  It might make more sense to just name the heads file3~2\nor file3~3 (with as many ~s repeated to avoid name clashes) like\nPasky does.\n"},{"id":"11381","messageId":"20051109081906.GA4960@c165.ib.student.liu.se","threadId":"2394","inReplyTo":"7vmzkenzcx.fsf@assigned-by-dhcp.cox.net","subject":"Re: Expected Behavior?","fromName":"Fredrik Kuivinen","fromEmail":"freku045@student.liu.se","sentAt":"2005-11-09T08:19:06Z","receivedAt":"2005-11-09T08:19:06Z","isPatch":false,"sender":{"key":"frekui@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13770967?v=4"},"body":"On Tue, Nov 08, 2005 at 09:50:54PM -0800, Junio C Hamano wrote:\n> Fredrik Kuivinen <freku045@student.liu.se> writes:\n> \n> >> Oops, I missed that part.  This is unsafe in theory, if you\n> >> could overwrite existing file3_master or file3_dev.  Does that\n> >> matter in practice?\n> >\n> > It wont overwrite any existing files. If there is a file named\n> > 'file3_master' then the new file will be named 'file3_master_1' and if\n> > that file also exists the new file will be named 'file3_master_2', and\n> > so on.\n> \n> Another thing to watch out is that a branch name could have a\n> slash in it.  It might make more sense to just name the heads file3~2\n> or file3~3 (with as many ~s repeated to avoid name clashes) like\n> Pasky does.\n> \n\nOups, I haven't thought about that. I kind of like the idea that you\ncan see the branch name in the file names though. How about replacing\nany slashes in the branch names with underscores? So the branch\n'foo/bar' will give rise to files with suffixes like '_foo_bar' and\n'_foo_bar_<number>'.\n\n- Fredrik\n"},{"id":"11384","messageId":"20051109104257.GC4960@c165.ib.student.liu.se","threadId":"2394","inReplyTo":"20051109081906.GA4960@c165.ib.student.liu.se","subject":"[PATCH] merge-recursive: Fix support for branch names containing slashes","fromName":"Fredrik Kuivinen","fromEmail":"freku045@student.liu.se","sentAt":"2005-11-09T10:42:57Z","receivedAt":"2005-11-09T10:42:57Z","isPatch":true,"sender":{"key":"frekui@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13770967?v=4"},"body":"On Wed, Nov 09, 2005 at 09:19:06AM +0100, Fredrik Kuivinen wrote:\n> On Tue, Nov 08, 2005 at 09:50:54PM -0800, Junio C Hamano wrote:\n> > Fredrik Kuivinen <freku045@student.liu.se> writes:\n> > \n> > >> Oops, I missed that part.  This is unsafe in theory, if you\n> > >> could overwrite existing file3_master or file3_dev.  Does that\n> > >> matter in practice?\n> > >\n> > > It wont overwrite any existing files. If there is a file named\n> > > 'file3_master' then the new file will be named 'file3_master_1' and if\n> > > that file also exists the new file will be named 'file3_master_2', and\n> > > so on.\n> > \n> > Another thing to watch out is that a branch name could have a\n> > slash in it.  It might make more sense to just name the heads file3~2\n> > or file3~3 (with as many ~s repeated to avoid name clashes) like\n> > Pasky does.\n> > \n> \n> Oups, I haven't thought about that. I kind of like the idea that you\n> can see the branch name in the file names though. How about replacing\n> any slashes in the branch names with underscores? So the branch\n> 'foo/bar' will give rise to files with suffixes like '_foo_bar' and\n> '_foo_bar_<number>'.\n> \n\nAnd here is a patch to implement this. Should apply cleanly on top of\n'[PATCH] merge-recursive: Fix limited output of rename messages'.\n\n---\n\nSigned-off-by: Fredrik Kuivinen <freku045@student.liu.se>\n\n\n---\n\n git-merge-recursive.py |    1 +\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\napplies-to: 1dd8c1800d7dd0425bc93f4c9441acfb207b1488\n795e2900e8804af53263821c177a270cd2d7c2c0\ndiff --git a/git-merge-recursive.py b/git-merge-recursive.py\nindex 3657875..90e889c 100755\n--- a/git-merge-recursive.py\n+++ b/git-merge-recursive.py\n@@ -295,6 +295,7 @@ def uniquePath(path, branch):\n             else:\n                 raise\n \n+    branch = branch.replace('/', '_')\n     newPath = path + '_' + branch\n     suffix = 0\n     while newPath in currentFileSet or \\\n---\n0.99.9.GIT\n"},{"id":"11387","messageId":"20051109112452.GD30496@pasky.or.cz","threadId":"2394","inReplyTo":"20051108210332.GB23265@c165.ib.student.liu.se","subject":"Re: Expected Behavior?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-09T11:24:52Z","receivedAt":"2005-11-09T11:24:52Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Nov 08, 2005 at 10:03:32PM CET, I got a letter\nwhere Fredrik Kuivinen <freku045@student.liu.se> said that...\n> On Mon, Nov 07, 2005 at 10:00:11PM -0800, Junio C Hamano wrote:\n> > Jon Loeliger <jdl@freescale.com> writes:\n> > \n> > > That is, after the merge, file3 appears to have simply kept\n> > > the contents of the current, master branch.  Why wasn't the\n> > > dev branch represented here?\n> > >\n> > > I _almost_ think I get it, and then *poof*...\n> > \n> > Automerge completely punted for this path, and at this point, it\n> > is still unmerged:\n> > \n> > ------------\n> > $ git ls-files --unmerged\n> > 100644 c4da0eb.... 2       file3\n> > 100644 fbc2aa4.... 3       file3\n> > ------------\n> > \n> > Three-way \"git-read-tree -m -u O A B\" (O is for old, A is ours\n> > and B is hers) puts O in stage1, A in stage2 and B in stage3.\n> > This path did not exist in O so we only have them in stage2 and\n> > stage3.  You could compare the stages like this:\n> > \n> \n> Jon: You could try to this merge with the recursive merge strategy\n> (git merge -s recursive 'merge message' master dev) If you do, you\n> _should_ get something like:\n> \n>     CONFLICT (add/add): File file3 added non-identically in both\n>     branches. Adding as file3_master and file3_dev instead.\n> \n> You will then end up with file3_master and file3_dev in your working\n> tree, which corresponds to file3 in the master branch and file3 in the\n> dev branch, respectively.\n\nThe world would be so much better if there would be just a _single_\nper-file automerger instead of three right now...\n\nI'm planning to feed back the automerger stuff from Cogito to GIT like I\nalready did once, but it's not a priority right now so it may take some\ntime (unless someone else does it, which is something I certainly\nwouldn't oppose).\n\nBut in the longer term even the recursive merge should use the same one,\nso either we should enhance the shell one to handle all the cases, or\nsplit out the python per-file automerger from recursive merge and make\nit possible to use this one separately. This is probably more viable\noption in the longer term, even though I personally don't grok python\nvery well - whatever, at least I'll have to get better. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11423","messageId":"46a038f90511091504l7218df18k251bec75491891e9@mail.gmail.com","threadId":"2394","inReplyTo":"20051109112452.GD30496@pasky.or.cz","subject":"Re: Expected Behavior?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-11-09T23:04:11Z","receivedAt":"2005-11-09T23:04:11Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 11/10/05, Petr Baudis <pasky@suse.cz> wrote:\n> The world would be so much better if there would be just a _single_\n> per-file automerger instead of three right now...\n\nI don't quite agree with this. The multi-merger mechanism is something\n(relatively) unique and powerful in GIT. Having fast+stupid, with\nfallback to slow+smart is an excellent strategy, and having the\nmechanism in place means that if someone is crazy enough to write a\nsmarter merge script for a language or a particular project (say, to\nease the transition to a new directory layout) it is entirely\npossible.\n\nIn the end, merges are tricky and need to be controlled by the end\nuser. We can help this giving the user good control and good\nvisibility of what decisions the merger is taking.\n\n> I'm planning to feed back the automerger stuff from Cogito to GIT like I\n> already did once.\n\nI use both mergers (cg and git) and I'd really _really_ like to turn\ncg-merge into a wrapper for git-merge. The cg merger does the basics:\ntrivial merge, fast forwards and diff3 merges. Adding the rest is\n_hard_ and debugging/auditing it is even harder. IMHO, having strong,\nhigh quality mergers is a must, and it's a complex enough space that a\nporcelain should align itself with git so we get a strong set of\nmergers done in a way that all porcelains can hook into.\n\nI made an initial half-attempt but it's trickier that I had expected\nbecause cg-merge relies on cg-commit to wrap up, marke the index as\nresolved, and commit, and I'm not entirely sure of how that works in\ndetail. My changes were going in the direction of breaking the current\nusage patterns, so it was a no-go really.\n\ncheers,\n\n\nmartin\n"},{"id":"11426","messageId":"20051109231248.GL16061@pasky.or.cz","threadId":"2394","inReplyTo":"46a038f90511091504l7218df18k251bec75491891e9@mail.gmail.com","subject":"Re: Expected Behavior?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-09T23:12:48Z","receivedAt":"2005-11-09T23:12:48Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Nov 10, 2005 at 12:04:11AM CET, I got a letter\nwhere Martin Langhoff <martin.langhoff@gmail.com> said that...\n> On 11/10/05, Petr Baudis <pasky@suse.cz> wrote:\n> > The world would be so much better if there would be just a _single_\n> > per-file automerger instead of three right now...\n> \n> I don't quite agree with this. The multi-merger mechanism is something\n> (relatively) unique and powerful in GIT.\n\nI'm not talking about mechanism but about the recommended policy (if you\nhave something better, fine, use it - just keep _one_ default one\ninstead of three, since this doesn't have anything or much to do with\nthe actual merge strategy). Besides,\n\n> Having fast+stupid, with fallback to slow+smart is an excellent\n> strategy, and having the mechanism in place means that if someone is\n> crazy enough to write a smarter merge script for a language or a\n> particular project (say, to ease the transition to a new directory\n> layout) it is entirely possible.\n\nwhat mechanism are you talking about? All the scripts have it hardcoded\nwhat to use, it seems - cg-Xmergefile, git-merge-one-file or some\nsubroutine...\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11432","messageId":"7virv18kc3.fsf@assigned-by-dhcp.cox.net","threadId":"2394","inReplyTo":"46a038f90511091504l7218df18k251bec75491891e9@mail.gmail.com","subject":"Re: Expected Behavior?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-09T23:36:44Z","receivedAt":"2005-11-09T23:36:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Langhoff <martin.langhoff@gmail.com> writes:\n\n> On 11/10/05, Petr Baudis <pasky@suse.cz> wrote:\n>> The world would be so much better if there would be just a _single_\n>> per-file automerger instead of three right now...\n>\n> I don't quite agree with this. The multi-merger mechanism is something\n> (relatively) unique and powerful in GIT.\n\nIf I am reading you two correctly, you are not disagreeing, but\nare talking about different issues.\n\nPasky is talking about what to do after merge strategy finds\nthat a path (from three stages) needs to be merged.  git-core\nuses git-merge-one-file or git-merge-recursive::mergeFile (which\nare the implementations of the same logic), and Pasky has his\nown in Cogito.\n\nFredrik's using his own mergeFile is defensible from both\nperformance and implementation point of view.  After the rename\nprocessing stage, he already extracted enough information from\ntrees involved, and there is no reason for him to be preparing\nthree stages in the index file with that information (which is\ncumbersome because there is no interface to populate the higher\nstage directly using git-update-index --- you have to first\ncreate temporary tree objects and ask git-read-tree -m to do so)\nand asking git-merge-index to call git-merge-one-file.  If you\nread git-merge-one-file, it is not a rocket science.  While we\n_may_ want to keep the logic that decides what to do in various\ncases across these three implementations, at least for me, it\ndoes not particularly feel disturbing, especially when there are\ngood reasons.\n"},{"id":"11434","messageId":"20051109234212.GJ30496@pasky.or.cz","threadId":"2394","inReplyTo":"7virv18kc3.fsf@assigned-by-dhcp.cox.net","subject":"Re: Expected Behavior?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-09T23:42:12Z","receivedAt":"2005-11-09T23:42:12Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Nov 10, 2005 at 12:36:44AM CET, I got a letter\nwhere Junio C Hamano <junkio@cox.net> said that...\n> Fredrik's using his own mergeFile is defensible from both\n> performance and implementation point of view.  After the rename\n> processing stage, he already extracted enough information from\n> trees involved, and there is no reason for him to be preparing\n> three stages in the index file with that information (which is\n> cumbersome because there is no interface to populate the higher\n> stage directly using git-update-index --- you have to first\n> create temporary tree objects and ask git-read-tree -m to do so)\n> and asking git-merge-index to call git-merge-one-file.  If you\n> read git-merge-one-file, it is not a rocket science.\n\nI'm not arguing against mergeFile but rather git-merge-one-file (and by\nimplication cg-Xmergefile), actually. My point is - couldn't be\nmergeFile generalized a bit or padded with suitable interface to be\nusable as git-merge-one-file's drop-in replacement?\n\n> While we _may_ want to keep the logic that decides what to do in\n> various cases across these three implementations, at least for me, it\n> does not particularly feel disturbing, especially when there are good\n> reasons.\n\nI'm not sure I follow you here - what exactly does not feel disturbing\nand what good reasons are there for whatever they are? :-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11436","messageId":"46a038f90511091543h520f6a84k3e3b14c2e502989f@mail.gmail.com","threadId":"2394","inReplyTo":"20051109231248.GL16061@pasky.or.cz","subject":"Re: Expected Behavior?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-11-09T23:43:04Z","receivedAt":"2005-11-09T23:43:04Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 11/10/05, Petr Baudis <pasky@suse.cz> wrote:\n> what mechanism are you talking about?\n\nI suspect you haven't seen the git-merge mechanism in action -- or\nperhaps I'm a bit lost and we're talking about different things. At\nleast last time I merged with git-merge.sh, it tried several\nstrategies in order in a temporary index. Actually, it tried in order:\nstupid, resolve, recursive... It shortcuts if one merges cleanly, but\nit'll definitely work through them. It's very nice to see this in\naction.\n\n> All the scripts have it hardcoded\n\nWell, no. git-merge -s 'foo' works pretty well and isn't hardcoded.\nEven if we agree on defaulting to only one relatively smart merger for\nsimplicity's sake, the mechanism we have in git-merge.sh (thanks to\nJunio I think) is excellent, and should be kept. Linus will probably\ndo his merges with \"stupid resolve\" or just \"stupid\" and the rest of\nus will use something else.\n\nThe mergers and things like git-merge-base are probably the areas of\ngit that need the most focus and polish -- that's why I'm\nuncomfortable with cg-merge doing its own thing, as it gets a lot less\nreview than git-merge-XX resolvers.\n\nRight now I am seeing some slightly abnormal things (*) in how some\nour our merges are going, so I' ll have to roll up my sleeves at some\npoint and try and figure out what's going on. And as I look into\ncg-merge and cg-Xmergefile, not many eyes have been through it...\n\n* - (nothing serious, just an annoying tendency to show spurious\nconflicts with the mergebase commit itself)\n\ncheers,\n\n\nmartin\n"},{"id":"11439","messageId":"20051109234925.GL30496@pasky.or.cz","threadId":"2394","inReplyTo":"46a038f90511091543h520f6a84k3e3b14c2e502989f@mail.gmail.com","subject":"Re: Expected Behavior?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-09T23:49:25Z","receivedAt":"2005-11-09T23:49:25Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Nov 10, 2005 at 12:43:04AM CET, I got a letter\nwhere Martin Langhoff <martin.langhoff@gmail.com> said that...\n> On 11/10/05, Petr Baudis <pasky@suse.cz> wrote:\n> > what mechanism are you talking about?\n> \n> I suspect you haven't seen the git-merge mechanism in action -- or\n> perhaps I'm a bit lost and we're talking about different things. At\n> least last time I merged with git-merge.sh, it tried several\n> strategies in order in a temporary index. Actually, it tried in order:\n> stupid, resolve, recursive... It shortcuts if one merges cleanly, but\n> it'll definitely work through them. It's very nice to see this in\n> action.\n\nBut that's something different that I'm talking about. :-)\n\nAs I said, I'm talking about per-file automergers. git-merge-one-file\nand that stuff. I know about merge strategies and they are cool.\n\n> The mergers and things like git-merge-base are probably the areas of\n> git that need the most focus and polish -- that's why I'm\n> uncomfortable with cg-merge doing its own thing, as it gets a lot less\n> review than git-merge-XX resolvers.\n\nYes. My longer plan is to use the strategy resolvers as well, but my\nTODO list is big... And I don't perceive this as a critical thing (the\nstandard strategy seems to work well enough), although I would like to\nsee this before 1.0.\n\n> Right now I am seeing some slightly abnormal things (*) in how some\n> our our merges are going, so I' ll have to roll up my sleeves at some\n> point and try and figure out what's going on. And as I look into\n> cg-merge and cg-Xmergefile, not many eyes have been through it...\n\nAt least this is the one area of Cogito that has at least a bit\nreasonable automated testing suite. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11441","messageId":"7vacgd8j3h.fsf@assigned-by-dhcp.cox.net","threadId":"2394","inReplyTo":"20051109234212.GJ30496@pasky.or.cz","subject":"Re: Expected Behavior?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-10T00:03:30Z","receivedAt":"2005-11-10T00:03:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> I'm not sure I follow you here - what exactly does not feel disturbing\n> and what good reasons are there for whatever they are? :-)\n\nMy misunderstanding, I guess.  I somehow thought you were\nsuggesting that recursive should implement mergeFile through\nmerge-index.  Going the other way, to make the current\nmerge-index users to feed mergeFile with what is stored as three\nstages in an index file, would make a lot more sense.\n"},{"id":"11452","messageId":"46a038f90511091847t70567e50o2303f1dc7ada2464@mail.gmail.com","threadId":"2394","inReplyTo":"20051109234925.GL30496@pasky.or.cz","subject":"Re: Expected Behavior?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-11-10T02:47:38Z","receivedAt":"2005-11-10T02:47:38Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 11/10/05, Petr Baudis <pasky@suse.cz> wrote:\n> But that's something different that I'm talking about. :-)\n\nAck! Sorry about that!\n\n> Yes. My longer plan is to use the strategy resolvers as well, but my\n> TODO list is big... And I don't perceive this as a critical thing (the\n> standard strategy seems to work well enough), although I would like to\n> see this before 1.0.\n\nFair enough. If you can outline how the interaction between cg-merge\nand cg-commit are expected to work, I'll try and find some time for\nthat.\n\n> > Right now I am seeing some slightly abnormal things (*) in how some\n> > our our merges are going, so I' ll have to roll up my sleeves at some\n> > point and try and figure out what's going on. And as I look into\n> > cg-merge and cg-Xmergefile, not many eyes have been through it...\n>\n> At least this is the one area of Cogito that has at least a bit\n> reasonable automated testing suite. ;-)\n\nThe good news is that git-merge is doing almost the same. Posted separately...\n\n\nmartin\n"},{"id":"11453","messageId":"7v64r16ro9.fsf_-_@assigned-by-dhcp.cox.net","threadId":"2394","inReplyTo":"20051108095600.GA1431@pasky.or.cz","subject":"merge-one-file: use common as base, instead of emptiness.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-10T04:41:10Z","receivedAt":"2005-11-10T04:41:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> I think having\n>\n> \t<<<<<\n> \tfile1\n> \t=====\n> \tfile2\n> \t>>>>>\n>\n> is an awful PITA to resolve, especially when the files actually are\n> similar. Running some vimdiff (or just diff and possibly applying either\n> way) on two separate files is much more convenient.\n\nYou are right.\n\nHow about something like this?  This adds a specialized hackery\nflag, --no-add, to git-apply, and uses it to compute common base\nto be used for 2-file merge, instead of using /dev/null.\n\nOn top of the previous round.\n\n -- >8 -- cut here -- >8 --\nUnlike the previous round that merged the path added differently\nin each branches using emptiness as the base, compute a common\nversion and use it as input to 'merge' program.\n\nThis would show the resulting (still conflicting) file left in\nthe working tree as:\n\n\tcommon file contents...\n\t<<<<<< FILENAME\n\tversion from our branch...\n\t======\n\tversion from their branch...\n\t>>>>>> .merge_file_XXXXXX\n\tmore common file contents...\n\nwhen both sides added similar contents.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n\n---\n\n apply.c               |   11 +++++++++--\n git-merge-one-file.sh |    6 ++++--\n 2 files changed, 13 insertions(+), 4 deletions(-)\n\napplies-to: 75c7cdf0addfcb4df5ed093f9b57bb98432489e1\nf158ab58fd3846a784805849bd9228bf060e4b2d\ndiff --git a/apply.c b/apply.c\nindex 3e53b34..7584888 100644\n--- a/apply.c\n+++ b/apply.c\n@@ -23,6 +23,7 @@ static int numstat = 0;\n static int summary = 0;\n static int check = 0;\n static int apply = 1;\n+static int no_add = 0;\n static int show_index_info = 0;\n static int line_termination = '\\n';\n static const char apply_usage[] =\n@@ -1099,8 +1100,10 @@ static int apply_one_fragment(struct buf\n \t\t\t\tbreak;\n \t\t/* Fall-through for ' ' */\n \t\tcase '+':\n-\t\t\tmemcpy(new + newsize, patch + 1, plen);\n-\t\t\tnewsize += plen;\n+\t\t\tif (*patch != '+' || !no_add) {\n+\t\t\t\tmemcpy(new + newsize, patch + 1, plen);\n+\t\t\t\tnewsize += plen;\n+\t\t\t}\n \t\t\tbreak;\n \t\tcase '@': case '\\\\':\n \t\t\t/* Ignore it, we already handled it */\n@@ -1697,6 +1700,10 @@ int main(int argc, char **argv)\n \t\t\texcludes = x;\n \t\t\tcontinue;\n \t\t}\n+\t\tif (!strcmp(arg, \"--no-add\")) {\n+\t\t\tno_add = 1;\n+\t\t\tcontinue;\n+\t\t}\n \t\tif (!strcmp(arg, \"--stat\")) {\n \t\t\tapply = 0;\n \t\t\tdiffstat = 1;\ndiff --git a/git-merge-one-file.sh b/git-merge-one-file.sh\nindex 32e17cb..d9ee458 100755\n--- a/git-merge-one-file.sh\n+++ b/git-merge-one-file.sh\n@@ -57,18 +57,20 @@ case \"${1:-.}${2:-.}${3:-.}\" in\n # Modified in both, but differently.\n #\n \"$1$2$3\" | \".$2$3\")\n+\tsrc2=`git-unpack-file $3`\n \tcase \"$1\" in\n \t'')\n \t\techo \"Added $4 in both, but differently.\"\n+\t\t# This extracts OUR file in $orig, and uses git-apply to\n+\t\t# remove lines that are unique to ours.\n \t\torig=`git-unpack-file $2`\n-\t\t: >$orig\n+\t\tdiff -u -La/$orig -Lb/$orig $orig $src2 | git-apply --no-add \n \t\t;;\n \t*)\n \t\techo \"Auto-merging $4.\"\n \t\torig=`git-unpack-file $1`\n \t\t;;\n \tesac\n-\tsrc2=`git-unpack-file $3`\n \n \t# We reset the index to the first branch, making\n \t# git-diff-file useful\n---\n0.99.9.GIT\n"},{"id":"11500","messageId":"20051110193430.GU30496@pasky.or.cz","threadId":"2394","inReplyTo":"46a038f90511091847t70567e50o2303f1dc7ada2464@mail.gmail.com","subject":"Re: Expected Behavior?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-10T19:34:30Z","receivedAt":"2005-11-10T19:34:30Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Nov 10, 2005 at 03:47:38AM CET, I got a letter\nwhere Martin Langhoff <martin.langhoff@gmail.com> said that...\n> On 11/10/05, Petr Baudis <pasky@suse.cz> wrote:\n> > Yes. My longer plan is to use the strategy resolvers as well, but my\n> > TODO list is big... And I don't perceive this as a critical thing (the\n> > standard strategy seems to work well enough), although I would like to\n> > see this before 1.0.\n> \n> Fair enough. If you can outline how the interaction between cg-merge\n> and cg-commit are expected to work, I'll try and find some time for\n> that.\n\nWell, basically like right now ;-).\n\nMerging is a two-stage process, where the two stages are isolated and\nthe latter does not interfere with the former. The former one is doing\nthe actual content merge, and that's what cg-merge does. The latter one\nis recording the merge in history, and that's what cg-commit does.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11503","messageId":"20051110194317.GV30496@pasky.or.cz","threadId":"2394","inReplyTo":"7v64r16ro9.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: merge-one-file: use common as base, instead of emptiness.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-10T19:43:17Z","receivedAt":"2005-11-10T19:43:17Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Nov 10, 2005 at 05:41:10AM CET, I got a letter\nwhere Junio C Hamano <junkio@cox.net> said that...\n> Petr Baudis <pasky@suse.cz> writes:\n> \n> > I think having\n> >\n> > \t<<<<<\n> > \tfile1\n> > \t=====\n> > \tfile2\n> > \t>>>>>\n> >\n> > is an awful PITA to resolve, especially when the files actually are\n> > similar. Running some vimdiff (or just diff and possibly applying either\n> > way) on two separate files is much more convenient.\n> \n> You are right.\n> \n> How about something like this?  This adds a specialized hackery\n> flag, --no-add, to git-apply, and uses it to compute common base\n> to be used for 2-file merge, instead of using /dev/null.\n\nWow, astonishingly simple.\n\n>  -- >8 -- cut here -- >8 --\n> Unlike the previous round that merged the path added differently\n> in each branches using emptiness as the base, compute a common\n> version and use it as input to 'merge' program.\n> \n> This would show the resulting (still conflicting) file left in\n> the working tree as:\n> \n> \tcommon file contents...\n> \t<<<<<< FILENAME\n> \tversion from our branch...\n> \t======\n> \tversion from their branch...\n> \t>>>>>> .merge_file_XXXXXX\n> \tmore common file contents...\n> \n> when both sides added similar contents.\n\nBut obviously now the trouble is opposite, when the files are completely\nunrelated, since now you likely get large conflicting areas interleaved\nwith some scarce common lines... And this might get to be a big PITA to\nresolve as well.\n\nThat said, I still really like --no-add and it would be heart-wrenching\nto just coldly dismiss it. It is a great tool, but I would let the user\nto use it manually. Possibly something like\n\n\tgit-twofile-merge foo~1 foo~2\n\n(the name is stupid, obviously) or a button in some GUI tool.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11505","messageId":"46a038f90511101154p4ef99cddv82d56272921a80ac@mail.gmail.com","threadId":"2394","inReplyTo":"20051110193430.GU30496@pasky.or.cz","subject":"Re: Expected Behavior?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-11-10T19:54:43Z","receivedAt":"2005-11-10T19:54:43Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 11/11/05, Petr Baudis <pasky@suse.cz> wrote:\n> Well, basically like right now ;-).\n\nExactly. Which isn't documented, and has several subtleties that I\ndon't know of.\n\n> Merging is a two-stage process, where the two stages are isolated and\n> the latter does not interfere with the former. The former one is doing\n> the actual content merge, and that's what cg-merge does. The latter one\n> is recording the merge in history, and that's what cg-commit does.\n\nThere are some semantics to exchange info between cg-merge and\ncg-commit and for handling the index while the user is resolving\nconflicts or reviewing the merge before committing. I'm not familiar\nwith them, and I'm unsure what the design is...\n\n - how do cg-merge and cg-commit pass around the parents, commit msg,\nfiles being merged vs dirty files on tree, etc? (easy: those lowercase\ntemp files in .git)\n - how do you run cg-status/cg-diff without messing up the index? does\nrunning cg-status or cg-diff stand any risk of accidentally marking\nfor inclusion dirty files that are not part of the merge? hopefully\nnot, and then what's the technique?\n - should cg-status show more about the status of the index ?\n - how does cg-commit know whether conflicts have been resolved at\nall? (perhaps it doesn't even try!)\n - how do you reset the 'we are merging' status?\n\nAnyway, that's off the top of my head, and probably shows you that I'm\nnot 200% familiar with all the tricks available for handling the\nindex.\n\ncheers,\n\n\n\nmartin\n"},{"id":"11508","messageId":"20051110201027.GW30496@pasky.or.cz","threadId":"2394","inReplyTo":"46a038f90511101154p4ef99cddv82d56272921a80ac@mail.gmail.com","subject":"Re: Expected Behavior?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-10T20:10:28Z","receivedAt":"2005-11-10T20:10:28Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Nov 10, 2005 at 08:54:43PM CET, I got a letter\nwhere Martin Langhoff <martin.langhoff@gmail.com> said that...\n> On 11/11/05, Petr Baudis <pasky@suse.cz> wrote:\n> > Well, basically like right now ;-).\n> \n> Exactly. Which isn't documented, and has several subtleties that I\n> don't know of.\n\nYes - from the user standpoint it is supposed to be a foolproof (for a\nreasonable value of 'fool') and should always guide you around. From a\ndeveloper's standpoint it might not be entirely crystal-clear, though.\n;-)\n\n> There are some semantics to exchange info between cg-merge and\n> cg-commit and for handling the index while the user is resolving\n> conflicts or reviewing the merge before committing. I'm not familiar\n> with them, and I'm unsure what the design is...\n\nThe design is \"keep arbitrary bunch of files in .git recording our state\nwrt. merging\". I want to tidy that up and keep all that in\n.git/cg-merge-state/ or something.\n\n>  - how do cg-merge and cg-commit pass around the parents, commit msg,\n> files being merged vs dirty files on tree, etc? (easy: those lowercase\n> temp files in .git)\n\nYes, lowercase temp files. Well, the commit msg itself is composed only\nin cg-commit.\n\n>  - how do you run cg-status/cg-diff without messing up the index? does\n> running cg-status or cg-diff stand any risk of accidentally marking\n> for inclusion dirty files that are not part of the merge? hopefully\n> not, and then what's the technique?\n\ncg-status and cg-diff are safe anytime, being basically read-only\ncommands wrt. the interesting index information.\n\nWell, they _do_ touch your index (but only modifying the stat\ninformation), and that may get you into some trouble, but only in case\nof some seemingly quite rare permission problem, I think (and that will\ntrash your index anytime, not just during a merge). There was a thread\nabout that about a month or two ago, IIRC.\n\n>  - should cg-status show more about the status of the index ?\n\nIn what sense? It shows if merge is in progress. It doesn't show\nconflicts, but that's because...\n\n>  - how does cg-commit know whether conflicts have been resolved at\n> all? (perhaps it doesn't even try!)\n\n...we don't actually track them yet. That's considered a bug, I want to\nfix it, and it even has some non-zero priority.\n\n>  - how do you reset the 'we are merging' status?\n\ncg-reset (except when you were merging over a dirty state; hmm, we don't\nhave a direct command for cancelling that, it seems).\n\ncg-merge will now hint you about cg-reset.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11510","messageId":"7vk6fgxn28.fsf@assigned-by-dhcp.cox.net","threadId":"2394","inReplyTo":"20051110194317.GV30496@pasky.or.cz","subject":"Re: merge-one-file: use common as base, instead of emptiness.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-10T20:30:55Z","receivedAt":"2005-11-10T20:30:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> But obviously now the trouble is opposite, when the files are completely\n> unrelated, since now you likely get large conflicting areas interleaved\n> with some scarce common lines... And this might get to be a big PITA to\n> resolve as well.\n\nYeah, you can always count lines in $orig and $src2 after\ntwo-file merge runs, and if it appears we do not have enough\ncommon section just empty the $orig before running merge.\n"},{"id":"11512","messageId":"20051110203411.GX30496@pasky.or.cz","threadId":"2394","inReplyTo":"20051109081906.GA4960@c165.ib.student.liu.se","subject":"Re: Expected Behavior?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-10T20:34:11Z","receivedAt":"2005-11-10T20:34:11Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Nov 09, 2005 at 09:19:06AM CET, I got a letter\nwhere Fredrik Kuivinen <freku045@student.liu.se> said that...\n> On Tue, Nov 08, 2005 at 09:50:54PM -0800, Junio C Hamano wrote:\n> > Fredrik Kuivinen <freku045@student.liu.se> writes:\n> > \n> > >> Oops, I missed that part.  This is unsafe in theory, if you\n> > >> could overwrite existing file3_master or file3_dev.  Does that\n> > >> matter in practice?\n> > >\n> > > It wont overwrite any existing files. If there is a file named\n> > > 'file3_master' then the new file will be named 'file3_master_1' and if\n> > > that file also exists the new file will be named 'file3_master_2', and\n> > > so on.\n> > \n> > Another thing to watch out is that a branch name could have a\n> > slash in it.  It might make more sense to just name the heads file3~2\n> > or file3~3 (with as many ~s repeated to avoid name clashes) like\n> > Pasky does.\n> > \n> \n> Oups, I haven't thought about that. I kind of like the idea that you\n> can see the branch name in the file names though. How about replacing\n> any slashes in the branch names with underscores? So the branch\n> 'foo/bar' will give rise to files with suffixes like '_foo_bar' and\n> '_foo_bar_<number>'.\n\nI like it too. :-)\n\nNow, this would look like file3~master in Cogito (or file3~~master in\ncase of name conflict, etc.).\n\nThanks for the idea,\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11514","messageId":"20051110203517.GY30496@pasky.or.cz","threadId":"2394","inReplyTo":"7vk6fgxn28.fsf@assigned-by-dhcp.cox.net","subject":"Re: merge-one-file: use common as base, instead of emptiness.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-10T20:35:17Z","receivedAt":"2005-11-10T20:35:17Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Nov 10, 2005 at 09:30:55PM CET, I got a letter\nwhere Junio C Hamano <junkio@cox.net> said that...\n> Petr Baudis <pasky@suse.cz> writes:\n> \n> > But obviously now the trouble is opposite, when the files are completely\n> > unrelated, since now you likely get large conflicting areas interleaved\n> > with some scarce common lines... And this might get to be a big PITA to\n> > resolve as well.\n> \n> Yeah, you can always count lines in $orig and $src2 after\n> two-file merge runs, and if it appears we do not have enough\n> common section just empty the $orig before running merge.\n\nReasonable solution, I like that. Let's say 50%, like for the renames\ndetection?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11523","messageId":"7vzmocw1xd.fsf@assigned-by-dhcp.cox.net","threadId":"2394","inReplyTo":"20051110203411.GX30496@pasky.or.cz","subject":"Re: Expected Behavior?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-10T22:52:46Z","receivedAt":"2005-11-10T22:52:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> Dear diary, on Wed, Nov 09, 2005 at 09:19:06AM CET, I got a letter\n> where Fredrik Kuivinen <freku045@student.liu.se> said that...\n>> On Tue, Nov 08, 2005 at 09:50:54PM -0800, Junio C Hamano wrote:\n>> > Fredrik Kuivinen <freku045@student.liu.se> writes:\n>> > \n>> Oups, I haven't thought about that. I kind of like the idea that you\n>> can see the branch name in the file names though. How about replacing\n>> any slashes in the branch names with underscores? So the branch\n>> 'foo/bar' will give rise to files with suffixes like '_foo_bar' and\n>> '_foo_bar_<number>'.\n>\n> I like it too. :-)\n>\n> Now, this would look like file3~master in Cogito (or file3~~master in\n> case of name conflict, etc.).\n\nOne thing I like about Cogito's is the use of tilde instead of\nunderscore -- much much less likely to clash with real filenames\nand easiliy recognizable as throwaway copies.\n\nOne thing I _don't_ like about both is there is no way for 'git\nreset --hard' to get rid of them, when the user decides to retry\nfrom scratch after seeing a failed merge that left too many of\nthem.\n"},{"id":"11525","messageId":"20051110232210.GC30496@pasky.or.cz","threadId":"2394","inReplyTo":"7vzmocw1xd.fsf@assigned-by-dhcp.cox.net","subject":"Re: Expected Behavior?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-10T23:22:10Z","receivedAt":"2005-11-10T23:22:10Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Nov 10, 2005 at 11:52:46PM CET, I got a letter\nwhere Junio C Hamano <junkio@cox.net> said that...\n> One thing I _don't_ like about both is there is no way for 'git\n> reset --hard' to get rid of them, when the user decides to retry\n> from scratch after seeing a failed merge that left too many of\n> them.\n\nYes. You can cg-clean, but that'll wipe out other stuff as well. I plan\nto fix that by adding some conflicts tracking to Cogito - I'm not yet\ndecided on the particular implementation (only that I certainly don't\nwant to require the user to manually tell Cogito about resolved\nconflicts).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"}]}