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]

 



Hi Linus

On 27/02/2019 12:47, Linus Nilsson wrote:
Hi

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.

Best Wishes

Phillip

I cherry-picked the commit to another branch that has additional files in the first directory. All the files in the first directory are now moved to the second directory, and not just the files that were moved in the original commit. It happens in Git for Windows, versions 2.20.1 and 2.21.0.

It can be reproduced using these steps:

$ git init
$ mkdir a
$ echo Hello > a/file1
$ git add a/file1
$ git commit -m 'Add file1'
$ git checkout -b fix
$ mkdir b
$ git mv a/file1 b
$ git commit -m 'Move file1 to b'
$ git checkout master
$ echo Bye > a/file2
$ git add a/file2
$ git commit -m 'Add file2'
$ git cherry-pick fix
[master 5b63afb] Move file1 to b
  Date: Wed Feb 27 13:27:45 2019 +0100
  2 files changed, 0 insertions(+), 0 deletions(-)
  rename {a => b}/file1 (100%)
  rename {a => b}/file2 (100%)

Regards
Linus Nilsson




[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