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
- From: Junio C Hamano <gitster@xxxxxxxxx>
- Subject: Re: [BUG] All files in folder are moved when cherry-picking commit that moves fewer files
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
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.
[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...]