{"thread":{"id":"47161","subject":"[PATCH 0/4] Fix issues with rename detection limits","startedAt":"2017-11-10T18:13:18Z","lastAt":"2017-11-10T18:27:37Z","messageCount":2,"participants":["Elijah Newren"],"isPatch":true,"patchVersion":1,"patchTotal":4},"messages":[{"id":"332203","messageId":"20171110181304.26236-1-newren@gmail.com","threadId":"47161","inReplyTo":null,"subject":"[PATCH 0/4] Fix issues with rename detection limits","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2017-11-10T18:13:04Z","receivedAt":"2017-11-10T18:13:18Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"In a repo with around 60k files with deep directory hierarchies (due to\nbeing predominantly java code) and which had a few high level directories\nmoved around (making it appear to git as dozens of thousands of individual\nfile renames), attempts to cherry-pick commits across product versions\nresulted in non-sensical delete/modify conflicts (rather than\nrename/modify as expected).  We had a few teams who were in the unenviable\nposition of having to backport hundreds or thousands of commits across\nsuch product versions, and the result was months of pain, which could have\nbeen alleviated were it not for a few small git bugs:\n\n  * When you try to cherry-pick changes, unlike when you merge two\n    branches, git will not notify you when you need to set a higher\n    merge.renameLimit.\n\n  * If you know git internals well enough, you can try to trick git into\n    telling you the correct renameLimit by doing a merge instead of a\n    cherry-pick.  If you do that, and have a renameLimit that is too\n    small, git will let you know the value you need.  You can then undo\n    the merge and proceed with the cherry-pick.  Except that...\n\n  * If you are performing a merge and specify a large renameLimit that\n    isn't large enough, and the necessary renameLimit you need is greater\n    than 32767, then git tells you nothing, leading you to believe that\n    the limit you specified is high enough, but only to watch it still\n    mess up the merge badly.\n\n  * If you happen to specify a merge.renameLimit that *is* high enough,\n    but just happens to be greater than 32767, then git will silently\n    pretend you specified 32767, determine that 32767 is not high enough,\n    not tell you anything about it's silent clamping, and then proceed to\n    mess up the merge or cherry-pick badly.  Not only do you get no\n    feedback, the clamping to 32767 isn't documented anywhere even if you\n    tried to read every manual page.\n\nFolks did discover the merge.renameLimit and tried setting it to various\nvalues, spread over the spectrum from 1000 (the default) up to 999999999\n(or maybe more, that's just the highest number I heard), completely\nunaware that most their attempts were ignored and wondering why git\ncouldn't handle things and couldn't explain why either.\n\nEventually folks wrote scripts that would run the output of format-patch\nthrough a bunch of sed commands to pretend patches were against the\nfilename on the other side of history and then pipe back through git-am.\nSuch scripts grew as more and more rename rules were added.\n\nI eventually learned of one of these scripts and said something close to,\n\"You don't need these pile of rename rules; just set merge.renameLimit to\nsomething higher.\"  When they responded that merge.renameLimit didn't\nwork, I didn't believe them.  This patch series, along with two others\nthat I will be sending shortly, represent my attempt to continue to not\nbelieve them.  :-)\n\nElijah Newren (4):\n  sequencer: Warn when internal merge may be suboptimal due to\n    renameLimit\n  Remove silent clamp of renameLimit\n  progress: Fix progress meters when dealing with lots of work\n  sequencer: Show rename progress during cherry picks\n\n diff.c            |  2 +-\n diffcore-rename.c | 15 ++++++---------\n progress.c        | 22 +++++++++++-----------\n progress.h        |  8 ++++----\n sequencer.c       |  2 ++\n 5 files changed, 24 insertions(+), 25 deletions(-)\n\n-- \n2.15.0.5.g9567be9905\n\n"},{"id":"332207","messageId":"CABPp-BF8WbB=hAAXg2pPLi4X1kyJYamTmm9faU-OiP7YnJn-xg@mail.gmail.com","threadId":"47161","inReplyTo":"20171110181304.26236-1-newren@gmail.com","subject":"Re: [PATCH 0/4] Fix issues with rename detection limits","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2017-11-10T18:27:31Z","receivedAt":"2017-11-10T18:27:37Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Nov 10, 2017 at 10:13 AM, Elijah Newren <newren@gmail.com> wrote:\n> In a repo with around 60k files with deep directory hierarchies (due to\n<snip>\n> Elijah Newren (4):\n>   sequencer: Warn when internal merge may be suboptimal due to\n>     renameLimit\n>   Remove silent clamp of renameLimit\n>   progress: Fix progress meters when dealing with lots of work\n>   sequencer: Show rename progress during cherry picks\n\nSorry for the duplicate send.\n\nI noticed the cover letter didn't appear on in the email list,\ndouble-checked https://public-inbox.org/git/, waited over half an hour\nand double checked both email and public-inbox again and still didn't\nsee it, so I re-sent.  Just as soon as I did, it seems that the\noriginal and the new cover letter emails suddenly showed up right\nthen.  *shrug*.\n"}]}