Re: [PATCH 0/1] t6042: fix breakage on Windows

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 16, 2019, 20:41 UTC
Message-ID: <nycvar.QRO.7.76.6.1901162137270.41@tvgsbejvaqbjf.bet>
In-Reply-To: <CABPp-BEXU7zbOgMK-JQJrNyyaek593okbWM10G1YCx0Gy0o=JA@mail.gmail.com>

Hi Elijah,

On Wed, 16 Jan 2019, Elijah Newren wrote:

Show 42 quoted lines

> Hi Dscho,
> 
> On Wed, Jan 16, 2019 at 5:37 AM Johannes Schindelin via GitGitGadget
> <gitgitgadget@gmail.com> wrote:
> >
> > Unfortunately, Travis decided to change some things under the hood that
> > affect the Windows build. As a consequence, master has not been tested in
> > quite a while, even if the test runs pretended that it had been tested :-(
> >
> > So imagine my surprise when master simply would refuse to pass the test
> > suite cleanly outside Travis, always failing at t6042, despite the fact that
> > Travis passed.
> >
> > It turns out that two files are written too quickly in succession, running
> > into the issue where Git for Windows chooses not to populate the inode and
> > device numbers in the stat data (this is a noticeable performance
> > optimization). As a consequence, Git thinks the file is unchanged, and fails
> > to pick up a modification. And no, we cannot simply undo the performance
> > optimization, it would make things prohibitively slow in particular in large
> > worktrees, and it is not like the bug is likely to be hit in reality: for
> > Git to be fooled into thinking that a file is unchanged, it has to be
> > written with the same file size, and within a 100ns time bucket (it is
> > pretty improbable that there is any real-world scenario that would run into
> > that, except of course our regression test suite).
> >
> > This patch works around this issue by forcing Git to recognize the new file
> > versions as new files (which they really are: the patch simply replaces
> >
> > git mv <old> <new> && mv <file> <new> && git add <new>`
> >
> > by
> >
> > git rm <old> && mv <file> <new> && git add <new>`
> >
> > which is not shorter, but even a performance improvement (an unnoticeable
> > one, of course).
> 
> Everything sounds good up to this final sentence.  I'm wondering if
> I'm misunderstanding or if there were some simple editing errors; in
> particular, I'm not sure what "even" means here (should it be left
> out?), and it seems like you meant "noticeable" rather than
> "unnoticeable" -- is that correct?

All I meant is that the test script now has less to do: rather than rename a file and overwrite it, it is simply deleted and written anew. In the filesystem layer, I would expect this to be a tiny fraction of a millisecond faster. Not enough to matter, but conceptually it is simpler.

Since Git does not record renames (quite intentionally so, as can be verified by reading the rather unruly arguments back in the day, disregarding even valid arguments such as: if we *do* know better than Git, why not provide a way to tell Git about renames?), there is no need to use `git mv` in this instance, either.

Ciao, Dscho