Re: [PATCH v10 00/36] Add directory rename detection to git

From: Elijah Newren <newren@gmail.com>
Date: Apr 23, 2018, 17:28 UTC
Message-ID: <CABPp-BHMt1Hjr8A_wkxvSExV9ALgG5032vV5uEE2-HtpYuA9QQ@mail.gmail.com>
In-Reply-To: <20180419175823.7946-1-newren@gmail.com>

On Thu, Apr 19, 2018 at 10:57 AM, Elijah Newren <newren@gmail.com> wrote:

Show 14 quoted lines

> Additional testing:
>
>   * I've re-merged all ~13k merge commits in git.git with both
>     git-2.17.0 and this version of git, comparing the results to each
>     other in detail.  (Including stdout & stderr, as well as the output
>     of subsequent commands like `git status`, `git ls-files -s`, `git
>     diff -M`, `git diff -M --staged`).  The only differences were in 23
>     merges of either git-gui or gitk which involved directory renames
>     (e.g. git-2.17.0's merge would result in files like 'lib/tools.tcl'
>     or 'po/ru.po' instead of the expected 'git-gui/lib/tools.tcl' or
>     'gitk-git/po/ru.po')
>
>   * I'm trying to do the same with linux.git, but it looks like that will
>     take nearly a week to complete...

Results after restarting[1] and throwing some big hardware at it to get faster completion:

Out of 53288 merge commits with exactly two parents in linux.git:
  - 48491 merged identically
  - 4737 merged the same other than a few different "Auto-merging
    <filename>" output lines (as expected due to patch 35/36)
  - 53 merged the same other than different "Checking out files: ..."
    output (I just did a plain merge; no flags like --no-progress)
  - the remaining 7 commits had non-trivial merge differences, all
    attributable to directory rename detection kicking in

So, it looks good to me. If anyone has suggestions for other testing to do, let me know.

[1] Restarted so it could include my unpack_trees fix (from Message-Id20180421193736.12722-1-newren@gmail.com) plus a couple minor fixup commits (fixing some testcase nits and a comment typo).