list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: Elijah Newren <>
Cc:, Adam Dinwoodie <>,
	David Turner <>,
	David Turner <>
Subject: Re: [PATCH] merge-recursive: ignore_case shouldn't reject intentional removals
Date: Sat, 25 Nov 2017 12:29:09 +0900	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Elijah Newren's message of "Fri, 24 Nov 2017 11:59:01 -0800")

Elijah Newren <> writes:

>     But what it really is forced to do is more of a 4-way merge; a good
>     chunk of its annoying complexity is based around this (undocumented
>     and unfortunate) reality.  It derives from what I consider a simple
>     design flaw.

Yes, and it does not help that it wants to write into the filesystem
while it performs the outermost merges.

In the ideal world, we should

 - ask unpack_trees() to do "read-tree -m" without "-u";

 - do all the merge-recursive computations in-core and prepare the
   resulting index, while keeping the current index intact;

 - compare the current in-core index and the resulting in-core
   index, and notice the paths that need to be added, updated or
   removed in the working tree, and ensure that there is no loss of
   information when the change is reflected to the working tree,
   e.g. the result wants to create a file where the working tree
   currently has a directory with non-expendable contents in it, the
   result wants to remove a file where the working tree file has
   local modification, etc.; and then finally

 - carry out the working tree update to make it match what the
   resulting in-core index says it should look like.


  parent reply	other threads:[~2017-11-25  3:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-24 19:59 [PATCH] merge-recursive: ignore_case shouldn't reject intentional removals Elijah Newren
2017-11-24 20:04 ` Eric Sunshine
2017-11-24 20:29   ` Elijah Newren
2017-11-25  3:29 ` Junio C Hamano [this message]
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
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:

  List information:

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

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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 read-only IMAP folder(s) and NNTP newsgroup(s).