RE: [BUG] All files in folder are moved when cherry-picking commit that moves fewer files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> 
Sent: Wednesday, 27 February 2019 18:32
To: Jeff King <peff@xxxxxxxx>
Cc: Phillip Wood <phillip.wood@xxxxxxxxxxxxx>; Linus Nilsson <Linus.Nilsson@xxxxxxxxx>; git@xxxxxxxxxxxxxxx
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@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/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?




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux