From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
Frank Schwidom <schwidom@gmx.net>,
git@vger.kernel.org
Subject: Re: partial commit of file-to-directory change, was Re: Bugreport
Date: Fri, 19 Jan 2024 17:22:19 -0800 [thread overview]
Message-ID: <xmqqmst0hk8k.fsf@gitster.g> (raw)
In-Reply-To: <20240120004628.GA117170@coredump.intra.peff.net> (Jeff King's message of "Fri, 19 Jan 2024 19:46:28 -0500")
Jeff King <peff@peff.net> writes:
> It might also be that the bug is earlier in list_paths(), where we
> should notice that "d" is gone and now we have entries under "d/".
We had a related discussion on "commit -i/-o tests" review thread,
where we noticed that "git commit -i foobar", when "foobar" does not
match any path in the index, silently ignore that unmatching
pathspec (but "commit -o foobar" does error out, saying "did not
match any file(s) known to git"). The important design decision we
made long time ago when we introduced partial commit ("commit -o
pathspec") is that we do not _add_ paths (that match the pathspec)
that are not tracked. We require explicit "git add" for them before
you run "git commit".
So, I suspect that list_paths() that gives "d" as a thing to add is
broken. "commit -m + ." at that point is saying "we should get the
latest contents from the working tree for all the paths in the real
index, add[*] them to the temporary index freshly read from HEAD,
and the resulting temporary index should be written out as a tree"
to create a commit, and then "the same set of contents for the paths
then should be added to the real index, so that the differences
between the tree we wrote out of the temporary index to update the
HEAD and the real index would still be the changes already in the
index before this partial commit".
Side note: here, "add" would include removing (if the working
tree file for the path is gone) or killing 'd' while adding
'd/b.txt'.
So I would understand if 'd/b.txt' is listed (because in the real
index there already is d/b.txt known), but if the directory 'd'
itself is listed, that does sound like a bug.
next prev parent reply other threads:[~2024-01-20 1:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-19 13:25 Bugreport Frank Schwidom
2024-01-19 23:14 ` Bugreport brian m. carlson
2024-01-20 0:46 ` partial commit of file-to-directory change, was Bugreport Jeff King
2024-01-20 0:55 ` Junio C Hamano
2024-01-20 1:22 ` Junio C Hamano [this message]
2024-01-25 18:54 ` Junio C Hamano
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=xmqqmst0hk8k.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=sandals@crustytoothpaste.net \
--cc=schwidom@gmx.net \
/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).