Hi Tassilo, I don't believe that config variable works correctly.
There is currently some work being done by Elijah Newren on trying to refactor and consolidate all the different bits of merge and rename detection code, and that (IIRC) was one of the issues (and there are many). Have a search of the Git email archive for more info https://lore.kernel.org/git/?q=renameLimit e.g. Look for the cover letter to his patch series. Also https://lore.kernel.org/git/20180426205202.23056-2-benpe...@microsoft.com/ Philip On 13/03/2020 06:08, Tassilo Horn wrote: > Hi all, > > I frequently merge between branches, thus I use above-standard values > for diff.renameLimit and merge.renameLimit. Recently, there was a large > restructuring on the master branch where almost all files where moved. > So when merging fixes from the last release branch into master, git > would start with > > Performing inexact rename detection: 100% (469630720/469630720), done. > > which took about a minute before actually doing the merge. Well, that's > expected. > > Well, now the next release branch has been created from master, so now I > only merge from that into master (which is cheap again). I only > cherry-prick some individual fixes from the previous release branch into > the new release branch. When doing so, I get the very same output > > Performing inexact rename detection: 100% (469630720/469630720), done. > > with the very same running time, no matter how large the actual changes > in the cherry-picked commit are. I.e., when cherry-picking a commit > changing only one single line of code, it takes a minute, just as it > takes a minute to cherry-pick a very large commit, just as it would take > a minute to do do an actual merge containing dozens of commits. > > Is that expected? I had assumed that git only needs to compute the > corresponding possibly renamed files for the ones that are actually > affected by the changes going to be merged/picked, not for all file in > the project. > > Bye, > Tassilo > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/f286babd-7e35-402b-7365-6e0eddaad8c8%40iee.email.
