{"thread":{"id":"2862","subject":"git merge questions","startedAt":"2005-12-16T20:05:11Z","lastAt":"2005-12-17T03:48:40Z","messageCount":9,"participants":["Don Zickus","Junio C Hamano","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"13735","messageId":"68948ca0512161205x3d5921bfm3bfcaa64f988eb99@mail.gmail.com","threadId":"2862","inReplyTo":null,"subject":"git merge questions","fromName":"Don Zickus","fromEmail":"dzickus@gmail.com","sentAt":"2005-12-16T20:05:11Z","receivedAt":"2005-12-16T20:05:11Z","isPatch":false,"sender":{"key":"dzickus@gmail.com","avatar":"https://gravatar.com/avatar/fbc96d0d5584c05dec11867b861650fe9f5d7d0ddec2655a1f90542fe07d9769?d=mp&s=160"},"body":"I now have a git merge question.  I decided to try merging branches\nand was left with a situation in which the file was moved on the\nmaster branch and updated on my branch.  Not sure how to properly\nintegrate the changes from my branch.\n\nFor example:\n%git checkout -b test v2.6.14\n%<manually apply all the 2.6.14.z stable patches>\n%<commit those patches>\n%git checkout -b test2 v2.6.15-rc4\n%git pull . test\n\nNow over the course of 2.6.15 the arch/ppc64 was renamed to\narch/powerpc.  Fine. The merge algorithms handled all the unchanged\nfiles properly.  However arch/ppc64/Kconfig was modified and the\nmerging was left unresolved.  In fact there is no file no merge\nagainst (because it moved).  So 'git-ls-files -u' only shows stage 1+3\n(no stage 2, of course).\n\nHow do I merge those changes?  I don't know enough about all the git\ncommands to figure this out, especially how to take advantage of the\nstage 1, 2, and 3 files.\n\nThanks for any help,\nDon\n"},{"id":"13736","messageId":"7vacf0g4ga.fsf@assigned-by-dhcp.cox.net","threadId":"2862","inReplyTo":"68948ca0512161205x3d5921bfm3bfcaa64f988eb99@mail.gmail.com","subject":"Re: git merge questions","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-16T20:41:25Z","receivedAt":"2005-12-16T20:41:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Don Zickus <dzickus@gmail.com> writes:\n\n> Now over the course of 2.6.15 the arch/ppc64 was renamed to\n> arch/powerpc.  Fine. The merge algorithms handled all the unchanged\n> files properly.  However arch/ppc64/Kconfig was modified and the\n> merging was left unresolved.  In fact there is no file no merge\n> against (because it moved).  So 'git-ls-files -u' only shows stage 1+3\n> (no stage 2, of course).\n>\n> How do I merge those changes?  I don't know enough about all the git\n> commands to figure this out, especially how to take advantage of the\n> stage 1, 2, and 3 files.\n\nI do not work on the kernel myself so I'll probably get the\ndetails wrong, but I am guessing here is what you have:\n\n - 2.6.14.z has arch/ppc64/Kconfig;\n\n - Your \"test\" branch has arch/ppc64/Kconfig.  You may or may\n   not have changes since 2.6.14.z on that file;\n\n - \"test2\" branch has 2.6.15-rc4, which has the file at\n   arch/powerpc/Kconfig;\n\nThen, with the current branch being \"test2\", you pulled \"test\"\ninto it.\n\n - Untouched [by whom???] files from arch/{ppc64,powerpc}/ were\n   merged correctly and you find the result of merge under\n   arch/powerpc --- after all you are applying changes on top of\n   2.6.15-rc4 and you want them under arch/powerpc as the\n   upstream has;\n\n - arch/ppc64/Kconfig was modified [by whom???] and merge was\n   left unresolved.\n\nI suspect these:\n\n\tls -l arch/ppc64/Kconfig <1>\n\tgit ls-files -s arch/ppc64/Kconfig <2>\n        ls -l arch/powerpc/Kconfig arch/powerpc/Kconfig~* <3>\n        git ls-files -s arch/powerpc/Kconfig <4>\n\n<1> has the file from your \"test\" branch based on 2.6.14z;\n<2> shows that same file;\n<3> may show the three variants (I am not sure about this);\n<4> has 2.6.15-rc4 version at stage 3 and merge base version at\n    stage 1 (I am not absolutely certain what stage 1 has, and\n    also am puzzled why stage 2 is not there --- if the\n    recursive strategy figured out renames it should have the\n    contents of arch/ppc64/Kconfig from test branch there).\n\nThe safest (however most primitive) way I can think of to go\nfrom here is:\n\n1. figure out the merge-base Kconfig file's contents.\n\n        $ mb=$(git merge-base refs/heads/test refs/heads/test2)\n        $ git ls-tree $(mb) arch/powerpc/Kconfig arch/ppc/Kconfig\n\n   I do not know which path the merge base has, but it should\n   have either one of those.  Note the blob object name (call it\n   $oSHA1).\n\n2. extract three versions.\n\n\t$ git ls-tree refs/heads/test2 arch/powerpc/Kconfig\n        $ git ls-tree refs/heads/test arch/powerpc/Kconfig\n\n   Note the blob object name from these two as well (call them\n   $aSHA1, and $bSHA1).\n\n3. merge those three.\n\n\t$ git cat-file blob $oSHA1 >orig\n        $ git cat-file blob $aSHA1 >from-test2\n        $ git cat-file blob $bSHA1 >from-test\n        $ merge from-test2 orig from-test\n\nWith luck from-test2 would contain a clean automerge result, or\nyou will get <<< === >>> conflict markers.  Resolve them in the\nfile, and then:\n\n4. resolve the index and remove cruft.\n\n\t$ cat from-test2 >arch/powerpc/Kconfig\n        $ rm -f arch/ppc64/Kconfig orig from-test2 from-test\n        $ git update-index --add --remove \\\n        \tarch/ppc64/Kconfig arch/powerpc/Kconfig\n\n5. if there is no other merge cruft, commit.\n\n\t$ git commit\n\nWhat puzzles me is that I think it is supposed to have done all\nthe above for you.  Namely:\n\n\t$ ls -l arch/ppc64/Kconfig <1>\n\t$ git ls-files -s arch/ppc64/Kconfig <2>\n        $ ls -l arch/powerpc/Kconfig arch/powerpc/Kconfig~* <3>\n        $ git ls-files -s arch/powerpc/Kconfig <4>\n\n<1> should not remain --- recursive merge could have notied that\nthe file was moved.\n<2> ditto.\n<3> arch/powerpc/Kconfig should be there with possibly merge\nconflict markers.\n<4> stage1 with merge base version (possibly renamed), stage2\nwith test2 version, stage3 with your test version (definitely\nrenamed).\n\nand after editing arch/powerpc/Kconfig to resolve conflicts, you\nshould be able to just say:\n\n\t$ git update-index arch/powerpc/Kconfig\n\t$ git commit\n"},{"id":"13739","messageId":"68948ca0512161313x5b09c65aw36570adb9495cf98@mail.gmail.com","threadId":"2862","inReplyTo":"7vacf0g4ga.fsf@assigned-by-dhcp.cox.net","subject":"Re: git merge questions","fromName":"Don Zickus","fromEmail":"dzickus@gmail.com","sentAt":"2005-12-16T21:13:12Z","receivedAt":"2005-12-16T21:13:12Z","isPatch":false,"sender":{"key":"dzickus@gmail.com","avatar":"https://gravatar.com/avatar/fbc96d0d5584c05dec11867b861650fe9f5d7d0ddec2655a1f90542fe07d9769?d=mp&s=160"},"body":"On 12/16/05, Junio C Hamano <junkio@cox.net> wrote:\n> Don Zickus <dzickus@gmail.com> writes:\n>\n> > Now over the course of 2.6.15 the arch/ppc64 was renamed to\n> > arch/powerpc.  Fine. The merge algorithms handled all the unchanged\n> > files properly.  However arch/ppc64/Kconfig was modified and the\n> > merging was left unresolved.  In fact there is no file no merge\n> > against (because it moved).  So 'git-ls-files -u' only shows stage 1+3\n> > (no stage 2, of course).\n> >\n> > How do I merge those changes?  I don't know enough about all the git\n> > commands to figure this out, especially how to take advantage of the\n> > stage 1, 2, and 3 files.\n>\n> I do not work on the kernel myself so I'll probably get the\n> details wrong, but I am guessing here is what you have:\n>\nSorry, I should have been more specific.  How about this:\n1) 2.6.14-test branch modifies arch/ppc64/Kconfig\n2) master branch renames arch/ppc64/Kconfig to arch/powerpc/Kconfig\n3) 2.6.14-test and master branch share a common ancestor v2.6.14\n4) Need to merge change arch/ppc64/Kconfig to arch/powerpc/Kconfig\n\n$ git ls-files -u\n100644 c658650af429672267409508b02b38754c11a40f 1       arch/ppc64/Kconfig\n100644 8abf1118ebbd59954d098d87679114ffda0e75cb 3       arch/ppc64/Kconfig\n***Notice no stage 2\n\n$ ls -ld arch/p*\ndrwxrwxr-x   9 dzickus dzickus 4096 Dec 16 14:12 arch/parisc\ndrwxrwxr-x  11 dzickus dzickus 4096 Dec 16 14:26 arch/powerpc\ndrwxrwxr-x  15 dzickus dzickus 4096 Dec 16 14:26 arch/ppc\n***Notice no ppc64 (was removed in master branch)\n\n$ ls -ld arch/powerpc/Kconfig*\n-rw-rw-r--  1 dzickus dzickus 24279 Dec 16 14:26 arch/powerpc/Kconfig\n***Notice no backup or side copy of Kconfig\n\nThere were other conflicts with this merge (ones that weren't\nautomatically resolved) but those were easily merged using vi and\nsearching for <<<.  However this particular file is providing an\nunusual case.\n\nLet me know if this helps or not.\n\nCheers,\nDon\n"},{"id":"13742","messageId":"7vy82keo8p.fsf@assigned-by-dhcp.cox.net","threadId":"2862","inReplyTo":"7vacf0g4ga.fsf@assigned-by-dhcp.cox.net","subject":"Re: git merge questions","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-16T21:16:54Z","receivedAt":"2005-12-16T21:16:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> What puzzles me is that I think it is supposed to have done all\n> the above for you.  Namely:\n>\n> \t$ ls -l arch/ppc64/Kconfig <1>\n> \t$ git ls-files -s arch/ppc64/Kconfig <2>\n>         $ ls -l arch/powerpc/Kconfig arch/powerpc/Kconfig~* <3>\n>         $ git ls-files -s arch/powerpc/Kconfig <4>\n>\n> <1> should not remain --- recursive merge could have notied that\n> the file was moved.\n> <2> ditto.\n> <3> arch/powerpc/Kconfig should be there with possibly merge\n> conflict markers.\n> <4> stage1 with merge base version (possibly renamed), stage2\n> with test2 version, stage3 with your test version (definitely\n> renamed).\n\nI know what happened.  That Kconfig file was modified between\nv2.6.14 and v2.6.15-rc4 beyond recognition, and the rename\ndetection did not think it was renamed.\n\nThe merge has this message:\n\n    CONFLICT (delete/modify): arch/ppc64/Kconfig deleted in HEAD and\n    modified in e14ee1ed34e25df6ea93b0bfb1bc4138cd26bea2. Version\n    e14ee1ed34e25df6ea93b0bfb1bc4138cd26bea2 of arch/ppc64/Kconfig\n    left in tree.\n\nand then, the digging I suggested yields these:\n\n$ ls -l arch/{ppc64,powerpc}/Kconfig\n-rw-rw-r--  1 junio src 24279 Dec 16 12:55 arch/powerpc/Kconfig\n-rw-rw-r--  1 junio src 11027 Dec 16 12:58 arch/ppc64/Kconfig\n$ git ls-files -s arch/ppc64/Kconfig arch/powerpc/Kconfig\n100644 bb2efdd566a9d590d64184b10b097e4b7ed17e95 0       arch/powerpc/Kconfig\n100644 c658650af429672267409508b02b38754c11a40f 1       arch/ppc64/Kconfig\n100644 8abf1118ebbd59954d098d87679114ffda0e75cb 3       arch/ppc64/Kconfig\n$ ls arch/{powerpc,ppc64}/Kconfig~*\nls: arch/powerpc/Kconfig~*: No such file or directory\nls: arch/ppc64/Kconfig~*: No such file or directory\n$ git diff --theirs arch/ppc64/Kconfig\n* Unmerged path arch/ppc64/Kconfig\ndiff --git a/arch/ppc64/Kconfig b/arch/ppc64/Kconfig\n\nThe merge algorithm thought your branch (that is, test2 which is\nv2.6.15-rc4) removed the old ppc64/Kconfig path, but the other\nbranch (test1 which has diff between v2.6.14 and v2.6.14.4) made\nupdates to that file.  For the other path, it simply thought\nyour branch added a new file arch/powerpc/Kconfig while the\nother branch did not do anything to that path between v2.6.14\nand v2.6.14.4, so it merged it already.\n\nThe result you want in this case is to merge changes between\nc65865 (stage1 of old path) and 8abf11 (stage3 of old path) into\nbb2efd (the latest contents of the new path) and register it as\nthe result of merge for arch/powerpc/Kconfig, and remove\narch/ppc64/Kconfig.  So the sequence would be:\n\n$ orig=$(git unpack-file c65865)\n$ from_test=$(git unpack-file 8abf11)\n$ merge $from_test $orig arch/powerpc/Kconfig\nmerge: warning: conflicts during merge\n\nAfter resolving the conflict in $from_test file, and other conflicts:\n\n$ ed $from_test\n$ cat $from_tset >arch/ppc64/Kconfig\n$ rm arch/powerpc/Kconfig\n$ rm $orig $from_test\n$ git update-index --add --remove arch/ppc64/Kconfig arch/powerpc/Kconfig\n# also mark paths you hand-resolved such as Makefile, drivers/pcmcia/i82365.c\n# etc. with \"git update-index\" here.\n$ git commit\n\nwould commit the result of the merge.\n"},{"id":"13744","messageId":"68948ca0512161335k50a3ec64lee6f73ea4f8ae23f@mail.gmail.com","threadId":"2862","inReplyTo":"7vy82keo8p.fsf@assigned-by-dhcp.cox.net","subject":"Re: git merge questions","fromName":"Don Zickus","fromEmail":"dzickus@gmail.com","sentAt":"2005-12-16T21:35:41Z","receivedAt":"2005-12-16T21:35:41Z","isPatch":false,"sender":{"key":"dzickus@gmail.com","avatar":"https://gravatar.com/avatar/fbc96d0d5584c05dec11867b861650fe9f5d7d0ddec2655a1f90542fe07d9769?d=mp&s=160"},"body":"> and then, the digging I suggested yields these:\n>\n> $ ls -l arch/{ppc64,powerpc}/Kconfig\n> -rw-rw-r--  1 junio src 24279 Dec 16 12:55 arch/powerpc/Kconfig\n> -rw-rw-r--  1 junio src 11027 Dec 16 12:58 arch/ppc64/Kconfig\n> $ git ls-files -s arch/ppc64/Kconfig arch/powerpc/Kconfig\n> 100644 bb2efdd566a9d590d64184b10b097e4b7ed17e95 0       arch/powerpc/Kconfig\n> 100644 c658650af429672267409508b02b38754c11a40f 1       arch/ppc64/Kconfig\n> 100644 8abf1118ebbd59954d098d87679114ffda0e75cb 3       arch/ppc64/Kconfig\n> $ ls arch/{powerpc,ppc64}/Kconfig~*\n> ls: arch/powerpc/Kconfig~*: No such file or directory\n> ls: arch/ppc64/Kconfig~*: No such file or directory\n> $ git diff --theirs arch/ppc64/Kconfig\n> * Unmerged path arch/ppc64/Kconfig\n> diff --git a/arch/ppc64/Kconfig b/arch/ppc64/Kconfig\n>\n> The merge algorithm thought your branch (that is, test2 which is\n> v2.6.15-rc4) removed the old ppc64/Kconfig path, but the other\n> branch (test1 which has diff between v2.6.14 and v2.6.14.4) made\n> updates to that file.  For the other path, it simply thought\n> your branch added a new file arch/powerpc/Kconfig while the\n> other branch did not do anything to that path between v2.6.14\n> and v2.6.14.4, so it merged it already.\n>\n> The result you want in this case is to merge changes between\n> c65865 (stage1 of old path) and 8abf11 (stage3 of old path) into\n> bb2efd (the latest contents of the new path) and register it as\n> the result of merge for arch/powerpc/Kconfig, and remove\n> arch/ppc64/Kconfig.  So the sequence would be:\n>\n> $ orig=$(git unpack-file c65865)\n> $ from_test=$(git unpack-file 8abf11)\n> $ merge $from_test $orig arch/powerpc/Kconfig\n> merge: warning: conflicts during merge\n>\n> After resolving the conflict in $from_test file, and other conflicts:\n>\n> $ ed $from_test\n> $ cat $from_tset >arch/ppc64/Kconfig\n> $ rm arch/powerpc/Kconfig\n> $ rm $orig $from_test\n> $ git update-index --add --remove arch/ppc64/Kconfig arch/powerpc/Kconfig\n> # also mark paths you hand-resolved such as Makefile, drivers/pcmcia/i82365.c\n> # etc. with \"git update-index\" here.\n> $ git commit\n>\n> would commit the result of the merge.\n>\n\nWow. That makes sense then.  All your digging techniques seem to be\nfairly straightforward.   Now say I didn't know the name of the rename\nand I had to dig that up.  Would the following be the right way or is\nthere something easier?\n\n%git log <renamed file>  #grab the last commit id from here\n%git-diff-tree -p <last commit id>  # search for the new file\n\nThanks again,\nDon\n"},{"id":"13750","messageId":"7voe3gd6ul.fsf@assigned-by-dhcp.cox.net","threadId":"2862","inReplyTo":"68948ca0512161335k50a3ec64lee6f73ea4f8ae23f@mail.gmail.com","subject":"Re: git merge questions","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-16T22:17:54Z","receivedAt":"2005-12-16T22:17:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Don Zickus <dzickus@gmail.com> writes:\n\n>> and then, the digging I suggested yields these:\n>>\n>> $ ls -l arch/{ppc64,powerpc}/Kconfig\n>> -rw-rw-r--  1 junio src 24279 Dec 16 12:55 arch/powerpc/Kconfig\n>> -rw-rw-r--  1 junio src 11027 Dec 16 12:58 arch/ppc64/Kconfig\n>> $ git ls-files -s arch/ppc64/Kconfig arch/powerpc/Kconfig\n>> 100644 bb2efdd566a9d590d64184b10b097e4b7ed17e95 0       arch/powerpc/Kconfig\n>> 100644 c658650af429672267409508b02b38754c11a40f 1       arch/ppc64/Kconfig\n>> 100644 8abf1118ebbd59954d098d87679114ffda0e75cb 3       arch/ppc64/Kconfig\n>> ..\n>> The result you want in this case is to merge changes between\n>> c65865 (stage1 of old path) and 8abf11 (stage3 of old path) into\n>> bb2efd (the latest contents of the new path) and register it as\n>> the result of merge for arch/powerpc/Kconfig, and remove\n>> arch/ppc64/Kconfig.  So the sequence would be:\n>>\n>> $ orig=$(git unpack-file c65865)\n>> $ from_test=$(git unpack-file 8abf11)\n>> $ merge $from_test $orig arch/powerpc/Kconfig\n>> merge: warning: conflicts during merge\n\nI suspect there might be a room for improvement to make this\neasier with a new command, if this becomes a common pattern.\n\nSomething like:\n\n\t$ git resolve-renamed-path arch/ppc64/Kconfig arch/powerpc/Kconfig\n\nto mean \"I want the result of this merge to rename ppc64/Kconfig\nto powerpc/Kconfig\", perhaps?  There are three cases: (1) we\nrenamed they didn't --- this is the case we are looking at and\nthere will be stage1 and stage3 but not stage2 for the old path,\nand stage0 for the new path; (2) they renamed we didn't --- this\nwould happen if you pulled test2 into test, and there will be\nstage1 and stage2 but not stage3 for the old path, and stage0\nfor the new path; (3) both of us renamed.\n\nThe third case is handled by the merge command automatically.\nOld path will not remain to bother you even if the merge of the\nnew path needs hand-resolving, so you do not need\nresolve-renamed-path command to deal with that case.\n\n> Now say I didn't know the name of the rename and I had to dig\n> that up.  Would the following be the right way or is there\n> something easier?\n>\n> %git log <renamed file>  #grab the last commit id from here\n> %git-diff-tree -p <last commit id>  # search for the new file\n\nThat would work.\n\nOr an explicit rename detection to see where many of the\nneighbouring paths moved (this is very expensive):\n\n\tmb=$(git merge-base test test2)\n        git diff-tree -r --diff-filter=R -M -l0 --name-status $mb test2\n\nOr the diff-tree between the merge base and your current tree\nand perhaps the other tree (this may give a lot of cruft):\n\n\tmb=$(git merge-base test test2)\n        git diff-tree -r --diff-filter=A --name-status $mb test2\n"},{"id":"13752","messageId":"Pine.LNX.4.63.0512170056380.11000@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2862","inReplyTo":"7voe3gd6ul.fsf@assigned-by-dhcp.cox.net","subject":"Re: git merge questions","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-12-16T23:58:50Z","receivedAt":"2005-12-16T23:58:50Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\njust a thought: maybe in this case -- git fails to recognize a rename -- \nPasky's idea would have some merit. You could then provide git with some \nextra information a la .git/info/grafts: \"Even if you, git, do not believe \nit: this file *was* renamed from blah to blop\".\n\nCiao,\nDscho\n"},{"id":"13755","messageId":"7vd5jwcxtk.fsf@assigned-by-dhcp.cox.net","threadId":"2862","inReplyTo":"Pine.LNX.4.63.0512170056380.11000@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git merge questions","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-17T01:32:55Z","receivedAt":"2005-12-17T01:32:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> just a thought: maybe in this case -- git fails to recognize a rename -- \n> Pasky's idea would have some merit. You could then provide git with some \n> extra information a la .git/info/grafts: \"Even if you, git, do not believe \n> it: this file *was* renamed from blah to blop\".\n\nYeah, except small details such as: where does it record it, and\nhow does the information presented to the user, and how does the\nuser tell git that information should be used?\n\nWhat would be interesting would be to extend on this thing I\njust wrote:\n\n    Something like:\n\n        $ git resolve-renamed-path arch/ppc64/ arch/powerpc/\n\n    to mean \"I want the result of this merge to rename ppc64/Kconfig\n    to powerpc/Kconfig\", perhaps?\n\nI think this would work very nicely even without rename\ndetectino by the recursive strategy.  What would happen with\nresolve strategy is that unchanged paths are removed from\narch/ppc64 and added to arch/powerpc by the usual read-tree\nmerge rules, and all paths (not just unrecognizable renames --\nbecause resolve would not even try) that have been changed on\nthe \"test\" branch would be in stage1+stage3 state in arch/ppc64,\nwhile the corresponding ones in arch/powerpc are collapsed\n(\"only added in test2 branch\") to stage0.  The fictional\nresolve-renamed-path command (notice that I removed the explicit\n\"Kconfig\" from the sample command line) could go through the\nindex file, looking for paths that arch/powerpc/ has stage0 and\narch/ppc64 has stage1+3, and perform the renaming merge at that\npoint.\n"},{"id":"13758","messageId":"7vbqzgbcyv.fsf@assigned-by-dhcp.cox.net","threadId":"2862","inReplyTo":"Pine.LNX.4.63.0512170056380.11000@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git merge questions","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-17T03:48:40Z","receivedAt":"2005-12-17T03:48:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> just a thought: maybe in this case -- git fails to recognize a rename -- \n> Pasky's idea would have some merit.\n\nIt is not as simple as that.  If you look at the output of the\nfollowing command, you would understand why.\n\n\t$ git rev-list ^$(git merge-base test test2) test2 -- \\\n          arch/powerpc/Kconfig arch/ppc64/Kconfig |\n          git diff-tree --pretty -C -r --stdin --abbrev --name-status \\\n          arch/powerpc/Kconfig arch/ppc64/Kconfig\n\nThe transition happened over time with multiple commits.\n\nFirst ppc64/Kconfig was somewhat stripped of its contents,\nstarting at this commit:\n\n    diff-tree bcdd1ea... (from 5bfc826...)\n    Author: Stephen Rothwell <sfr@canb.auug.org.au>\n    Date:   Mon Sep 19 23:13:24 2005 +1000\n\n        [PATCH] powerpc: Move arch/ppc*/oprofile/Kconfig to arch/powerpc\n\n        These files are identical.\n\n        Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>\n        Signed-off-by: Paul Mackerras <paulus@samba.org>\n\n    M       arch/ppc64/Kconfig\n\nand after a lot of hard work, powerpc/Kconfig gets\ncreated.\n\n    diff-tree 14cf11a... (from e5baa39...)\n    Author: Paul Mackerras <paulus@samba.org>\n    Date:   Mon Sep 26 16:04:21 2005 +1000\n\n        powerpc: Merge enough to start building in arch/powerpc.\n\n        This creates the directory structure under arch/powerpc and a bunch\n        of Kconfig files...\n\n    A       arch/powerpc/Kconfig\n\nAfter that both continues to exist for some time, and finally\nppc64/Kconfig gets deleted with this one:\n\n    diff-tree 7568cb4... (from c55377e...)\n    Author: Paul Mackerras <paulus@samba.org>\n    Date:   Mon Nov 14 17:30:17 2005 +1100\n\n        powerpc: Move most remaining ppc64 files over to arch/powerpc\n\n        Also deletes files in arch/ppc64 that are no longer used now that\n        we don't compile with ARCH=ppc64 any more.\n\n        Signed-off-by: Paul Mackerras <paulus@samba.org>\n\n    M       arch/powerpc/Kconfig\n    D       arch/ppc64/Kconfig\n\n\nYou cannot record \"this is the rename\" by attributing that\ninformation to one particular commit.  Even looking at the\ncommit history one by one you cannot really say powerpc/Kconfig\nis a rename of ppc64/Kconfig.  I suspect that it is not really a\nrename --- from reading of the log messages, its original\ncontents were moved around and scattered over to other Kconfig\nfiles in the tree, or along with other configuration pieces got\nconsolidated into powerpc/Kconfig, or perhaps both.\n"}]}