From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: David Turner <novalis@novalis.org>,
Johannes Schindelin <johannes.schindelin@gmx.de>,
git@vger.kernel.org
Subject: Re: [PATCH 5/5] path.c: don't call the match function without value in trie_find()
Date: Wed, 23 Oct 2019 18:20:48 +0200 [thread overview]
Message-ID: <20191023162048.GI4348@szeder.dev> (raw)
In-Reply-To: <xmqqa79si003.fsf@gitster-ct.c.googlers.com>
On Wed, Oct 23, 2019 at 01:01:00PM +0900, Junio C Hamano wrote:
> SZEDER Gábor <szeder.dev@gmail.com> writes:
>
> >> - b9317d55a3 added two new keys to the trie: 'logs/refs/rewritten'
> >> and 'logs/refs/worktree', next to the already existing
> >> 'logs/refs/bisect'. This resulted in a trie node with the path
> >> 'logs/refs', which didn't exist before, and which doesn't have a
> >
> > Oops, I missed the trailing slash, that must be 'logs/refs/'!
> >
> >> value attached. A query for 'logs/refs/' finds this node and then
> >> hits that one callsite of the match function which doesn't check
> >> for the value's existence, and thus invokes the match function
> >> with NULL as value.
>
> Given that the trie is maintained by hand in common_list[], I wonder
> if we can mechanically catch errors like the one b9317d55a3 added,
> by perhaps having a self-test function that a t/helper/ program
> calls to perform consistency check after the "git" gets built.
I'm not sure what you mean by "consistency check". The resulting trie
looked as expected both before and after b9317d55a3, i.e. each trie
node had the right contents, value, and children, as far as I could
tell. The issue was in the lookup function.
next prev parent reply other threads:[~2019-10-23 16:20 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-16 7:07 [PATCH 0/2] Handle git_path() with lock files correctly in worktrees Johannes Schindelin via GitGitGadget
2019-10-16 7:07 ` [PATCH 1/2] t1400: wrap setup code in test case Johannes Schindelin via GitGitGadget
2019-10-16 7:07 ` [PATCH 2/2] git_path(): handle `.lock` files correctly Johannes Schindelin via GitGitGadget
2019-10-16 11:04 ` SZEDER Gábor
2019-10-17 7:15 ` Junio C Hamano
2019-10-17 22:05 ` Johannes Schindelin
2019-10-18 11:06 ` SZEDER Gábor
2019-10-18 11:35 ` SZEDER Gábor
2019-10-21 16:00 ` [PATCH 0/5] path.c: a couple of common dir/trie fixes SZEDER Gábor
2019-10-21 16:00 ` [PATCH 1/5] Documentation: mention more worktree-specific exceptions SZEDER Gábor
2019-10-21 16:00 ` [PATCH 2/5] path.c: clarify trie_find()'s in-code comment SZEDER Gábor
2019-10-21 16:00 ` [PATCH 3/5] path.c: mark 'logs/HEAD' in 'common_list' as file SZEDER Gábor
2019-10-21 16:00 ` [PATCH 4/5] path.c: clarify two field names in 'struct common_dir' SZEDER Gábor
2019-10-21 16:00 ` [PATCH 5/5] path.c: don't call the match function without value in trie_find() SZEDER Gábor
2019-10-21 17:39 ` David Turner
2019-10-21 20:57 ` SZEDER Gábor
2019-10-23 4:01 ` Junio C Hamano
2019-10-23 16:20 ` SZEDER Gábor [this message]
2019-10-24 3:29 ` Junio C Hamano
2019-10-28 10:57 ` Johannes Schindelin
2019-10-28 12:00 ` SZEDER Gábor
2019-10-28 21:30 ` Johannes Schindelin
2019-10-18 11:42 ` [PATCH 0/2] path.c: minor common_list fixes SZEDER Gábor
2019-10-18 11:42 ` [PATCH 1/2] path.c: fix field name in 'struct common_dir' SZEDER Gábor
2019-10-18 11:42 ` [PATCH 2/2] path.c: mark 'logs/HEAD' in 'common_list' as file SZEDER Gábor
2019-10-21 19:35 ` [PATCH 0/2] path.c: minor common_list fixes Johannes Schindelin
2019-10-17 22:07 ` [PATCH v2 0/2] Handle git_path() with lock files correctly in worktrees Johannes Schindelin via GitGitGadget
2019-10-17 22:07 ` [PATCH v2 1/2] t1400: wrap setup code in test case Johannes Schindelin via GitGitGadget
2019-10-17 22:07 ` [PATCH v2 2/2] git_path(): handle `.lock` files correctly Johannes Schindelin via GitGitGadget
2019-10-18 1:23 ` Junio C Hamano
2019-10-18 12:35 ` SZEDER Gábor
2019-10-21 20:26 ` Johannes Schindelin
2019-10-23 2:12 ` Junio C Hamano
2019-10-21 21:54 ` [PATCH v3 0/2] Handle git_path() with lock files correctly in worktrees Johannes Schindelin via GitGitGadget
2019-10-21 21:54 ` [PATCH v3 1/2] t1400: wrap setup code in test case Johannes Schindelin via GitGitGadget
2019-10-21 21:54 ` [PATCH v3 2/2] git_path(): handle `.lock` files correctly Johannes Schindelin via GitGitGadget
2019-10-22 16:01 ` SZEDER Gábor
2019-10-23 3:38 ` Junio C Hamano
2019-10-28 12:01 ` Johannes Schindelin
2019-10-28 12:32 ` SZEDER Gábor
2019-10-28 17:30 ` Junio C Hamano
2019-10-28 12:57 ` [PATCH v4 0/2] Handle git_path() with lock files correctly in worktrees Johannes Schindelin via GitGitGadget
2019-10-28 12:57 ` [PATCH v4 1/2] t1400: wrap setup code in test case Johannes Schindelin via GitGitGadget
2019-10-28 12:57 ` [PATCH v4 2/2] git_path(): handle `.lock` files correctly Johannes Schindelin via GitGitGadget
2019-10-29 3:39 ` [PATCH v4 0/2] Handle git_path() with lock files correctly in worktrees 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=20191023162048.GI4348@szeder.dev \
--to=szeder.dev@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johannes.schindelin@gmx.de \
--cc=novalis@novalis.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).