bug report: add/delete instead of rename

bug report: add/delete instead of rename

[Sergey Ivanov]

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.


[System Info]
git version:
git version 2.37.2
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 5.19.0-23-generic #24-Ubuntu SMP PREEMPT_DYNAMIC Fri Oct
14 15:39:57 UTC 2022 x86_64
compiler info: gnuc: 12.1
libc info: glibc: 2.36
$SHELL (typically, interactive shell): /bin/bash


[Enabled Hooks]
not run from a git repository - no hooks to show


-- 
Kind regards,
Sergey Ivanov

Re: bug report: add/delete instead of rename

[Ævar Arnfjörð Bjarmason]

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.

Re: bug report: add/delete instead of rename

[Sergey Ivanov]

Awesome, thanks!

пт, 18 нояб. 2022 г. в 21:53, Ævar Arnfjörð Bjarmason <avarab@gmail.com>:
>
>
> 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.



-- 
Kind regards,
Sergey Ivanov