Re: [PATCH] t/perf: rename duplicate-numbered test script

From: Jeff King <peff@peff.net>
Date: Aug 12, 2019, 16:13 UTC
Message-ID: <20190812161352.GB25388@sigill.intra.peff.net>
In-Reply-To: <xmqqftm6bca3.fsf@gitster-ct.c.googlers.com>

On Mon, Aug 12, 2019 at 09:04:36AM -0700, Junio C Hamano wrote:

Show 12 quoted lines

> >  t/perf/{p5600-clone-reference.sh => p5601-clone-reference.sh} | 0
> >  1 file changed, 0 insertions(+), 0 deletions(-)
> >  rename t/perf/{p5600-clone-reference.sh => p5601-clone-reference.sh} (100%)
> >
> > diff --git a/t/perf/p5600-clone-reference.sh b/t/perf/p5601-clone-reference.sh
> > similarity index 100%
> > rename from t/perf/p5600-clone-reference.sh
> > rename to t/perf/p5601-clone-reference.sh
> 
> By the way, do we feel differently (e.g. more risky) when we see
> 100% rename without the "index old-oid..new-oid mode" lines and when
> we see 99% rename with one, with a one-line change?

I saw that earlier message from Linus, too. :)

For a change like this, I don't think it matters either way. Whatever is the content of that file, my intent is to move it to a new location. So if you did have changes, moving them along with it would be the right thing.

That said, I'm not at all opposed to having more data in the patch. Even if the "apply" side doesn't do anything useful with the "index" line in such a case, it's possible it could help with tracking down a mis-merge or other confusion after the fact.

What I don't think we would want, though, is for a change on your side to reject a patch like mine (a sort of "RENAME/MODIFY" conflict, I guess, where "am" says "I can't move 1234abcd to this new filename, because that's not what I have at that path"). Our merges are already happy to port changes around when there's a rename on another branch, and this case is no different.

-Peff