{"thread":{"id":"43174","subject":"Re: Rename detection at git log","startedAt":"2006-11-20T05:57:23Z","lastAt":"2006-11-20T12:16:20Z","messageCount":17,"participants":["Jakub Narebski","Andy Parkins","Alexander Litvinov","Junio C Hamano","Alex Riesen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"295330","messageId":"200611201157.23680.litvinov2004@gmail.com","threadId":"43174","inReplyTo":null,"subject":"Rename detection at git log","fromName":"Alexander Litvinov","fromEmail":"litvinov2004@gmail.com","sentAt":"2006-11-20T05:57:23Z","receivedAt":"2006-11-20T05:57:23Z","isPatch":false,"sender":{"key":"litvinov2004@gmail.com","avatar":null},"body":"How can I see all changes for one file ? Including renames/copies ? Currently \nI don't known how to see them :\n\n> mkdir 1 && cd 1 && git init-db\ndefaulting to local storage area\n> date >> a\n> git add a\n> git commit -a -m \"1\"\nCommitting initial tree c47d83a6544612309aad57519ca831cf62a489d5\n> mkdir b\n> git mv a b/\n> git commit -a -m \"2\"\n> PAGER=cat git log -M -C --pretty=oneline b/a\n3b591f7147ee8dbe15fdf456db5730072d41bed8 2\n>\n\nAt lastline I would like to see two commits : renaming a -> b/a and creation \nof a. By the way, how can I see commit message with git log ?\n\nThanks for help.\n"},{"id":"294027","messageId":"200611200951.05529.andyparkins@gmail.com","threadId":"43174","inReplyTo":"200611201157.23680.litvinov2004@gmail.com","subject":"Re: Rename detection at git log","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-20T09:50:55Z","receivedAt":"2006-11-20T09:50:55Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Monday 2006 November 20 05:57, Alexander Litvinov wrote:\n\n> > PAGER=cat git log -M -C --pretty=oneline b/a\n\nI've come across this too. Personally I'm not sure what use \"-C\" is. From \nthe manpage, man git-diff-files (no, this isn't the place I'd look either).\n\n--find-copies-harder\nFor performance reasons, by default, -C option finds copies only if the \noriginal file of the copy was modified in the same changeset. This flag makes \nthe command inspect unmodified files as candidates for the source of copy. \nThis is a very expensive operation for large projects, so use it with \ncaution.\n\nThat is to say that unless the file you are copying was modified AND copied in \nthe same commit, it won't be searched as a potential source for the copy \noperation. I think it would be rare to make a copy of a file I had modified, \nsurely I'd want to check in modifications before making a copy?\n\nRegardlss, to get the results you want, use the stronger \nswitch --find-copies-harder, heeding the warning that on big projects it will \nbe very slow.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"296729","messageId":"81b0412b0611200206q4ded162drdc450715d7f801e0@mail.gmail.com","threadId":"43174","inReplyTo":"200611201157.23680.litvinov2004@gmail.com","subject":"Re: Rename detection at git log","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-11-20T10:06:56Z","receivedAt":"2006-11-20T10:06:56Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 11/20/06, Alexander Litvinov wrote:\n> How can I see all changes for one file ? Including renames/copies ?\n\ngit log -M -C -r --name-status\n\n> PAGER=cat git log -M -C --pretty=oneline b/a\n>\n> At lastline I would like to see two commits : renaming a -> b/a and creation\n> of a. By the way, how can I see commit message with git log ?\n\n"},{"id":"296850","messageId":"7vejry5t4g.fsf@assigned-by-dhcp.cox.net","threadId":"43174","inReplyTo":"200611200951.05529.andyparkins@gmail.com","subject":"Re: Rename detection at git log","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-20T10:07:11Z","receivedAt":"2006-11-20T10:07:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> On Monday 2006 November 20 05:57, Alexander Litvinov wrote:\n>\n>> > PAGER=cat git log -M -C --pretty=oneline b/a\n>\n> I've come across this too. Personally I'm not sure what use \"-C\" is. From \n> the manpage, man git-diff-files (no, this isn't the place I'd look either).\n\nThe real issue here is because the b/a on the command line\napplies on the input-side, and does not act as the output\nfilter. This comes from _very_ early design decision and if you\ndig the list archive you will see Linus and I arguing about\ndiffcore-pathspec (which later died off).\n\nWhat it means is that \"git log\" will look at path that matches\nb/a (that means b/a/c and b/a/d are looked at, if b/a were a\ndirectory). Since path \"a\" which is what the file was\noriginally at is not something the pattern b/a matches, there is\nno way b/a is noticed as a rename from a.\n\nI've been meaning to resurrect Fredrik's --single-follow=path\npatch but haven't had time to recently, with all the other\ninteresting discussion happening on the list.\n\n"},{"id":"293970","messageId":"ejrutd$j98$1@sea.gmane.org","threadId":"43174","inReplyTo":"7vejry5t4g.fsf@assigned-by-dhcp.cox.net","subject":"Re: Rename detection at git log","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-20T10:11:17Z","receivedAt":"2006-11-20T10:11:17Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Andy Parkins writes:\n> \n>> On Monday 2006 November 20 05:57, Alexander Litvinov wrote:\n>>\n>>> > PAGER=cat git log -M -C --pretty=oneline b/a\n>>\n>> I've come across this too. Personally I'm not sure what use \"-C\" is. From \n>> the manpage, man git-diff-files (no, this isn't the place I'd look either).\n> \n> The real issue here is because the b/a on the command line\n> applies on the input-side, and does not act as the output\n> filter. This comes from _very_ early design decision and if you\n> dig the list archive you will see Linus and I arguing about\n> diffcore-pathspec (which later died off).\n> \n> What it means is that \"git log\" will look at path that matches\n> b/a (that means b/a/c and b/a/d are looked at, if b/a were a\n> directory). Since path \"a\" which is what the file was\n> originally at is not something the pattern b/a matches, there is\n> no way b/a is noticed as a rename from a.\n> \n> I've been meaning to resurrect Fredrik's --single-follow=path\n> patch but haven't had time to recently, with all the other\n> interesting discussion happening on the list.\n\nBut for now, you can use\n\n PAGER= git log -M -C -- b/a a\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297344","messageId":"200611201022.10656.andyparkins@gmail.com","threadId":"43174","inReplyTo":"7vejry5t4g.fsf@assigned-by-dhcp.cox.net","subject":"Re: Rename detection at git log","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-20T10:22:08Z","receivedAt":"2006-11-20T10:22:08Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Monday 2006 November 20 10:07, Junio C Hamano wrote:\n\n> The real issue here is because the b/a on the command line\n> applies on the input-side, and does not act as the output\n> filter. This comes from _very_ early design decision and if you\n> dig the list archive you will see Linus and I arguing about\n> diffcore-pathspec (which later died off).\n\nI don't think so; even without the b/a on the command line, git does not find \ncopies made in this way...\n\n$ git init-db\ndefaulting to local storage area\n$ date > fileA\n$ git add fileA\n$ git commit -a -m \"fileA\"\nCommitting initial tree 3ef607fd139dd955f868305462d99dfc4cfff70f\n$ cp fileA fileB\n$ git add fileB\n$ git commit -a -m \"fileA -> fileB\"\n\nNow let's try and get git-diff to notice this was a copy...\n\n$ git diff HEAD^..HEAD | cat\ndiff --git a/fileB b/fileB\nnew file mode 100644\nindex 0000000..ec620df\n--- /dev/null\n+++ b/fileB\n@@ -0,0 +1 @@\n+Mon Nov 20 10:16:29 GMT 2006\n$ git diff -C HEAD^..HEAD | cat\ndiff --git a/fileB b/fileB\nnew file mode 100644\nindex 0000000..ec620df\n--- /dev/null\n+++ b/fileB\n@@ -0,0 +1 @@\n+Mon Nov 20 10:16:29 GMT 2006\n$ git diff --find-copies-harder HEAD^..HEAD | cat\ndiff --git a/fileA b/fileB\nsimilarity index 100%\ncopy from fileA\ncopy to fileB\n\nAs I said - I don't see what \"-C\" ever does for you in all but the rarest of \nuses. --find-copies-harder is the only way to list copies successfully. \nIt's nothing to do with any input or output filtering.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"297496","messageId":"200611201023.54146.andyparkins@gmail.com","threadId":"43174","inReplyTo":"81b0412b0611200206q4ded162drdc450715d7f801e0@mail.gmail.com","subject":"Re: Rename detection at git log","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-20T10:23:52Z","receivedAt":"2006-11-20T10:23:52Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Monday 2006 November 20 10:06, Alex Riesen wrote:\n\n> remove --pretty=oneline, it is default behavior of git log.\n\nNo it's not; are you confusing it with --pretty=short?\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"297004","messageId":"7virha4cnm.fsf@assigned-by-dhcp.cox.net","threadId":"43174","inReplyTo":"200611201022.10656.andyparkins@gmail.com","subject":"Re: Rename detection at git log","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-20T10:48:13Z","receivedAt":"2006-11-20T10:48:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> On Monday 2006 November 20 10:07, Junio C Hamano wrote:\n>\n>> The real issue here is because the b/a on the command line\n>> applies on the input-side, and does not act as the output\n>> filter. This comes from _very_ early design decision and if you\n>> dig the list archive you will see Linus and I arguing about\n>> diffcore-pathspec (which later died off).\n>\n> I don't think so; even without the b/a on the command line,\n> git does not find copies made in this way...\n\nI wrote the code and you contradict me ;-)?\n\nTrust me, I know this area reasonably well, to the point that\nsometimes I wonder if there is a sane and cheap way to change\nthe meaning of the pathspec to be an output filter and then\nquickly say \"Nah\" to myself.\n\nIf you say\n\n\tgit diff --find-copies-harder HEAD^..HEAD -- fileB\n\nin your example, it would give you the creation of fileB, not\ncopy.\n\nThere are a few things we need to be careful about rename/copy.\n\n - Typically too small files are not treated as copies unless\n they are identical copies (does not apply to this case,\n luckily).\n\n - Renames are only picked up from files that were lost in the\n same change (i.e. \"mv fileA fileB\" creates fileB and loses\n fileA; fileB is checked if it is similar to fileA in the\n original).\n\n - Copies are only picked up from files that were changed in the\n same change (i.e. splitting major part of original file and\n moving it to somewhere else, while leaving a skelton in the\n original file). \"harder\" is needed if the copy original was\n untouched, as you found out.\n\nThe last one is a compromise between performance and thoroughness,\nand the \"harder\" is one knob to tweak its behaviour.\n\nIn the kernel archive, \n\n\tgit show -C ad2f931d\n\ntells us that:\n\n - drivers/i2c/chips/Kconfig lost major part of it and only\n skeletal part of the original remains in it;\n\n - major part of it went to drivers/hwmon/Kconfig;\n\nThe story is similar to the Makefile next door.\n"},{"id":"297317","messageId":"7vd57i4cij.fsf@assigned-by-dhcp.cox.net","threadId":"43174","inReplyTo":"200611201023.54146.andyparkins@gmail.com","subject":"Re: Rename detection at git log","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-20T10:51:16Z","receivedAt":"2006-11-20T10:51:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> On Monday 2006 November 20 10:06, Alex Riesen wrote:\n>\n>> remove --pretty=oneline, it is default behavior of git log.\n>\n> No it's not; are you confusing it with --pretty=short?\n\nI think Alex (Riesen) is saying \"you (Alex Litvinov) were\nwondering why you do not see the commit log message but only the\nfirst line. That is because you are using --pretty=oneline.\nLose it, then you would get what you want because giving the log\nmessage _is_ the default\".\n"},{"id":"297543","messageId":"200611201101.04456.andyparkins@gmail.com","threadId":"43174","inReplyTo":"7virha4cnm.fsf@assigned-by-dhcp.cox.net","subject":"Re: Rename detection at git log","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-20T11:01:02Z","receivedAt":"2006-11-20T11:01:02Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Monday 2006 November 20 10:48, Junio C Hamano wrote:\n\n> I wrote the code and you contradict me ;-)?\n\nSorry; I wasn't so much contradicting that the filtering works exactly as you \nsay (of course it must - I don't know anywhere near enough to make that sort \nof assertion).\n\nHowever, I do think that the problem is not one of filtering. I was saying \nthat \"-C\" has no practical use.\n\n> in your example, it would give you the creation of fileB, not\n> copy.\n\nI'm sure it would - but you had to use --find-copies-harder; -C would not find \nit as a copy.\n\n> - Renames are only picked up from files that were lost in the\n> same change (i.e. \"mv fileA fileB\" creates fileB and loses\n> fileA; fileB is checked if it is similar to fileA in the\n> original).\n\nI've found rename detection to be flawless in all my uses.\n\n> - Copies are only picked up from files that were changed in the\n> same change (i.e. splitting major part of original file and\n> moving it to somewhere else, while leaving a skelton in the\n> original file). \"harder\" is needed if the copy original was\n> untouched, as you found out.\n\nYep; I understand that. I also understand that it is done for performance \nreasons. However, since the typical copy will be one where the source \ndoesn't change at the same time, I am arguing that the non-hard copy \ndetection isn't much use.\n\n> The last one is a compromise between performance and thoroughness,\n> and the \"harder\" is one knob to tweak its behaviour.\n\nI've been poking in tree-diff.c to see if I can understand why it it such a \nperformance hog. I still haven't. Each file is stored under its hash right? \nSo for copy detection why can't you just search for other files with the same \nhash, which I presume is very fast (as it is the basis of what makes git so \nfast)?\n\nI am probably misunderstanding git, but I guess that a copy isn't even needed \nin the database because two files with the same hash in the working copy only \nneed storing once and then referencing twice. So for a copy (again, with my \nsimple understanding of git) we'd have:\n\n commit1 -> tree1 -> fileA = fileA_hash\n ^\n |\n commit2 -> tree2 -> fileA = fileA_hash\n fileB = fileB_hash\n\nDoesn't that mean that copy detection is just a matter of searching the parent \ncommit trees for references to the same hash?\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"295981","messageId":"ejs2lp$2r4$1@sea.gmane.org","threadId":"43174","inReplyTo":"200611201101.04456.andyparkins@gmail.com","subject":"Re: Rename detection at git log","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-20T11:15:30Z","receivedAt":"2006-11-20T11:15:30Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andy Parkins wrote:\n\n> On Monday 2006 November 20 10:48, Junio C Hamano wrote:\n>\n>> - Copies are only picked up from files that were changed in the\n>> same change (i.e. splitting major part of original file and\n>> moving it to somewhere else, while leaving a skelton in the\n>> original file). \"harder\" is needed if the copy original was\n>> untouched, as you found out.\n> \n> Yep; I understand that. I also understand that it is done for performance \n> reasons. However, since the typical copy will be one where the source \n> doesn't change at the same time, I am arguing that the non-hard copy \n> detection isn't much use.\n\nI'm not sure about this. You usually both do pure renames (to reorganize\nfiles, to give file a better name) and renames with modification, but\nI don't think that copy without modification is very common. Usually you\ncopy a file because you take one file as template for the other, or you\nsplit file, or you join files into one file.\n \n>> The last one is a compromise between performance and thoroughness,\n>> and the \"harder\" is one knob to tweak its behaviour.\n> \n> I've been poking in tree-diff.c to see if I can understand why it it such a \n> performance hog. I still haven't. Each file is stored under its hash right? \n> So for copy detection why can't you just search for other files with the same \n> hash, which I presume is very fast (as it is the basis of what makes git so \n> fast)?\n\nCopy and rename detection are done by comparing the contents, calculating\nsimilarity. So to check if files A and B are copies (not necessary pure\ncopies) it is not enough to compare hashes.\n\nThat said, it should be fairly easy (if not that useful in true projects\nas I understand it, as stated above) to add to copy detection detection of\npure copies by comparing hashes. Still, --find-copies-harder would be still\nneeded if the copy original was untouched, while copy itself was modified.\n\n> I am probably misunderstanding git, but I guess that a copy isn't even needed \n> in the database because two files with the same hash in the working copy only \n> need storing once and then referencing twice. So for a copy (again, with my \n> simple understanding of git) we'd have:\n> \n> commit1 -> tree1 -> fileA = fileA_hash\n> ^\n> |\n> commit2 -> tree2 -> fileA = fileA_hash\n> fileB = fileB_hash\n> \n> Doesn't that mean that copy detection is just a matter of searching the parent \n> commit trees for references to the same hash?\n\nThink copy'n'change.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297326","messageId":"200611201117.39244.andyparkins@gmail.com","threadId":"43174","inReplyTo":"7vd57i4cij.fsf@assigned-by-dhcp.cox.net","subject":"Re: Rename detection at git log","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-20T11:17:37Z","receivedAt":"2006-11-20T11:17:37Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Monday 2006 November 20 10:51, Junio C Hamano wrote:\n\n> I think Alex (Riesen) is saying \"you (Alex Litvinov) were\n> wondering why you do not see the commit log message but only the\n> first line. That is because you are using --pretty=oneline.\n> Lose it, then you would get what you want because giving the log\n> message _is_ the default\".\n\nYou're right. Apologies to Alex for my misunderstanding.\n\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"298006","messageId":"7vfyce2w7d.fsf@assigned-by-dhcp.cox.net","threadId":"43174","inReplyTo":"7virha4cnm.fsf@assigned-by-dhcp.cox.net","subject":"Re: Rename detection at git log","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-20T11:28:54Z","receivedAt":"2006-11-20T11:28:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> There are a few things we need to be careful about rename/copy.\n>...\n> - Copies are only picked up from files that were changed in the\n> same change (i.e. splitting major part of original file and\n> moving it to somewhere else, while leaving a skelton in the\n> original file). \"harder\" is needed if the copy original was\n> untouched, as you found out.\n>\n> The last one is a compromise between performance and thoroughness,\n> and the \"harder\" is one knob to tweak its behaviour.\n\nIf people are well disciplined, code refactoring (which can\ntrigger rename/copy detection) tend to affect both source and\ndestination files at the same time, so many times -C finds what\nyou want without --find-copies-harder.\n\nBut sometimes the source stays the same and you literally have\nduplicate (with possibly some modifications) in the new\ndestination. Finding exact copy is cheap (diffcore-rename has a\ndouble loop that first finds exact copies without similarity\nestimation which is very cheap, and then goes on to open blobs\nand does its similarity magic for destinations whose origin is\nstill unknown) but copy/rename with edit is not, and \"harder\"\nvariant feeds _everything_ from the older tree as a candidate of\ncopy source, so it is very expensive for huge projects.\n\n> In the kernel archive, \n>\n> \tgit show -C ad2f931d\n>\n> tells us that:\n>\n> - drivers/i2c/chips/Kconfig lost major part of it and only\n> skeletal part of the original remains in it;\n>\n> - major part of it went to drivers/hwmon/Kconfig;\n>\n> The story is similar to the Makefile next door.\n\nHaving said all that, I think the rename/copy as a wholesale\noperation on one file is an uninteresting special case. The\ngeneric case that happens far more often in practice is the\nlines moving around across files, and the new \"git blame\" gives\nyou better picture to answer \"where the heck did this come from\"\nquestion.\n\nFor example,\n\n\tgit blame -f -n -C 'ad2f931d^!' -- drivers/hwmon/Kconfig\n\non the same commit would show that many of its lines came from\ni2c/chips/Kconfig but not all of them.\n\nThere are quite a few other things I should probably mention for\nnew people on the list about rename/copy/break heuristics but it\nis getting late so I'd defer it to some other time.\n"},{"id":"294916","messageId":"7vbqn22w20.fsf@assigned-by-dhcp.cox.net","threadId":"43174","inReplyTo":"ejs2lp$2r4$1@sea.gmane.org","subject":"Re: Rename detection at git log","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-20T11:32:07Z","receivedAt":"2006-11-20T11:32:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> That said, it should be fairly easy (if not that useful in true projects\n> as I understand it, as stated above) to add to copy detection detection of\n> pure copies by comparing hashes.\n\nThat is already done as a performance measure (notice the double\nloop controlled with \"contents_too\" in diffcore_rename()).\n"},{"id":"294096","messageId":"200611201733.42723.litvinov2004@gmail.com","threadId":"43174","inReplyTo":"7vejry5t4g.fsf@assigned-by-dhcp.cox.net","subject":"Re: Rename detection at git log","fromName":"Alexander Litvinov","fromEmail":"litvinov2004@gmail.com","sentAt":"2006-11-20T11:33:42Z","receivedAt":"2006-11-20T11:33:42Z","isPatch":false,"sender":{"key":"litvinov2004@gmail.com","avatar":null},"body":"> What it means is that \"git log\" will look at path that matches\n> b/a (that means b/a/c and b/a/d are looked at, if b/a were a\n> directory). Since path \"a\" which is what the file was\n> originally at is not something the pattern b/a matches, there is\n> no way b/a is noticed as a rename from a.\n\nI have found that git blame show correct commits for this case. But I am still \nin trouble then examining file's history. I have found I can use \ngit show -C -M commit-sha1 \nfor commit there file was created to see if this was a rename :-)\n\n"},{"id":"294712","messageId":"200611201159.16596.andyparkins@gmail.com","threadId":"43174","inReplyTo":"ejs2lp$2r4$1@sea.gmane.org","subject":"Re: Rename detection at git log","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-20T11:59:12Z","receivedAt":"2006-11-20T11:59:12Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Monday 2006 November 20 11:15, Jakub Narebski wrote:\n\n> I'm not sure about this. You usually both do pure renames (to reorganize\n> files, to give file a better name) and renames with modification, but\n> I don't think that copy without modification is very common. Usually you\n> copy a file because you take one file as template for the other, or you\n> split file, or you join files into one file.\n\nExactly - unfortunately it's the /source/ that has to be modified to be \nincluded in the potential list. Who copies a file then modifies the \noriginal? The copy is by definition already one of the modified files.\n\n\"For performance reasons, by default, -C option finds copies only if the \noriginal file of the copy was modified in the same changeset. This flag makes\"\n\nYour points about copy-and-change accepted. Hash comparison is not \nsufficient.\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"298133","messageId":"200611201216.21752.andyparkins@gmail.com","threadId":"43174","inReplyTo":"7vfyce2w7d.fsf@assigned-by-dhcp.cox.net","subject":"Re: Rename detection at git log","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-20T12:16:20Z","receivedAt":"2006-11-20T12:16:20Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Monday 2006 November 20 11:28, Junio C Hamano wrote:\n\n> If people are well disciplined, code refactoring (which can\n> trigger rename/copy detection) tend to affect both source and\n> destination files at the same time, so many times -C finds what\n> you want without --find-copies-harder.\n\nThat's true; however, I don't think that refactoring is the common operation. \nUsually it's (as Jakub says) copy-and-modify-the-copy. In that case the \noriginal is untouched.\n\n> Having said all that, I think the rename/copy as a wholesale\n> operation on one file is an uninteresting special case. The\n> generic case that happens far more often in practice is the\n> lines moving around across files, and the new \"git blame\" gives\n> you better picture to answer \"where the heck did this come from\"\n> question.\n\nTo help the version control system underneath, I have always obeyed the \ndiscipline of not to copy/move and modify in the same commit. git has the \npotential to remove this necessity, but I'd still like all my old commits to \nhave the copies detected correctly.\n\nAs an example: I've got a colleague who works on a project where each new \nversion begins as a copy of the old one (it's not the way I'd work, but I \nthink git is flexible enough to cope with anything). So, project1/ exists \nand is copied to project2/ to begin work. I suppose this is effectively \nbranching using the filesystem rather than the version control system. I \nnoticed (and was surprised) that git didn't detect this as a copy. No files \nwere changed in the copy, so I thought git would easily spot this.\n\nThe problem is that the next project can be a copy of either project1/ or \nproject2/. All this has already gone on for a few years. I've recently \nimported this into git and was examining the history. I wanted to know for a \nparticular subdirectory (of many) which of the others it was based off. I \nwas in qgit, and found that the commit didn't show as a copy, it showed as a \ncreate, and hence I couldn't tell which was the parent project. It's a shame \nbecause all the mechanisms are there to show the operation, it just isn't \nshown (without --find-copies-harder).\n\ngit-blame is obviously of huge use for these detailed analyses of individual \nline history. However, in the simple case of a commit being a 100% copy of \nanother file, git lets me down. In fact, in the case described above, it \nwouldn't necessarily help me. What if it went like this:\n\nproject1/ copied to project2/\nproject2/ copied to project3/\n\ngit-blame on a file in project3/ will show that its contents came from a \nproject1 commit, whereas I want to know it's direct parent.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"}]}