From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Sergey Ivanov <icegood1980@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: bug report: add/delete instead of rename
Date: Fri, 18 Nov 2022 20:50:43 +0100 [thread overview]
Message-ID: <221118.86iljcf3a9.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <CAJCbrz5+LC9g34x0E_2HAezFNaMGW7ECSA9iXpHgnAHGoQNzHA@mail.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.
next prev parent reply other threads:[~2022-11-18 19:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-18 19:47 bug report: add/delete instead of rename Sergey Ivanov
2022-11-18 19:50 ` Ævar Arnfjörð Bjarmason [this message]
2022-11-18 20:00 ` Sergey Ivanov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=221118.86iljcf3a9.gmgdl@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=icegood1980@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox