{"thread":{"id":"26204","subject":"--find-copies-harder finds fewer copies/renames than -C does","startedAt":"2011-01-05T17:46:13Z","lastAt":"2011-01-06T20:42:02Z","messageCount":4,"participants":["Stefan Haller","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"158972","messageId":"1jukub7.uehx43wxtij7M%lists@haller-berlin.de","threadId":"26204","inReplyTo":null,"subject":"--find-copies-harder finds fewer copies/renames than -C does","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2011-01-05T17:46:13Z","receivedAt":"2011-01-05T17:46:13Z","isPatch":false,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"I was surprised to find out that --find-copies-harder can, under certain\ncircumstances, detect fewer renames than -C does for a given commit.\nAfter some digging I think I understand now why this is so, but I find\nit extremely unintuitive, and would like to know what other people think\nabout it. I had expected --find-copies-harder to always detect at least\nas many copies/renames as -C, and possibly more, but never less.\n\nThe case I had is this: I have a repo with about 10.000 files, and a\ncommit with 14 files being moved to a different folder; half of them\nwhere unmodified moves, the other half had one-line modifications\n(similarity index 97% or so).\n\n\"git show -C --name-status \" detects all 14 files as renames;\n\"git show --find-copies-harder --name-status \" only shows the\nunmodified moves as renames, the ones with modifications are shown as\ndelete plus add.\n\nThe reason for this seems to be the condition\n\"num_create * num_src > rename_limit * rename_limit\" in diffcore_rename;\n--find-copies-harder exeeds the limit, so it turns off inexact rename\ndectection *completely*, while -C stays well below the limit.\n\nI had expected --find-copies-harder to still do inexact rename detection\namong the changed files in the commit in this case, and turn it off only\nfor the unmodified files; I'm not familiar enough with the code to tell\nwhether that would be easy to implement though.\n\nAny thoughts?\n\n\n-- \nStefan Haller\nBerlin, Germany\nhttp://www.haller-berlin.de/\n"},{"id":"158980","messageId":"7voc7vch35.fsf@alter.siamese.dyndns.org","threadId":"26204","inReplyTo":"1jukub7.uehx43wxtij7M%lists@haller-berlin.de","subject":"Re: --find-copies-harder finds fewer copies/renames than -C does","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-05T18:59:10Z","receivedAt":"2011-01-05T18:59:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"lists@haller-berlin.de (Stefan Haller) writes:\n\n> The reason for this seems to be the condition\n> \"num_create * num_src > rename_limit * rename_limit\" in diffcore_rename;\n> --find-copies-harder exeeds the limit, so it turns off inexact rename\n> dectection *completely*, while -C stays well below the limit.\n>\n> I had expected --find-copies-harder to still do inexact rename detection\n> among the changed files in the commit in this case, and turn it off only\n> for the unmodified files; I'm not familiar enough with the code to tell\n> whether that would be easy to implement though.\n>\n> Any thoughts?\n\nTwo. When you can spend unlimited amount of resources, it would feel more\nintuitive if -C -C lifted rename-limit altogether. On the other hand, in\na project where the difference does matter (i.e. you have far too many\ncandidate sources), it is likely that -C -C without rename limit would run\nout of memory and not produce any result, so automatic lifting of rename\nlimit is unacceptable as the default.\n\nSetting rename-limit to match the size of your environment (perhaps do\nthis once in the config) would make this a non-issue, so coming up with an\nautomated way to do so might be an interesting exercise.\n"},{"id":"159036","messageId":"1juopju.rh4v4z97i9hmM%lists@haller-berlin.de","threadId":"26204","inReplyTo":"7voc7vch35.fsf@alter.siamese.dyndns.org","subject":"Re: --find-copies-harder finds fewer copies/renames than -C does","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2011-01-06T16:54:06Z","receivedAt":"2011-01-06T16:54:06Z","isPatch":false,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"Junio C Hamano wrote:\n\n> lists@haller-berlin.de (Stefan Haller) writes:\n> \n> > I had expected --find-copies-harder to still do inexact rename detection\n> > among the changed files in the commit in this case, and turn it off only\n> > for the unmodified files; I'm not familiar enough with the code to tell\n> > whether that would be easy to implement though.\n> >\n> > Any thoughts?\n> \n> Two. When you can spend unlimited amount of resources, it would feel more\n> intuitive if -C -C lifted rename-limit altogether. On the other hand, in\n> a project where the difference does matter (i.e. you have far too many\n> candidate sources), it is likely that -C -C without rename limit would run\n> out of memory and not produce any result, so automatic lifting of rename\n> limit is unacceptable as the default.\n\nBut what about the suggestion of falling back to -C if\n--find-copies-harder exceeds the rename limit, but -C does not?\nWouldn't that be the desired behaviour?\n\n\n-- \nStefan Haller\nBerlin, Germany\nhttp://www.haller-berlin.de/\n"},{"id":"159065","messageId":"7vhbdlahnp.fsf@alter.siamese.dyndns.org","threadId":"26204","inReplyTo":"1juopju.rh4v4z97i9hmM%lists@haller-berlin.de","subject":"Re: --find-copies-harder finds fewer copies/renames than -C does","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-06T20:42:02Z","receivedAt":"2011-01-06T20:42:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"lists@haller-berlin.de (Stefan Haller) writes:\n\n> But what about the suggestion of falling back to -C if\n> --find-copies-harder exceeds the rename limit, but -C does not?\n> Wouldn't that be the desired behaviour?\n\nMaybe. Patches welcome ;-)\n"}]}