git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Elijah Newren <newren@gmail.com>
Cc: Jeff King <peff@peff.net>,
	Phillip Wood <phillip.wood@dunelm.org.uk>,
	Linus Nilsson <Linus.Nilsson@trimma.se>,
	"git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [BUG] All files in folder are moved when cherry-picking commit that moves fewer files
Date: Fri, 01 Mar 2019 11:52:41 +0900	[thread overview]
Message-ID: <xmqq7edj9uh2.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: CABPp-BGOqQ0P8ywCK_sybPOeASxPnkTq7NXW8678f=345=68-Q@mail.gmail.com

As you know that I've always been skeptical to this rename-directory
business, this probably won't come as a surprise, but I seriously
think directory renames should be made opt-in, and as a separate
option, making the option three-way.  I.e.

 - do we do any renames (yes/no)?

 - if we do do renames, do we base the decision only on the contents
   of the thing along, or do we allow neighbouring files affect the
   decision?
 
That is, in addition to the traditional --renames or -M, we'd have a
separate bool --allow-directory-renames that is by default off and
is a no-op if the former is off.

We had to fix a breakage recently for 3-way fallback case, and we
explained the fix as needed because the case lacks the full
information, but I think even with the full information at hand, the
rename-directory heurisitcs is inherently riskier than the content
based rename detection.

Suppose you had F1, F2, ... in directory D1, and moved them all to
D1/D2.  In the meantime, somebody else adds Fn to directory D1.  It
may be likely that some variant of Fn would want to go to D1/D2, but
it also is very likely that there should be a difference between
D1/Fn somebody else had, and the contents of D1/D2/Fn in the merge
result.  Perhaps D1/F1 in your preimage used to refer to another
path in the top-level directory as "../top", but the reference would
have been rewritten to "../../top" when you moved D1/F1 to D1/D2/F1,
and the person doing the merge should at least check if D1/Fn that
comes from the other party needs a similar adjustment while merged.

In the above scenario, if there were D1/Fn in _your_ preimage and
all the other party did was to make in-place modification, the story
is vastly different.  Most likely you would have made most of, if
not all, the adjustment necessary for D1/Fn to sit in its new
location, while the other party kept the relative reference to other
places intact, so we can say that both parties have say in the
contents of the auto-merged result.  The "since neighgours moved,
this must also want to move the same way" heuristics does not give a
chance to the party that is not aware of the move to prepare the
contents appropriate for the new location, by definition, so the
onus is on the person who merges to adjust the contents.

Thanks.

