archive mirror
 help / color / mirror / Atom feed
From: Elijah Newren <>
To: Junio C Hamano <>
Cc: Git Mailing List <>,
	Adam Dinwoodie <>
Subject: Re: [PATCH] merge-recursive: ignore_case shouldn't reject intentional removals
Date: Mon, 27 Nov 2017 17:02:45 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Nov 27, 2017 at 3:39 PM, Junio C Hamano <> wrote:
> Elijah Newren <> writes:
>>> As a fix, this sorely wants something new in t/ directory.
>> Well, then perhaps I was wrong to submit it independent of my
>> directory rename series.  As noted in the (very lengthy) extended
>> commit message explanation, the assumption the previous code made just
>> happened to work ...
> Here is what I wrote in What's cooking draft (which automatically
> gets copied to the merge log message and becomes part of release
> notes when a topic graduates) for this thing.  Am I on the right
> track?
>     The code internal to the recursive merge strategy was not fully
>     prepared to see a path that is renamed to try overwriting another
>     path that is only different in case on case insensitive systems.
>     This does not matter in the current code, but will start to matter
>     once the rename detection logic starts taking hints from nearby
>     paths moving to some directory and moves a path that is otherwise
>     not changed along with them.

Yes, though I have one minor nit: I'd prefer "a new path" to "a path
that is otherwise not changed".

(Reason for the nit: "Not changed" to me implies the file existed in
the merge base and didn't change name on either side of the merge,
which in turn implies the directory remains on both sides, which means
there was no directory rename.  Since directory rename detection is
mostly about moving file adds into the right directory, this seemed
like the simplest correction.  There are also transitive renames, but
they're much less common and trying to cover them too might make it
even harder to parse.)

As a side note, the two sentences are a little bit unwieldy to try to
parse.  I couldn't come up with any concrete suggestions to improve
it, so it's probably fine, but thought I'd mention in case others spot
an easy way to simplify it.

  reply	other threads:[~2017-11-28  1:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-24 19:59 Elijah Newren
2017-11-24 20:04 ` Eric Sunshine
2017-11-24 20:29   ` Elijah Newren
2017-11-25  3:29 ` Junio C Hamano
2017-11-25 22:35   ` Elijah Newren
2017-11-26  2:32     ` Junio C Hamano
2017-11-27  3:40 ` Junio C Hamano
2017-11-27 16:40   ` Elijah Newren
2017-11-27 23:39     ` Junio C Hamano
2017-11-28  1:02       ` Elijah Newren [this message]
2019-03-04 23:07 Woody Woodman
2019-03-06 14:23 ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \
    --subject='Re: [PATCH] merge-recursive: ignore_case shouldn'\''t reject intentional removals' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).