{"thread":{"id":"46821","subject":"BUG: merge -s theirs is not in effect (does the same as -s ours)","startedAt":"2017-09-25T00:28:15Z","lastAt":"2018-01-25T04:35:57Z","messageCount":19,"participants":["Yaroslav Halchenko","Junio C Hamano","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"328777","messageId":"20170925000213.rilmsczdbi3jqkta@hopa.kiewit.dartmouth.edu","threadId":"46821","inReplyTo":null,"subject":"BUG: merge -s theirs is not in effect (does the same as -s ours)","fromName":"Yaroslav Halchenko","fromEmail":"yoh@onerussian.com","sentAt":"2017-09-25T00:02:13Z","receivedAt":"2017-09-25T00:28:15Z","isPatch":false,"sender":{"key":"yoh@onerussian.com","avatar":"https://gravatar.com/avatar/8901b82415ae451a83aea49409708912726e53620e3ac92320bf1f86548d97e9?d=mp&s=160"},"body":"My interest was to get remote branch \"merge\" the changes in the branch taking\nthe branch's version (primarily alternative symlinks for git-annex'ed content)\nover the version in master (previous merge of a similar branch).  Unfortunately\n-s theirs seems to do actually -s ours -- symlinks and content is taken from\nthe 'ours' branch instead of theirs.  workaround -- perform -s ours of\nmaster within the branch, and then ff of master to that state:\n\n$> git --version                        \ngit version 2.14.1.729.g59c0ea183a\n\n$> rm -rf /tmp/repo1; mkdir /tmp/repo1; cd /tmp/repo1; git init .; ln -s sym1 link; echo 1 > file; git add file link; git commit -m 'common'; git co -b b1 ; ln -sf b1link link; echo \"b1 file\" >| file; git commit -m 'b2 changes' -a; git co master; ln -sf masterlink link; echo \"master file\" >| file; git commit -m 'also modified in master' -a; git merge -s theirs --no-edit b1; ls -l link; cat file\nE: could not determine git repository root\nwarning: templates not found /home/yoh/share/git-core/templates\nInitialized empty Git repository in /tmp/repo1/.git/\n[master (root-commit) b6a69d0] common\n 2 files changed, 2 insertions(+)\n create mode 100644 file\n create mode 120000 link\nSwitched to a new branch 'b1'\n[b1 739eb85] b2 changes\n 2 files changed, 2 insertions(+), 2 deletions(-)\nSwitched to branch 'master'\n[master 18a2da4] also modified in master\n 2 files changed, 2 insertions(+), 2 deletions(-)\nargs: b6a69d0c0c2500530cba8bc2987a1f79998b5e74 -- HEAD 739eb853c480b729ec07da533610243e3a6d69ee\nMerge made by the 'theirs' strategy.\nlrwxrwxrwx 1 yoh yoh 10 Sep 24 19:58 link -> masterlink\nmaster file\n\n\n-- \nYaroslav O. Halchenko\nCenter for Open Neuroscience     http://centerforopenneuroscience.org\nDartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755\nPhone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419\nWWW:   http://www.linkedin.com/in/yarik        \n"},{"id":"328780","messageId":"xmqqwp4nfuv1.fsf@gitster.mtv.corp.google.com","threadId":"46821","inReplyTo":"20170925000213.rilmsczdbi3jqkta@hopa.kiewit.dartmouth.edu","subject":"Re: BUG: merge -s theirs is not in effect (does the same as -s ours)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-09-25T01:08:18Z","receivedAt":"2017-09-25T01:08:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Yaroslav Halchenko <yoh@onerussian.com> writes:\n\n> My interest was to get remote branch \"merge\" the changes in the\n> branch taking the branch's version (primarily alternative symlinks\n> for git-annex'ed content) over the version in master (previous\n> merge of a similar branch).  Unfortunately -s theirs seems to do\n> actually -s ours\n\nWhat does\n\n    ls $(git --exec-path) | grep git-merge\n\nsay?  \n\nThe official Git never shipped \"git-merge-theirs\" as far as I know,\nand it should not exist (neither should \"git merge -s theirs\"; you\ncan use \"git reset --hard theirs\" instead).\n\n\n\n"},{"id":"328781","messageId":"20170925031751.lg7zk6krt65dxwas@hopa.kiewit.dartmouth.edu","threadId":"46821","inReplyTo":"xmqqwp4nfuv1.fsf@gitster.mtv.corp.google.com","subject":"Re: BUG: merge -s theirs is not in effect (does the same as -s ours)","fromName":"Yaroslav Halchenko","fromEmail":"yoh@onerussian.com","sentAt":"2017-09-25T03:17:51Z","receivedAt":"2017-09-25T03:18:07Z","isPatch":false,"sender":{"key":"yoh@onerussian.com","avatar":"https://gravatar.com/avatar/8901b82415ae451a83aea49409708912726e53620e3ac92320bf1f86548d97e9?d=mp&s=160"},"body":"\nOn Mon, 25 Sep 2017, Junio C Hamano wrote:\n\n> Yaroslav Halchenko <yoh@onerussian.com> writes:\n\n> > My interest was to get remote branch \"merge\" the changes in the\n> > branch taking the branch's version (primarily alternative symlinks\n> > for git-annex'ed content) over the version in master (previous\n> > merge of a similar branch).  Unfortunately -s theirs seems to do\n> > actually -s ours\n\n> What does\n\n>     ls $(git --exec-path) | grep git-merge\n\nNB when running git just built, --exec-path reports some non existing dir\nin ~:\n\n$> git --exec-path \n/home/yoh/libexec/git-core\n$> ls -l /home/yoh/libexec/git-core\nls: cannot access '/home/yoh/libexec/git-core': No such file or directory\n$> which git\n/home/yoh/proj/misc/git/git\n\n> say?  \n\n> The official Git never shipped \"git-merge-theirs\" as far as I know,\n> and it should not exist (neither should \"git merge -s theirs\"; you\n> can use \"git reset --hard theirs\" instead).\n\nd'oh, indeed there is no git-merge-theirs  neither in debian pkg or a freshly\nbuilt git  and I found a rogue script in the PATH (which did nothing\napparently, sorry!). BUT I was originally mislead by the --help/manpage:\n\n\nMERGE STRATEGIES\n       The merge mechanism (git merge and git pull commands) allows the backend merge strategies to be chosen with -s option. Some strategies can also take their own options, which can be passed by giving -X<option>\n       arguments to git merge and/or git pull.\n       ...\n       recursive\n           This can only resolve two heads using a 3-way merge algorithm. When there is more than one common ancestor that can be used for 3-way merge, it creates a merged tree of the common ancestors and uses that as\n           the reference tree for the 3-way merge. This has been reported to result in fewer merge conflicts without causing mismerges by tests done on actual merge commits taken from Linux 2.6 kernel development\n           history. Additionally this can detect and handle merges involving renames. This is the default merge strategy when pulling or merging one branch.\n\n           The recursive strategy can take the following options:\n\n           ours\n               This option forces conflicting hunks to be auto-resolved cleanly by favoring our version. ...\n           theirs\n               This is the opposite of ours.\n\n\n(Documentation/merge-strategies.txt in the sources I guess)\n\nPS thanks for CCing me in replies!\n-- \nYaroslav O. Halchenko\nCenter for Open Neuroscience     http://centerforopenneuroscience.org\nDartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755\nPhone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419\nWWW:   http://www.linkedin.com/in/yarik        \n"},{"id":"328790","messageId":"xmqqmv5je412.fsf_-_@gitster.mtv.corp.google.com","threadId":"46821","inReplyTo":"20170925031751.lg7zk6krt65dxwas@hopa.kiewit.dartmouth.edu","subject":"Re* BUG: merge -s theirs is not in effect (does the same as -s ours)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-09-25T05:33:13Z","receivedAt":"2017-09-25T05:33:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Yaroslav Halchenko <yoh@onerussian.com> writes:\n\n> d'oh, indeed there is no git-merge-theirs  neither in debian pkg or a freshly\n> built git  and I found a rogue script in the PATH (which did nothing\n> apparently, sorry!). BUT I was originally mislead by the --help/manpage:\n\nAhh, you're right.  The text does make readers expect \"-s theirs\" to\nexist.\n\n-- >8 --\nSubject: merge-strategies: avoid implying that \"-s theirs\" exists\n\nThe description of `-Xours` merge option has a parenthetical note\nthat tells the readers that it is very different from `-s ours`,\nwhich is correct, but the description of `-Xtheirs` that follows it\ncarelessly says \"this is the opposite of `ours`\", giving a false\nimpression that the readers also need to be warned that it is very\ndifferent from `-s theirs`, which in reality does not even exist.\n\nClarify it a bit to avoid misleading readers.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n\n * I hope this should help things a bit.\n\n   It is a different matter to resurrect the age old discussion that\n   happend in the summer of 2008 if '-s theirs' should or should not\n   exist.  In short, the previous discussion can be summarised to\n   \"we don't want '-s theirs' as it encourages the wrong workflow\".\n\n   https://public-inbox.org/git/alpine.DEB.1.00.0807290123300.2725@eeepc-johanness/\n   https://public-inbox.org/git/7vtzen7bul.fsf@gitster.siamese.dyndns.org/\n   https://public-inbox.org/git/20080720192130.6117@nanako3.lavabit.com/\n\n   It is OK for people to come with new perspective and bring new\n   ideas to the table.  We learned from experience while using Git\n   for longer and are wiser than what we were back then, and might\n   be able to make a better decision ;-)\n\n Documentation/merge-strategies.txt | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt\nindex 2eb92b9327..a09d597463 100644\n--- a/Documentation/merge-strategies.txt\n+++ b/Documentation/merge-strategies.txt\n@@ -39,7 +39,8 @@ even look at what the other tree contains at all.  It discards everything\n the other tree did, declaring 'our' history contains all that happened in it.\n \n theirs;;\n-\tThis is the opposite of 'ours'.\n+\tThis is the opposite of 'ours'; note that, unlike 'ours', there is\n+\tno 'theirs' merge stragegy to confuse this merge option with.\n \n patience;;\n \tWith this option, 'merge-recursive' spends a little extra time\n"},{"id":"328844","messageId":"20170925143040.4qgofxcdahal46r7@hopa.kiewit.dartmouth.edu","threadId":"46821","inReplyTo":"xmqqmv5je412.fsf_-_@gitster.mtv.corp.google.com","subject":"-X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect","fromName":"Yaroslav Halchenko","fromEmail":"yoh@onerussian.com","sentAt":"2017-09-25T14:30:40Z","receivedAt":"2017-09-25T14:30:55Z","isPatch":false,"sender":{"key":"yoh@onerussian.com","avatar":"https://gravatar.com/avatar/8901b82415ae451a83aea49409708912726e53620e3ac92320bf1f86548d97e9?d=mp&s=160"},"body":"\nOn Mon, 25 Sep 2017, Junio C Hamano wrote:\n\n> Yaroslav Halchenko <yoh@onerussian.com> writes:\n\n> > d'oh, indeed there is no git-merge-theirs  neither in debian pkg or a freshly\n> > built git  and I found a rogue script in the PATH (which did nothing\n> > apparently, sorry!). BUT I was originally mislead by the --help/manpage:\n\n> Ahh, you're right.  The text does make readers expect \"-s theirs\" to\n> exist.\n> ...\n>  * I hope this should help things a bit.\n\nyes it does. Thanks.  And that is where I realized that I should have used -X\ntheirs (not -s theirs), as the instruction on the option for the\n(recursive) merge.  And now problem is more specific:\n\n- conflict within file content editing was resolved as instructed\n  (taking \"theirs\" version)\n\n- BUT symlink was not taken from \"theirs\" and left as unresolved conflict:\n\n$> rm -rf /tmp/repo1; mkdir /tmp/repo1; cd /tmp/repo1; git init .; ln -s sym1 link; echo 1 > file; git add file link; git commit -m 'common'; git co -b b1 ; ln -sf b1link link; echo \"b1 file\" >| file; git commit -m 'b2 changes' -a; git co master; ln -sf masterlink link; echo \"master file\" >| file; git commit -m 'also modified in master' -a; git merge -X theirs --no-edit b1; ls -l link; cat file\nwarning: templates not found /home/yoh/share/git-core/templates\nInitialized empty Git repository in /tmp/repo1/.git/\n[master (root-commit) f0b75bc] common\n 2 files changed, 2 insertions(+)\n create mode 100644 file\n create mode 120000 link\nSwitched to a new branch 'b1'\n[b1 45c93ca] b2 changes\n 2 files changed, 2 insertions(+), 2 deletions(-)\nSwitched to branch 'master'\n[master 0ee6db2] also modified in master\n 2 files changed, 2 insertions(+), 2 deletions(-)\nAuto-merging link\nCONFLICT (content): Merge conflict in link\nAuto-merging file\nAutomatic merge failed; fix conflicts and then commit the result.\nlrwxrwxrwx 1 yoh yoh 10 Sep 25 10:21 link -> masterlink\nb1 file\nchanges on filesystem:                                                                                          \n link | Unmerged\ncached/staged changes:\n file | 2 +-\n link | Unmerged\n\n\nPS I will followup on -s theirs in a split thread\nPSS Thanks for CCing me your replies\n-- \nYaroslav O. Halchenko\nCenter for Open Neuroscience     http://centerforopenneuroscience.org\nDartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755\nPhone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419\nWWW:   http://www.linkedin.com/in/yarik        \n"},{"id":"328845","messageId":"20170925144021.vhbd3wb3uqejs5wq@hopa.kiewit.dartmouth.edu","threadId":"46821","inReplyTo":"xmqqmv5je412.fsf_-_@gitster.mtv.corp.google.com","subject":"-s theirs use-case(s) Was: BUG: merge -s theirs is not in effect","fromName":"Yaroslav Halchenko","fromEmail":"yoh@onerussian.com","sentAt":"2017-09-25T14:40:21Z","receivedAt":"2017-09-25T14:40:34Z","isPatch":false,"sender":{"key":"yoh@onerussian.com","avatar":"https://gravatar.com/avatar/8901b82415ae451a83aea49409708912726e53620e3ac92320bf1f86548d97e9?d=mp&s=160"},"body":"\nOn Mon, 25 Sep 2017, Junio C Hamano wrote:\n>    It is a different matter to resurrect the age old discussion that\n>    happend in the summer of 2008 if '-s theirs' should or should not\n>    exist.  In short, the previous discussion can be summarised to\n>    \"we don't want '-s theirs' as it encourages the wrong workflow\".\n\n>    https://public-inbox.org/git/alpine.DEB.1.00.0807290123300.2725@eeepc-johanness/\n>    https://public-inbox.org/git/7vtzen7bul.fsf@gitster.siamese.dyndns.org/\n>    https://public-inbox.org/git/20080720192130.6117@nanako3.lavabit.com/\n\n>    It is OK for people to come with new perspective and bring new\n>    ideas to the table.  We learned from experience while using Git\n>    for longer and are wiser than what we were back then, and might\n>    be able to make a better decision ;-)\n\nFWIW\n\n1. As a workaround for absence of -m theirs I using mtheirs git alias:\n(I believe provided to me awhile back here on the list):\n\n    mtheirs = !sh -c 'git merge -s ours --no-commit $1 && git read-tree -m -u $1' -\n\nand it worked fine for my usecases\n\n2. I think that if there is a reason for -s ours to exist, so there for -s theirs\nsince it is just the directionality of merges which changes between the two\n\n3. My most frequently used use-case for -m theirs strategy is repositories such as \n\nhttp://datasets.datalad.org/openfmri/ds000001/.git\n\nwhere we construct \"datalad dataset\" by crawling the web resource(s), and\nworkflow consists of 3 branches:\n\nincoming             -- content from the web \"as is\"\nincoming-processed   -- content from the web \"processed\" (fully automatically),\n                        e.g. tarballs extracted etc\nmaster               -- the \"final\" result, delivered to public\n\nincoming-processed   is formed  by  -s theirs --no-commit  incoming, then all\ncontent needed to be extracted/processed (since last such merge point) is\nprocessed and commit is done.  Such \"merge\" allows us to establish a point of\nprevious \"processing state\" so we could react appropriately whenever anything\nin \"incoming\" branch changes (so that there is a new commit).\n\n  And then incoming-processed is merged (regular recursive) into the\nmaster branch, which might have further \"manual\" tune ups.\n\nPS thanks for CCing replies\n\n-- \nYaroslav O. Halchenko\nCenter for Open Neuroscience     http://centerforopenneuroscience.org\nDartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755\nPhone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419\nWWW:   http://www.linkedin.com/in/yarik        \n"},{"id":"328919","messageId":"xmqqing6cje7.fsf@gitster.mtv.corp.google.com","threadId":"46821","inReplyTo":"20170925143040.4qgofxcdahal46r7@hopa.kiewit.dartmouth.edu","subject":"Re: -X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-09-26T01:56:32Z","receivedAt":"2017-09-26T01:56:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Yaroslav Halchenko <yoh@onerussian.com> writes:\n\n> yes it does. Thanks.  And that is where I realized that I should have used -X\n> theirs (not -s theirs), as the instruction on the option for the\n> (recursive) merge.  And now problem is more specific:\n>\n> - conflict within file content editing was resolved as instructed\n>   (taking \"theirs\" version)\n>\n> - BUT symlink was not taken from \"theirs\" and left as unresolved conflict:\n\nI wouldn't call it working-as-intended, but this unfortunately is\nexpected.  You'd encounter exactly the same behaviour when changes\nto a binary file conflicts.\n\nIt is because -X<ours|theirs> _ONLY_ kicks in (i.e. that is how it\nis defined) when we would otherwise throw the half-merged result:\n\n\t<<<<<<<\n\tour version looks like this\n\t=======\n\ttheir version looks like this\n\t>>>>>>>\n\nand ask you to edit that to a correct resolution.\n\nBecause you would not normally be given something like the above\nwhen merging conflicted changes to symbolic links or to binary\nfiles, -X<ours|theirs> has no chance of affecting the outcome.\n\nI do not recall people talking about symbolic links but the case of\nbinary files has been on the wishlist for a long time, and I do not\nknow of anybody who is working on (or is planning to work on) it.\n"},{"id":"328920","messageId":"xmqqefqucigh.fsf@gitster.mtv.corp.google.com","threadId":"46821","inReplyTo":"xmqqing6cje7.fsf@gitster.mtv.corp.google.com","subject":"Re: -X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-09-26T02:16:46Z","receivedAt":"2017-09-26T02:16:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> I do not recall people talking about symbolic links but the case of\n> binary files has been on the wishlist for a long time, and I do not\n> know of anybody who is working on (or is planning to work on) it.\n\nAh, I misremembered.\n\nWe've addressed the \"binary files\" case back in 2012 with a944af1d\n(\"merge: teach -Xours/-Xtheirs to binary ll-merge driver\",\n2012-09-08).  I do not know offhand if it is just as easy to plumb\nthe MERGE_FAVOR_{OURS,THEIRS} bits thru the symbolic link codepath,\nlike that patch did to the binary file codepath.\n\n"},{"id":"328921","messageId":"xmqqa81ichdu.fsf@gitster.mtv.corp.google.com","threadId":"46821","inReplyTo":"xmqqefqucigh.fsf@gitster.mtv.corp.google.com","subject":"Re: -X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-09-26T02:39:57Z","receivedAt":"2017-09-26T02:40:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> I do not recall people talking about symbolic links but the case of\n>> binary files has been on the wishlist for a long time, and I do not\n>> know of anybody who is working on (or is planning to work on) it.\n>\n> Ah, I misremembered.\n>\n> We've addressed the \"binary files\" case back in 2012 with a944af1d\n> (\"merge: teach -Xours/-Xtheirs to binary ll-merge driver\",\n> 2012-09-08).  I do not know offhand if it is just as easy to plumb\n> the MERGE_FAVOR_{OURS,THEIRS} bits thru the symbolic link codepath,\n> like that patch did to the binary file codepath.\n\nPerhaps the attached (totally untested) patch might be a good\nstarting point.  I do not know if you are interested in hacking on\nGit, and I do not feel offended if you are not, but perhaps somebody\nelse might get interested in seeing if this #leftoverbits is a good\ndirection to go in, and finishing it with docs and tests if it is\n;-)\n\n\n merge-recursive.c | 17 +++++++++++++----\n 1 file changed, 13 insertions(+), 4 deletions(-)\n\ndiff --git a/merge-recursive.c b/merge-recursive.c\nindex 1d3f8f0d22..3605275ca3 100644\n--- a/merge-recursive.c\n+++ b/merge-recursive.c\n@@ -1026,10 +1026,19 @@ static int merge_file_1(struct merge_options *o,\n \t\t\t\t\t\t       &b->oid,\n \t\t\t\t\t\t       !o->call_depth);\n \t\t} else if (S_ISLNK(a->mode)) {\n-\t\t\toidcpy(&result->oid, &a->oid);\n-\n-\t\t\tif (!oid_eq(&a->oid, &b->oid))\n-\t\t\t\tresult->clean = 0;\n+\t\t\tswitch (o->recursive_variant) {\n+\t\t\tcase MERGE_RECURSIVE_NORMAL:\n+\t\t\t\toidcpy(&result->oid, &a->oid);\n+\t\t\t\tif (!oid_eq(&a->oid, &b->oid))\n+\t\t\t\t\tresult->clean = 0;\n+\t\t\t\tbreak;\n+\t\t\tcase MERGE_RECURSIVE_OURS:\n+\t\t\t\toidcpy(&result->oid, &a->oid);\n+\t\t\t\tbreak;\n+\t\t\tcase MERGE_RECURSIVE_THEIRS:\n+\t\t\t\toidcpy(&result->oid, &b->oid);\n+\t\t\t\tbreak;\n+\t\t\t}\n \t\t} else\n \t\t\tdie(\"BUG: unsupported object type in the tree\");\n \t}\n"},{"id":"328923","messageId":"xmqqzi9iazrp.fsf@gitster.mtv.corp.google.com","threadId":"46821","inReplyTo":"20170925144021.vhbd3wb3uqejs5wq@hopa.kiewit.dartmouth.edu","subject":"Re: -s theirs use-case(s) Was: BUG: merge -s theirs is not in effect","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-09-26T03:45:46Z","receivedAt":"2017-09-26T03:45:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Yaroslav Halchenko <yoh@onerussian.com> writes:\n\n> 1. As a workaround for absence of -m theirs I using mtheirs git alias:\n> (I believe provided to me awhile back here on the list):\n>\n>     mtheirs = !sh -c 'git merge -s ours --no-commit $1 && git read-tree -m -u $1' -\n>\n> and it worked fine for my usecases\n>\n> 2. I think that if there is a reason for -s ours to exist, so there for -s theirs\n> since it is just the directionality of merges which changes between the two\n\nJust on this point.  They are not exactly symmetric.\n\nImagine there are some undesirable changes you want to vanquish from\nthe world, but they have already built on useful changes on top of\nthe undesirable changes.  A hypothetical history might look like\nthis:\n\n                 B---C\n                /\n           X---X---A\n          /\n      ---o---o         your mainline\n\nwhere 'X' denotes those unwanted changes.\n\nWith a \"-s ours\" merge, you can declare that changes on the other\nbranch will never be merged to your branch, i.e.\n\n                 B---C\n                /\n           X---X---A\n          /     \\\n      ---o---o---M     your mainline\n\nand then you can safely merge A and C into your branch, without\nhaving to worry about them bringing the unwanted changes to your\ntree state.\n\n                 B---C\n                /     \\\n           X---X---A   \\\n          /     \\   \\   \\\n      ---o---o---M---N---O  your mainline\n\nThat is the primary reason why \"-s ours\" exists, i.e. you do not\ncontrol the branch where mistakes X were made because that is\nsomebody else's history.\n\nThe symmetiric case where _you_ have wrong changes do not need \"-s\ntheirs\".  These mistakes X are yours, so are the changes depend on\nthem:\n\n                 B---C\n                /\n           X---X---A\n          /\n      ---o---o         their mainline\n\nand you can just rebase A, B and C on top of their mainline while\ngetting rid of Xs yourself before publishing.\n\n               B'--C'\n              /  \n      ---o---o---A'\n\nThe reason why ours and theirs are not symmetric is because you are\nyou and not them---the control and ownership of our history and\ntheir history is not symmetric.\n\nThere may be valid workflows that benefit from \"-s theirs\", and I\nwould not be surprised at all if we found more of them in the past 9\nyears since we had the \"why -s theirs does not exist\" discussion in\n2008.  But \"because -s ours can be used in reverse to emulate\" is\nnot a valid excuse to add \"-s theirs\".  It can be used a rationale\nagainst adding it (e.g. \"-s theirs generally is discouraged because\nit forsters a bad workflow, but in a very rare case where it might\nbe useful, you can always check out their branch and merge yours\nusing '-s ours' to emulate it, so we do not lose any functionality\neven if we did not add it\"), though.\n"},{"id":"328942","messageId":"20170926133232.3yjasune6um4qw45@hopa.kiewit.dartmouth.edu","threadId":"46821","inReplyTo":"xmqqzi9iazrp.fsf@gitster.mtv.corp.google.com","subject":"Re: -s theirs use-case(s) Was: BUG: merge -s theirs is not in effect","fromName":"Yaroslav Halchenko","fromEmail":"yoh@onerussian.com","sentAt":"2017-09-26T13:32:32Z","receivedAt":"2017-09-26T13:32:47Z","isPatch":false,"sender":{"key":"yoh@onerussian.com","avatar":"https://gravatar.com/avatar/8901b82415ae451a83aea49409708912726e53620e3ac92320bf1f86548d97e9?d=mp&s=160"},"body":"\nOn Tue, 26 Sep 2017, Junio C Hamano wrote:\n\n> Yaroslav Halchenko <yoh@onerussian.com> writes:\n\n> > 1. As a workaround for absence of -m theirs I using mtheirs git alias:\n> > (I believe provided to me awhile back here on the list):\n\n> >     mtheirs = !sh -c 'git merge -s ours --no-commit $1 && git read-tree -m -u $1' -\n\n> > and it worked fine for my usecases\n\n> > 2. I think that if there is a reason for -s ours to exist, so there for -s theirs\n> > since it is just the directionality of merges which changes between the two\n\n> Just on this point.  They are not exactly symmetric.\n\n> Imagine there are some undesirable changes you want to vanquish from\n> the world, but they have already built on useful changes on top of\n> the undesirable changes.  A hypothetical history might look like\n> this:\n\n>                  B---C\n>                 /\n>            X---X---A\n>           /\n>       ---o---o         your mainline\n\n> where 'X' denotes those unwanted changes.\n\n> >...<\n\n> The symmetiric case where _you_ have wrong changes do not need \"-s\n> theirs\".  These mistakes X are yours, so are the changes depend on\n> them:\n\n>                  B---C\n>                 /\n>            X---X---A\n>           /\n>       ---o---o         their mainline\n\n> and you can just rebase A, B and C on top of their mainline while\n> getting rid of Xs yourself before publishing.\n\nand that is where the gotcha comes -- what if \"my\" changes were already\npublished?  then I would like to avoid the rebase, and would -s theirs\nto choose \"their\" solution in favor of mine and be able to push so\nothers could still \"fast-forward\" to the new state.\n\nSo -- as to me it remains 'symmetric' ;)\n\n> There may be valid workflows that benefit from \"-s theirs\", and I\n> would not be surprised at all if we found more of them in the past 9\n> years since we had the \"why -s theirs does not exist\" discussion in\n> 2008.  But \"because -s ours can be used in reverse to emulate\" is\n> not a valid excuse to add \"-s theirs\".  It can be used a rationale\n> against adding it (e.g. \"-s theirs generally is discouraged because\n> it forsters a bad workflow, but in a very rare case where it might\n> be useful, you can always check out their branch and merge yours\n> using '-s ours' to emulate it, so we do not lose any functionality\n> even if we did not add it\"), though.\n\nsure, git is flexible, so workarounds could always be found, but often\nmany options are just a matter of convenience.  And here -s theirs would\nbe one of them besides my other use case where it is a somewhat \"by\ndesign\" workflow, and -s theirs is use to take their exact state I would\nimprove upon (before committing the \"merge\")\n\n-- \nYaroslav O. Halchenko\nCenter for Open Neuroscience     http://centerforopenneuroscience.org\nDartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755\nPhone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419\nWWW:   http://www.linkedin.com/in/yarik        \n"},{"id":"328943","messageId":"20170926133703.7gtk5ztkhqvfxszh@hopa.kiewit.dartmouth.edu","threadId":"46821","inReplyTo":"xmqqa81ichdu.fsf@gitster.mtv.corp.google.com","subject":"Re: -X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect","fromName":"Yaroslav Halchenko","fromEmail":"yoh@onerussian.com","sentAt":"2017-09-26T13:37:03Z","receivedAt":"2017-09-26T13:37:24Z","isPatch":false,"sender":{"key":"yoh@onerussian.com","avatar":"https://gravatar.com/avatar/8901b82415ae451a83aea49409708912726e53620e3ac92320bf1f86548d97e9?d=mp&s=160"},"body":"\nOn Tue, 26 Sep 2017, Junio C Hamano wrote:\n> >> I do not recall people talking about symbolic links but the case of\n> >> binary files has been on the wishlist for a long time, and I do not\n> >> know of anybody who is working on (or is planning to work on) it.\n\n> > Ah, I misremembered.\n\n> > We've addressed the \"binary files\" case back in 2012 with a944af1d\n> > (\"merge: teach -Xours/-Xtheirs to binary ll-merge driver\",\n> > 2012-09-08).  I do not know offhand if it is just as easy to plumb\n> > the MERGE_FAVOR_{OURS,THEIRS} bits thru the symbolic link codepath,\n> > like that patch did to the binary file codepath.\n\n> Perhaps the attached (totally untested) patch might be a good\n> starting point.  I do not know if you are interested in hacking on\n> Git, and I do not feel offended if you are not, but perhaps somebody\n\nI would have felt honored to \"hack on Git\" but neither my C-foo is up to\npar, neither there would be more time I could adequately allocate for\nsuch endeavor.   So meanwhile I am trying to contribute in hopefully\nconstructive \"whining\" while exploiting git.\n\n> else might get interested in seeing if this #leftoverbits is a good\n> direction to go in, and finishing it with docs and tests if it is\n> ;-)\n\n\n>  merge-recursive.c | 17 +++++++++++++----\n>  1 file changed, 13 insertions(+), 4 deletions(-)\n\n> >...<\n\nThis patch worked beautifully in my usecase!:\n\n$> rm -rf /tmp/repo1; mkdir /tmp/repo1; cd /tmp/repo1; git init .; ln -s sym1 link; echo 1 > file; git add file link; git commit -m 'common'; git co -b b1 ; ln -sf b1link link; echo \"b1 file\" >| file; git commit -m 'b2 changes' -a; git co master; ln -sf masterlink link; echo \"master file\" >| file; git commit -m 'also modified in master' -a; git merge -X theirs --no-edit b1; ls -l link; cat file                                                       \nwarning: templates not found /home/yoh/share/git-core/templates                                                                \nInitialized empty Git repository in /tmp/repo1/.git/\n[master (root-commit) d2e9010] common\n 2 files changed, 2 insertions(+)\n create mode 100644 file\n create mode 120000 link\nSwitched to a new branch 'b1'\n[b1 a2b1321] b2 changes\n 2 files changed, 2 insertions(+), 2 deletions(-)\nSwitched to branch 'master'\n[master fbb4ba7] also modified in master\n 2 files changed, 2 insertions(+), 2 deletions(-)\nAuto-merging link\nAuto-merging file\nMerge made by the 'recursive' strategy.\n file | 2 +-\n link | 2 +-\n 2 files changed, 2 insertions(+), 2 deletions(-)\nlrwxrwxrwx 1 yoh yoh 6 Sep 26 09:32 link -> b1link\nb1 file\n\nI also tried -s ours and no explicit -s, and they did as prescribed as\nwell\n\nPS thanks for the CCs\n-- \nYaroslav O. Halchenko\nCenter for Open Neuroscience     http://centerforopenneuroscience.org\nDartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755\nPhone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419\nWWW:   http://www.linkedin.com/in/yarik        \n"},{"id":"328987","messageId":"xmqqzi9h80jp.fsf@gitster.mtv.corp.google.com","threadId":"46821","inReplyTo":"20170926133232.3yjasune6um4qw45@hopa.kiewit.dartmouth.edu","subject":"Re: -s theirs use-case(s) Was: BUG: merge -s theirs is not in effect","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-09-27T00:09:30Z","receivedAt":"2017-09-27T00:09:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Yaroslav Halchenko <yoh@onerussian.com> writes:\n\n> and that is where the gotcha comes -- what if \"my\" changes were already\n> published?  then I would like to avoid the rebase, and would -s theirs\n> to choose \"their\" solution in favor of mine and be able to push so\n> others could still \"fast-forward\" to the new state.\n>\n> So -- as to me it remains 'symmetric' ;)\n\nI do not necessarily agree.  Once you decide that their history is\nthe mainline, you'd rather want to treat your line of development as\na side branch and make a merge in that direction, i.e. the first\nparent of the resulting merge is a commit on their history and the\nsecond parent is the last bad one of your history.  So you would end\nup using \"checkout their-history && merge -s ours your-history\" to\nkeep the first-parenthood sensible.\n\nAnd at that point, use of \"-s ours\" is no longer a workaround for\nlack of \"-s theirs\".  It is a proper part of the desired semantics,\ni.e. from the point of view of the surviving canonical history line,\nyou want to preserve what it did, nullifying what the other line of\nhistory did.\n\nSo I still do not think the above scenario justifies \"-s theirs\".\n"},{"id":"329000","messageId":"20170927051915.tsxw2zycnjx4dyo4@hopa.kiewit.dartmouth.edu","threadId":"46821","inReplyTo":"xmqqzi9h80jp.fsf@gitster.mtv.corp.google.com","subject":"Re: -s theirs use-case(s) Was: BUG: merge -s theirs is not in effect","fromName":"Yaroslav Halchenko","fromEmail":"yoh@onerussian.com","sentAt":"2017-09-27T05:19:15Z","receivedAt":"2017-09-27T05:19:29Z","isPatch":false,"sender":{"key":"yoh@onerussian.com","avatar":"https://gravatar.com/avatar/8901b82415ae451a83aea49409708912726e53620e3ac92320bf1f86548d97e9?d=mp&s=160"},"body":"\nOn Wed, 27 Sep 2017, Junio C Hamano wrote:\n\n> > and that is where the gotcha comes -- what if \"my\" changes were already\n> > published?  then I would like to avoid the rebase, and would -s theirs\n> > to choose \"their\" solution in favor of mine and be able to push so\n> > others could still \"fast-forward\" to the new state.\n\n> > So -- as to me it remains 'symmetric' ;)\n\n> I do not necessarily agree.  Once you decide that their history is\n> the mainline, you'd rather want to treat your line of development as\n> a side branch and make a merge in that direction, i.e. the first\n> parent of the resulting merge is a commit on their history and the\n> second parent is the last bad one of your history.  So you would end\n> up using \"checkout their-history && merge -s ours your-history\" to\n> keep the first-parenthood sensible.\n\n> And at that point, use of \"-s ours\" is no longer a workaround for\n> lack of \"-s theirs\".  It is a proper part of the desired semantics,\n> i.e. from the point of view of the surviving canonical history line,\n> you want to preserve what it did, nullifying what the other line of\n> history did.\n\n> So I still do not think the above scenario justifies \"-s theirs\".\n\nok, when you describe it like this (in my case I rarely cared about the\nside of the merge), then indeed I might better do the entire dance with\ngit reset --hard theirstate; git merge -s ours HEAD@{1}\nand live happily with the left side being the one always correct and\nhide \"my\" mistakes ;)  will keep it in mind\n\n-- \nYaroslav O. Halchenko\nCenter for Open Neuroscience     http://centerforopenneuroscience.org\nDartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755\nPhone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419\nWWW:   http://www.linkedin.com/in/yarik        \n"},{"id":"329057","messageId":"20170927202132.e4gqbozkczctci5z@hopa.kiewit.dartmouth.edu","threadId":"46821","inReplyTo":"20170927051915.tsxw2zycnjx4dyo4@hopa.kiewit.dartmouth.edu","subject":"Re: -s theirs use-case(s) Was: BUG: merge -s theirs is not in effect","fromName":"Yaroslav Halchenko","fromEmail":"yoh@onerussian.com","sentAt":"2017-09-27T20:21:32Z","receivedAt":"2017-09-27T20:21:46Z","isPatch":false,"sender":{"key":"yoh@onerussian.com","avatar":"https://gravatar.com/avatar/8901b82415ae451a83aea49409708912726e53620e3ac92320bf1f86548d97e9?d=mp&s=160"},"body":"\nOn Wed, 27 Sep 2017, Yaroslav Halchenko wrote:\n> > And at that point, use of \"-s ours\" is no longer a workaround for\n> > lack of \"-s theirs\".  It is a proper part of the desired semantics,\n> > i.e. from the point of view of the surviving canonical history line,\n> > you want to preserve what it did, nullifying what the other line of\n> > history did.\n\n> > So I still do not think the above scenario justifies \"-s theirs\".\n\n> ok, when you describe it like this (in my case I rarely cared about the\n> side of the merge), then indeed I might better do the entire dance with\n> git reset --hard theirstate; git merge -s ours HEAD@{1}\n> and live happily with the left side being the one always correct and\n> hide \"my\" mistakes ;)  will keep it in mind\n\nha -- was about to use it, which reminded me about this use case!\n\nNB pardon me for not so wonderful ascii-diagrams as yours but hopefully\nstill helps\n\n              x-o-o-o-x-o-o    debian\n             /        /\n             x-------x-----    releases -- should just linearly sweep through releases I care about\n            /       /\n           R1      R2          various release branches/tags\n           A       B           which have differing commits\n          /       /\n      ---o---o----o----o        masteg\n\nFor packaging some packages for Debian, with my git-rotten-soul, I am trying to\nkeep my debian packaging  (in a branch \"debian\") on top of upstream\nreleases.  But the problem comes whenever upstream releases from \"release\nbranches\", which are never merged into master and might have different and\nconflicting changes.  \n\nSo, it becomes impossible to maintain a linearly progressing \"debian\"\nbranch without adding a middle-man between upstream releases (in release\nbranches), and debian branch (should progress linearly forward) -- \"releases\"\nbranch.  See e.g.  http://github.com/neurodebian/pandas and its releases\nbranch.\n\nso I use -s theirs for \"linearizing\" the branched up development history\n\n-- \nYaroslav O. Halchenko\nCenter for Open Neuroscience     http://centerforopenneuroscience.org\nDartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755\nPhone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419\nWWW:   http://www.linkedin.com/in/yarik        \n"},{"id":"330443","messageId":"xmqqtvyzslcz.fsf_-_@gitster.mtv.corp.google.com","threadId":"46821","inReplyTo":"20170926133703.7gtk5ztkhqvfxszh@hopa.kiewit.dartmouth.edu","subject":"[PATCH] merge: teach -Xours/-Xtheirs to symbolic link merge","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-10-16T05:38:36Z","receivedAt":"2017-10-16T05:38:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The -Xours/-Xtheirs merge options were originally defined as a way\nto \"force\" the resolution of 3way textual merge conflicts to take\none side without using your editor, hence did not even trigger in\nsituations where you would normally not get the <<< === >>> conflict\nmarkers.\n\nThis was improved for binary files back in 2012 with a944af1d\n(\"merge: teach -Xours/-Xtheirs to binary ll-merge driver\",\n2012-09-08).\n\nTeach a similar trick to the codepath that deals with merging two\nconflicting changes to symbolic links.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n\n * Looks like I queued this on 'pu' but never sent it out to the\n   list for extra eyeballs.  On the tests are new, relative to what\n   was sent out earlier and archived at:\n\n   https://public-inbox.org/git/xmqqa81ichdu.fsf@gitster.mtv.corp.google.com\n\n merge-recursive.c            | 17 +++++++++++++----\n t/t6037-merge-ours-theirs.sh | 32 ++++++++++++++++++++++++++++++++\n 2 files changed, 45 insertions(+), 4 deletions(-)\n\ndiff --git a/merge-recursive.c b/merge-recursive.c\nindex 1494ffdb82..ed529f2ceb 100644\n--- a/merge-recursive.c\n+++ b/merge-recursive.c\n@@ -1002,10 +1002,19 @@ static int merge_file_1(struct merge_options *o,\n \t\t\t\t\t\t       &b->oid,\n \t\t\t\t\t\t       !o->call_depth);\n \t\t} else if (S_ISLNK(a->mode)) {\n-\t\t\toidcpy(&result->oid, &a->oid);\n-\n-\t\t\tif (!oid_eq(&a->oid, &b->oid))\n-\t\t\t\tresult->clean = 0;\n+\t\t\tswitch (o->recursive_variant) {\n+\t\t\tcase MERGE_RECURSIVE_NORMAL:\n+\t\t\t\toidcpy(&result->oid, &a->oid);\n+\t\t\t\tif (!oid_eq(&a->oid, &b->oid))\n+\t\t\t\t\tresult->clean = 0;\n+\t\t\t\tbreak;\n+\t\t\tcase MERGE_RECURSIVE_OURS:\n+\t\t\t\toidcpy(&result->oid, &a->oid);\n+\t\t\t\tbreak;\n+\t\t\tcase MERGE_RECURSIVE_THEIRS:\n+\t\t\t\toidcpy(&result->oid, &b->oid);\n+\t\t\t\tbreak;\n+\t\t\t}\n \t\t} else\n \t\t\tdie(\"BUG: unsupported object type in the tree\");\n \t}\ndiff --git a/t/t6037-merge-ours-theirs.sh b/t/t6037-merge-ours-theirs.sh\nindex 3889eca4ae..0aebc6c028 100755\n--- a/t/t6037-merge-ours-theirs.sh\n+++ b/t/t6037-merge-ours-theirs.sh\n@@ -73,4 +73,36 @@ test_expect_success 'pull passes -X to underlying merge' '\n \tgit reset --hard master && test_must_fail git pull -s recursive -X bork . side\n '\n \n+test_expect_success SYMLINKS 'symlink with -Xours/-Xtheirs' '\n+\tgit reset --hard master &&\n+\tgit checkout -b two master &&\n+\tln -s target-zero link &&\n+\tgit add link &&\n+\tgit commit -m \"add link pointing to zero\" &&\n+\n+\tln -f -s target-two link &&\n+\tgit commit -m \"add link pointing to two\" link &&\n+\n+\tgit checkout -b one HEAD^ &&\n+\tln -f -s target-one link &&\n+\tgit commit -m \"add link pointing to one\" link &&\n+\n+\t# we expect symbolic links not to resolve automatically, of course\n+\tgit checkout one^0 &&\n+\ttest_must_fail git merge -s recursive two &&\n+\n+\t# favor theirs to resolve to target-two?\n+\tgit reset --hard &&\n+\tgit checkout one^0 &&\n+\tgit merge -s recursive -X theirs two &&\n+\tgit diff --exit-code two HEAD link &&\n+\n+\t# favor ours to resolve to target-one?\n+\tgit reset --hard &&\n+\tgit checkout one^0 &&\n+\tgit merge -s recursive -X ours two &&\n+\tgit diff --exit-code one HEAD link\n+\n+'\n+\n test_done\n-- \n2.15.0-rc1-172-gbfe4246c99\n\n"},{"id":"335512","messageId":"CABPp-BHTZrNonnJrWfZg+_xCrO+o_uNjx4nbwuVHF4qVGe01cA@mail.gmail.com","threadId":"46821","inReplyTo":"xmqqtvyzslcz.fsf_-_@gitster.mtv.corp.google.com","subject":"Re: [PATCH] merge: teach -Xours/-Xtheirs to symbolic link merge","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2017-12-29T02:49:36Z","receivedAt":"2017-12-29T02:49:44Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Sun, Oct 15, 2017 at 10:38 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> The -Xours/-Xtheirs merge options were originally defined as a way\n> to \"force\" the resolution of 3way textual merge conflicts to take\n> one side without using your editor, hence did not even trigger in\n> situations where you would normally not get the <<< === >>> conflict\n> markers.\n>\n> This was improved for binary files back in 2012 with a944af1d\n> (\"merge: teach -Xours/-Xtheirs to binary ll-merge driver\",\n> 2012-09-08).\n>\n> Teach a similar trick to the codepath that deals with merging two\n> conflicting changes to symbolic links.\n\nSaw this change referenced in the \"what's cooking\" emails and decided\nto review this.  The code changes look obviously correct to me, and\nthe testcase looks good too.\n\nReviewed-by: Elijah Newren <newren@gmail.com>\n\n(and perhaps we should also add in \"Tested-by: Yaroslav Halchenko\n<yoh@onerussian.com>\" ?  At least, that was my thought based on\nhttps://public-inbox.org/git/20170926133703.7gtk5ztkhqvfxszh@hopa.kiewit.dartmouth.edu/\n)\n"},{"id":"335516","messageId":"20171229044127.7jwyg7geclsmksw4@hopa.kiewit.dartmouth.edu","threadId":"46821","inReplyTo":"CABPp-BHTZrNonnJrWfZg+_xCrO+o_uNjx4nbwuVHF4qVGe01cA@mail.gmail.com","subject":"Re: [PATCH] merge: teach -Xours/-Xtheirs to symbolic link merge","fromName":"Yaroslav Halchenko","fromEmail":"yoh@onerussian.com","sentAt":"2017-12-29T04:41:27Z","receivedAt":"2017-12-29T04:41:43Z","isPatch":true,"sender":{"key":"yoh@onerussian.com","avatar":"https://gravatar.com/avatar/8901b82415ae451a83aea49409708912726e53620e3ac92320bf1f86548d97e9?d=mp&s=160"},"body":"\nOn Thu, 28 Dec 2017, Elijah Newren wrote:\n> > Teach a similar trick to the codepath that deals with merging two\n> > conflicting changes to symbolic links.\n\n> Saw this change referenced in the \"what's cooking\" emails and decided\n> to review this.  The code changes look obviously correct to me, and\n> the testcase looks good too.\n\n> Reviewed-by: Elijah Newren <newren@gmail.com>\n\n> (and perhaps we should also add in \"Tested-by: Yaroslav Halchenko\n> <yoh@onerussian.com>\" ?  At least, that was my thought based on\n> https://public-inbox.org/git/20170926133703.7gtk5ztkhqvfxszh@hopa.kiewit.dartmouth.edu/\n> )\n\nI would be honored to wear a badge of the git-tested-by-er!  FWIW\nI can reconfirm, that the patch did work out nicely for me back then\n\nThanks!\n-- \nYaroslav O. Halchenko\nCenter for Open Neuroscience     http://centerforopenneuroscience.org\nDartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755\nPhone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419\nWWW:   http://www.linkedin.com/in/yarik        \n"},{"id":"337356","messageId":"20180125043544.GY3296@hopa.kiewit.dartmouth.edu","threadId":"46821","inReplyTo":"xmqqtvyzslcz.fsf_-_@gitster.mtv.corp.google.com","subject":"external diff driver is not used for diff --stat?","fromName":"Yaroslav Halchenko","fromEmail":"yoh@onerussian.com","sentAt":"2018-01-25T04:35:44Z","receivedAt":"2018-01-25T04:35:57Z","isPatch":false,"sender":{"key":"yoh@onerussian.com","avatar":"https://gravatar.com/avatar/8901b82415ae451a83aea49409708912726e53620e3ac92320bf1f86548d97e9?d=mp&s=160"},"body":"Dear Git Peoples,\n\nI am torturing git and git-annex here trying to compare some logs from a\nrun of a software recorded in two different branches.  As many other\ntools, software often logs its version, elapsed times etc, so diff becomes not of interest to me:\n\n\t$> PATH=~/proj/misc/git/INSTALL-2.16.1/bin:$PATH git diff test-18.0.09 test-18.0.05+git24-gb25b21054_dfsg.1-1_nd90+1 -- AFNI_data6/FT_analysis/FT.results/out.allcostX.txt-git\n\tdiff --git a/AFNI_data6/FT_analysis/FT.results/out.allcostX.txt-git b/AFNI_data6/FT_analysis/FT.results/out.allcostX.txt-git\n\tindex db85c9be..5f4a704d 100644\n\t--- a/AFNI_data6/FT_analysis/FT.results/out.allcostX.txt-git\n\t+++ b/AFNI_data6/FT_analysis/FT.results/out.allcostX.txt-git\n\t@@ -1,4 +1,4 @@\n\t-++ 3dAllineate: AFNI version=AFNI_18.0.09 (Jan 19 2018) [64-bit]\n\t+++ 3dAllineate: AFNI version=Debian-18.0.05+git24-gb25b21054~dfsg.1-1~nd90+1 (Jan 23 2018) [64-bit]\n\t ++ Authored by: Zhark the Registrator\n\t ++ Source dataset: ./anat_final.FT+tlrc.HEAD\n\t ++ Base dataset:   ./final_epi_vr_base_min_outlier+tlrc.HEAD\n\t@@ -28,5 +28,5 @@ volume 0\n\t\tlpa  = 0.921773\n\t\tlpc+ = 0.310739\n\t\tncd  = 0.967007\n\t-++ 3dAllineate: total CPU time = 0.0 sec  Elapsed = 1.5\n\t+++ 3dAllineate: total CPU time = 0.0 sec  Elapsed = 1.3\n\n\nso I came up with a simple differ to exclude those:\n\n\t$> cat ~/bin/git-annex-diff-wrapper\n\t#!/usr/bin/env bash                                                             \n\tLANG=C diff --color=always --ignore-matching-lines=\"\\(AFNI version=\\|time.*Elapsed\\)\" -u \"$2\" \"$5\"  \n\nwhich works as it should (sorry for long lines, just wanted to not cut out\nanything which might be of relevance)\n\n\t$> PATH=~/proj/misc/git/INSTALL-2.16.1/bin:$PATH GIT_EXTERNAL_DIFF='git-annex diffdriver  -- ~/bin/git-annex-diff-wrapper --' git diff --ext-diff test-18.0.09 test-18.0.05+git24-gb25b21054_dfsg.1-1_nd90+1 -- AFNI_data6/FT_analysis/FT.results/out.allcostX.txt-git     \n\t# no output received\n\n(and even on annexed files -- whoohoo).\n\nThe problem comes that --stat seems to be not using the external diff (it is\nline the same as above just with --stat):\n\n\t$> PATH=~/proj/misc/git/INSTALL-2.16.1/bin:$PATH GIT_EXTERNAL_DIFF='git-annex diffdriver  -- ~/bin/git-annex-diff-wrapper --' git diff --ext-diff test-18.0.09 test-18.0.05+git24-gb25b21054_dfsg.1-1_nd90+1 --stat -- AFNI_data6/FT_analysis/FT.results/out.allcostX.txt-git\n\t AFNI_data6/FT_analysis/FT.results/out.allcostX.txt-git | 4 ++--\n\t 1 file changed, 2 insertions(+), 2 deletions(-)\n\n\nA shortcoming or somehow \"by design\"? ;)\n\nPS Please CC me in replies\n\nCheers!\n\n-- \nYaroslav O. Halchenko\nCenter for Open Neuroscience     http://centerforopenneuroscience.org\nDartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755\nPhone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419\nWWW:   http://www.linkedin.com/in/yarik        \n"}]}