From: Ephrim Khong <dr.khong@gmail.com>
To: GIT Mailing-list <git@vger.kernel.org>
Subject: Tracking a merge bug
Date: Mon, 26 Oct 2020 16:08:13 +0100 [thread overview]
Message-ID: <120922f1-67a9-9ae2-2e9c-56e20935e0f9@gmail.com> (raw)
Dear All,
I am trying to find the root cause for what I believe might be a strange
bug in git merge. I have a feature branch A which branched off master
not too long ago, and want to bring it up to date with master:
git checkout A
git merge master
which yields
Removing somefile
Removing anotherfile
error: add_cacheinfo failed to refresh for path 'c/d/e.sh'; merge
aborting.
the offending file, c/d/e.sh, does not exist in my feature branch but
was added to master since branching off. After aborting, the working
directory is in an inconsistent state and c/d/e.sh exists with the
correct content.
Below is a stacktrace - the merger handles the file as a rename
(apparently there is a similar / identical file 'c/f/g.sh' that is
renamed to 'c/d/e.sh'), but that fails because the file has MODE_CHANGED
set. (Which appears strange - at the time where the merge is aborting,
the file apparently was already written to the working directory. Is it
renaming two different files to the same target file?).
Any hint is appreciated, especially where to look: Is the root cause
more likely to be at the filesystem level (the stat returns something
off), or in the merge logic? What else could be wrong here?
The stacktrace looks roughly as follows:
-> read-cache.c, ie_modified(): ie_match_stat returned 63, which is
MTIME_CHANGED | CTIME_CHANGED | OWNER_CHANGED |
MODE_CHANGED | INODE_CHANGED | DATA_CHANGED
and is_modified() returns 63 because MODE_CHANGED is set.
-> read-cache.c, refresh_cache_ent(): at the call to ie_modified
-> read-cache.c, refresh_cache_entry()
-> merge-recursive.c, add_cacheinfo(), is in the refresh-path (i.e.
make_cache_entry() worked, but refresh_cache_entry() will fail)
-> merge-recursive.c, update_file_flags(), after the update_index: label
-> merge-recursive.c, update_file()
-> merge-recursive.c, handle_content_merge() is in the very last
update_file() call, close to the end of the function
-> merge-recursive.c, handle_rename_normal()
-> merge-recursive.c, process_entry()
is in the RENAME_NORMAL / RENAME_ONE_FILE_TO_ONE block
-> [...]
Thanks
- Eph
next reply other threads:[~2020-10-26 15:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-26 15:08 Ephrim Khong [this message]
2020-10-26 15:50 ` Tracking a merge bug Elijah Newren
2021-03-05 11:07 ` Ephrim Khong
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=120922f1-67a9-9ae2-2e9c-56e20935e0f9@gmail.com \
--to=dr.khong@gmail.com \
--cc=git@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).