Re: bug report: add/delete instead of rename

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

 



On Fri, Nov 18 2022, Sergey Ivanov wrote:

> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
>
> What did you do before the bug happened?
>
> hard rename of files and directories via 'git mv' . git status before
> commit for some related files:
>
> Changes to be committed:
>   (use "git restore --staged <file>..." to unstage)
>
> new file:   sepolicy/private/file.te
> renamed:    sepolicy/components/icl_infotainment.te ->
> sepolicy/private/icl_infotainment.te
> renamed:    sepolicy/common/hal_icl_infotainment.te ->
> sepolicy/public/icl_infotainment.te
> renamed:    sepolicy/common/file.te -> sepolicy/public/file.te
>
> Changes not staged for commit:
>   (use "git add/rm <file>..." to update what will be committed)
>   (use "git restore <file>..." to discard changes in working directory)
> modified:   sepolicy/private/icl_infotainment.te
> modified:   sepolicy/public/file.te
>
> What did you expect to happen?
>
> All related nodes are renamed during commit
>
> What happened instead? (Actual behavior)
>
> delete mode 100644 sepolicy/common/file.te
> delete mode 100644 sepolicy/components/icl_infotainment.te
> create mode 100644 sepolicy/private/icl_infotainment.te
> create mode 100644 sepolicy/private/file.te
> create mode 100644 sepolicy/public/file.te
> rename sepolicy/{common/hal_icl_infotainment.te =>
> public/icl_infotainment.te} (90%)
>
> What's different between what you expected and what actually happened?
>
> Instead of renaming 2 more pairs of create/delete formed.
> It makes harder to see changes on gitlab UI after push.
>
> Anything else you want to add:
>
> Please review the rest of the bug report below.
> You can delete any lines you don't wish to share.

Git, unlike some other SCM's (e.g. SVN) doesn't track renames at
all. I.e. it doesn't matter if you use "git mv", or just manually remove
a file, "git add" that removal, add another file separately etc.

So I think you're probably just running into that. I.e. "renames" are
heuristically determined based on how similar the file is
before/after. Likely you rewrote it more than the rename detection was
willing to accept.

But see the "git log" manual for details, as it's a heuristic you can
tweak it, and e.g. set -M<n> for how similar two files should be before
they're considered a rename.



[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