Web lists-archives.com

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@xxxxxxxx> wrote:
> 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/technical/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?