In a repo with around 60k files with deep directory hierarchies (due to
being predominantly java code) and which had a few high level directories
moved around (making it appear to git as dozens of thousands of individual
file renames), attempts to cherry-pick commits across product versions
resulted in non-sensical delete/modify conflicts (rather than
rename/modify as expected). We had a few teams who were in the unenviable
position of having to backport hundreds or thousands of commits across
such product versions, and the result was months of pain, which could have
been alleviated were it not for a few small git bugs:
* When you try to cherry-pick changes, unlike when you merge two
branches, git will not notify you when you need to set a higher
merge.renameLimit.
* If you know git internals well enough, you can try to trick git into
telling you the correct renameLimit by doing a merge instead of a
cherry-pick. If you do that, and have a renameLimit that is too
small, git will let you know the value you need. You can then undo
the merge and proceed with the cherry-pick. Except that...
* If you are performing a merge and specify a large renameLimit that
isn't large enough, and the necessary renameLimit you need is greater
than 32767, then git tells you nothing, leading you to believe that
the limit you specified is high enough, but only to watch it still
mess up the merge badly.
* If you happen to specify a merge.renameLimit that *is* high enough,
but just happens to be greater than 32767, then git will silently
pretend you specified 32767, determine that 32767 is not high enough,
not tell you anything about it's silent clamping, and then proceed to
mess up the merge or cherry-pick badly. Not only do you get no
feedback, the clamping to 32767 isn't documented anywhere even if you
tried to read every manual page.
Folks did discover the merge.renameLimit and tried setting it to various
values, spread over the spectrum from 1000 (the default) up to 999999999
(or maybe more, that's just the highest number I heard), completely
unaware that most their attempts were ignored and wondering why git
couldn't handle things and couldn't explain why either.
Eventually folks wrote scripts that would run the output of format-patch
through a bunch of sed commands to pretend patches were against the
filename on the other side of history and then pipe back through git-am.
Such scripts grew as more and more rename rules were added.
I eventually learned of one of these scripts and said something close to,
"You don't need these pile of rename rules; just set merge.renameLimit to
something higher." When they responded that merge.renameLimit didn't
work, I didn't believe them. This patch series, along with two others
that I will be sending shortly, represent my attempt to continue to not
believe them. :-)
Elijah Newren (4):
sequencer: Warn when internal merge may be suboptimal due to
renameLimit
Remove silent clamp of renameLimit
progress: Fix progress meters when dealing with lots of work
sequencer: Show rename progress during cherry picks
diff.c | 2 +-
diffcore-rename.c | 15 ++++++---------
progress.c | 22 +++++++++++-----------
progress.h | 8 ++++----
sequencer.c | 2 ++
5 files changed, 24 insertions(+), 25 deletions(-)
--
2.15.0.5.g9567be9905