[jch: I am still mostly offline til the next week, but I had a
chance to sit in front of my mailbox long enough, so...]

  parent reply	other threads:[~2019-03-01  2:52 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-27 12:47 [BUG] All files in folder are moved when cherry-picking commit that moves fewer files Linus Nilsson
2019-02-27 14:30 ` Phillip Wood
2019-02-27 16:02   ` Elijah Newren
2019-02-27 16:40     ` Jeff King
2019-02-27 17:31       ` Elijah Newren
2019-02-28  8:16         ` Linus Nilsson
2019-03-01  2:52         ` Junio C Hamano [this message]
2019-03-02 23:48           ` Elijah Newren
2019-03-03  1:33             ` Junio C Hamano
2019-03-06  0:27               ` Elijah Newren
2019-03-06  4:43                 ` Junio C Hamano
2019-03-07  4:14                   ` Elijah Newren
2019-03-07  5:45                     ` Junio C Hamano
2019-03-07  5:45                     ` Junio C Hamano
2019-03-30  0:33                 ` [PATCH v2 00/15] Switch directory rename detection default Elijah Newren
2019-03-30  0:33                   ` [PATCH v2 01/15] Use 'unsigned short' for mode, like diff_filespec does Elijah Newren
2019-03-30  0:33                   ` [PATCH v2 02/15] merge-recursive: rename merge_options argument from 'o' to 'opt' Elijah Newren
2019-03-30  0:33                   ` [PATCH v2 03/15] merge-recursive: rename diff_filespec 'one' to 'o' Elijah Newren
2019-03-30  0:33                   ` [PATCH v2 04/15] merge-recursive: rename locals 'o' and 'a' to 'obuf' and 'abuf' Elijah Newren
2019-03-30  0:33                   ` [PATCH v2 05/15] merge-recursive: use 'ci' for rename_conflict_info variable name Elijah Newren
2019-03-30  0:33                   ` [PATCH v2 06/15] merge-recursive: move some struct declarations together Elijah Newren
2019-03-30  0:33                   ` [PATCH v2 07/15] merge-recursive: shrink rename_conflict_info Elijah Newren
2019-03-30  0:33                   ` [PATCH v2 08/15] merge-recursive: remove ren[12]_other fields from rename_conflict_info Elijah Newren
2019-03-30  0:33                   ` [PATCH v2 09/15] merge-recursive: track branch where rename occurred in rename struct Elijah Newren
2019-03-30  0:33                   ` [PATCH v2 10/15] merge-recursive: cleanup handle_rename_* function signatures Elijah Newren
2019-03-30  0:33                   ` [PATCH v2 11/15] merge-recursive: switch from (oid,mode) pairs to a diff_filespec Elijah Newren
2019-03-30  0:33                   ` [PATCH v2 12/15] t6043: fix copied test description to match its purpose Elijah Newren
2019-03-30  0:33                   ` [PATCH v2 13/15] merge-recursive: track information associated with directory renames Elijah Newren
2019-03-30  0:33                   ` [PATCH v2 14/15] merge-recursive: give callers of handle_content_merge() access to contents Elijah Newren
2019-03-30  0:33                   ` [PATCH v2 15/15] merge-recursive: switch directory rename detection default Elijah Newren
2019-03-30  9:12                     ` Ævar Arnfjörð Bjarmason
2019-04-01 15:41                       ` Elijah Newren
2019-04-05 15:00                   ` [PATCH v3 00/15] Switch " Elijah Newren
2019-04-05 15:00                     ` [PATCH v3 01/15] Use 'unsigned short' for mode, like diff_filespec does Elijah Newren
2019-04-05 15:00                     ` [PATCH v3 02/15] merge-recursive: rename merge_options argument from 'o' to 'opt' Elijah Newren
2019-04-05 15:00                     ` [PATCH v3 03/15] merge-recursive: rename diff_filespec 'one' to 'o' Elijah Newren
2019-04-05 15:00                     ` [PATCH v3 04/15] merge-recursive: rename locals 'o' and 'a' to 'obuf' and 'abuf' Elijah Newren
2019-04-05 15:00                     ` [PATCH v3 05/15] merge-recursive: use 'ci' for rename_conflict_info variable name Elijah Newren
2019-04-05 15:00                     ` [PATCH v3 06/15] merge-recursive: move some struct declarations together Elijah Newren
2019-04-05 15:00                     ` [PATCH v3 07/15] merge-recursive: shrink rename_conflict_info Elijah Newren
2019-04-05 15:00                     ` [PATCH v3 08/15] merge-recursive: remove ren[12]_other fields from rename_conflict_info Elijah Newren
2019-04-05 15:00                     ` [PATCH v3 09/15] merge-recursive: track branch where rename occurred in rename struct Elijah Newren
2019-04-05 15:00                     ` [PATCH v3 10/15] merge-recursive: cleanup handle_rename_* function signatures Elijah Newren
2019-04-05 15:00                     ` [PATCH v3 11/15] merge-recursive: switch from (oid,mode) pairs to a diff_filespec Elijah Newren
2019-04-05 15:00                     ` [PATCH v3 12/15] t6043: fix copied test description to match its purpose Elijah Newren
2019-04-05 15:00                     ` [PATCH v3 13/15] merge-recursive: track information associated with directory renames Elijah Newren
2019-04-05 15:00                     ` [PATCH v3 14/15] merge-recursive: give callers of handle_content_merge() access to contents Elijah Newren
2019-04-05 15:00                     ` [PATCH v3 15/15] merge-recursive: switch directory rename detection default Elijah Newren
2019-04-05 16:32                     ` [PATCH v3 00/15] Switch " Jacob Keller

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=xmqq7edj9uh2.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=Linus.Nilsson@trimma.se \
    --cc=git@vger.kernel.org \
    --cc=newren@gmail.com \
    --cc=peff@peff.net \
    --cc=phillip.wood@dunelm.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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.
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).