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/87sgicaise.fsf%40gnu.org.
