Re: bug report: add/delete instead of rename

>
>
> 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.