RE: [BUG] All files in folder are moved when cherry-picking commit that moves fewer files
- From
- Linus Nilsson <linus.nilsson@trimma.se>
- Date
- Feb 28, 2019, 08:16 UTC
- Message-ID
- <67C5CE5D6EC13D4DB8FC51E2F9BD262F022B8B3599@Triton.ad.trimma.se>
- In-Reply-To
- <CABPp-BGOqQ0P8ywCK_sybPOeASxPnkTq7NXW8678f=345=68-Q@mail.gmail.com>
Thanks for the answers. So it seems it's not a bug, but may lead to new merge options. I worked around it anyway, so it was not a real problem.
Med vänlig hälsning Linus Nilsson
-----Original Message----- From: Elijah Newren <newren@gmail.com> Sent: Wednesday, 27 February 2019 18:32 To: Jeff King <peff@peff.net> Cc: Phillip Wood <phillip.wood@dunelm.org.uk>; Linus Nilsson <Linus.Nilsson@trimma.se>; git@vger.kernel.org Subject: Re: [BUG] All files in folder are moved when cherry-picking commit that moves fewer files
On Wed, Feb 27, 2019 at 8:40 AM Jeff King <peff@peff.net> wrote:
Show 25 quoted lines
> > On Wed, Feb 27, 2019 at 08:02:35AM -0800, Elijah Newren wrote: > > > > > I have found what I suspect to be a bug, or at least not > > > > desirable behavior in my case. In one branch, I have moved all > > > > files in a directory to another directory. The first directory > > > > is now empty in this branch (I haven't tested whether this is significant). > > > > > > I suspect that because you've moved all the files git thinks the > > > directory has been renamed and that's why it moves a/file2 when > > > fix is cherry-picked in the example below. I've cc'd Elijah as he > > > knows more about how the directory rename detection works. > > > > Yes, Phillip is correct. If the branch you were > > merging/cherry-picking still had any files at all in the original > > directory, then no directory rename would be detected. You can read > > up more details about how it works at > > https://git.kernel.org/pub/scm/git/git.git/tree/Documentation/techni > > cal/directory-rename-detection.txt > > Is there a way to disable it (either by config, or for a single run)? > I know there's merge.renames, but it's plausible somebody might want > file-level renames but not directory-level ones. > > -Peff
Not yet. Adding such an option, similar in nature to the flags for turning off renaming detection entirely (merge.renames, diff.renames, -Xno-renames) would probably make sense (I don't see an analogy to -Xrename-threshold=, though). It might make sense as just an alternate setting of merge.renames or diff.renames, though it's possible that could get confusing with "copy" being an option. #leftoverbits for someone that wants to figure out what the option names and values should be?