From: Jeff King <peff@peff.net>
To: Antoine Pelisse <apelisse@gmail.com>
Cc: tboegi@web.de, git@vger.kernel.org
Subject: Re: [PATCH] status: report ignored yet tracked directories
Date: Sat, 5 Jan 2013 18:03:03 -0500 [thread overview]
Message-ID: <20130105230303.GA5195@sigill.intra.peff.net> (raw)
In-Reply-To: <1357418563-6626-1-git-send-email-apelisse@gmail.com>
On Sat, Jan 05, 2013 at 09:42:43PM +0100, Antoine Pelisse wrote:
> Tracked directories (i.e. directories containing tracked files) that
> are ignored must be reported as ignored if they contain untracked files.
>
> Currently, tracked files or directories can't be reported untracked or ignored.
> Remove that constraint when searching ignored files.
>
> Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
> ---
I was expecting to see some explanation of the user-visible bug here. In
other words, what does this fix, and why does the bug only happen when
core.ignorecase is set.
Looking at your fix and remembering how the index hashing works, I think
the answer is that:
1. This bug only affects directories, because they are the only thing
that can be simultaneously "ignored and untracked" and "tracked"
(i.e., they have entries of both, and we are using
DIR_SHOW_OTHER_DIRECTORIES).
2. When core.ignorecase is false, the index name hash contains only
the file entries, and cache_name_exists returns an exact match. So
it doesn't matter if we make an extra check when adding the
directory via dir_add_name; we know that it will not be there, and
the final check is a no-op.
3. When core.ignorecase is true, we also store directory entries in
the index name hash, and this extra check is harmful; the entry
does not really exist in the index, and we still need to add it.
But that makes me wonder. In the ignorecase=false case, I claimed that
the check in dir_add_name is a no-op for mixed tracked/ignored
directories. But it is presumably not a no-op for other cases. Your
patch only turns it off when DIR_SHOW_IGNORED is set. But is it possible
for us to have DIR_SHOW_IGNORED set, _and_ to pass in a path that exists
in the index as a regular file?
I think in the normal file case, we'd expect treat_path to just tell us
that it is handled, and we would not ever call dir_add_name in the first
place. But what if we have an index entry for a file, but the working
tree now contains a directory?
I _think_ we still do not hit this code path in that instance, because
we will end up in treat_directory, and we will end up checking
directory_exists_in_index. And I cannot get it to misbehave in practice.
So I think your fix is correct, but the exact how and why is a bit
subtle.
-Peff
next prev parent reply other threads:[~2013-01-05 23:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-05 11:07 t7061: comments and one failure Torsten Bögershausen
2013-01-05 11:24 ` Jeff King
2013-01-05 11:29 ` Antoine Pelisse
2013-01-05 20:42 ` [PATCH] status: report ignored yet tracked directories Antoine Pelisse
2013-01-05 21:27 ` Torsten Bögershausen
2013-01-05 23:03 ` Jeff King [this message]
2013-01-06 16:40 ` Antoine Pelisse
2013-01-07 8:33 ` Jeff King
2013-01-06 22:09 ` [PATCH v2] status: always report ignored " Antoine Pelisse
2013-01-07 17:21 ` Torsten Bögershausen
2013-01-07 17:50 ` Junio C Hamano
2013-01-07 19:06 ` Junio C Hamano
2013-01-07 20:24 ` Antoine Pelisse
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=20130105230303.GA5195@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=apelisse@gmail.com \
--cc=git@vger.kernel.org \
--cc=tboegi@web.de \
/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).