From: Junio C Hamano <gitster@pobox•com>
To: Jaime Soriano Pastor <jsorianopastor@gmail•com>
Cc: git@vger•kernel.org
Subject: Re: [PATCH] Check order when reading index
Date: Thu, 21 Aug 2014 11:51:05 -0700 [thread overview]
Message-ID: <xmqq38cpsmli.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1408628606-12975-1-git-send-email-jsorianopastor@gmail.com> (Jaime Soriano Pastor's message of "Thu, 21 Aug 2014 15:43:26 +0200")
Jaime Soriano Pastor <jsorianopastor@gmail•com> writes:
> Signed-off-by: Jaime Soriano Pastor <jsorianopastor@gmail•com>
> ---
> read-cache.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/read-cache.c b/read-cache.c
> index 7f5645e..e117d3a 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -1438,6 +1438,21 @@ static struct cache_entry *create_from_disk(struct ondisk_cache_entry *ondisk,
> return ce;
> }
>
> +void check_next_ce(struct cache_entry *ce, struct cache_entry *next_ce) {
Have opening brace for the function on its own line, i.e.
void check_next_ce(struct cache_entry *ce, struct cache_entry *next_ce)
{
The function might be misnamed (see below), though.
> + if (!ce || !next_ce)
> + return;
Hmph, would it be either a programming error or a corrupt index
input to see a NULL in either of these variables?
> + if (cache_name_compare(ce->name, ce_namelen(ce),
> + next_ce->name, ce_namelen(next_ce)) > 1)
An odd indentation that is overly deep to make it hard to read.
if (cache_name_compare(ce->name, ce_namelen(ce),
next_ce->name, ce_namelen(next_ce)) > 1)
should be sufficient (replacing 7-SP before next_ce with a HT is OK
if the existing code nearby does so).
What is the significance of the return value from cache_name_compare()
that is strictly greater than 1 (as opposed to merely "is it positive?")?
Perhaps you want something that is modeled after ce_same_name() that
ignores the stage, i.e.
int ce_name_compare(const struct cache_entry *a, const struct cache_entry *b)
{
return strcmp(a->ce_name, b->ce_name);
}
without reimplementing the cache-name-compare() as
int bad_ce_same_name(const struct cache_entry *a, const struct cache_entry *b)
{
return !ce_same_name(a, b);
}
to keep the "two names with different length could never be the
same" optimization.
- if (0 <= ce_name_compare(ce, next)) then the names are not sorted
- if (!stage(ce) && !name_compare(ce, next)) then the merged
entry 'ce' is not the only entry for the path
> + die("Unordered stage entries in index");
> + if (ce_same_name(ce, next_ce)) {
> + if (!ce_stage(ce))
> + die("Multiple stage entries for merged file '%s'",
> + ce->name);
> + if (ce_stage(ce) >= ce_stage(next_ce))
> + die("Unordered stage entries for '%s'", ce->name);
> + }
> +}
> +
> /* remember to discard_cache() before reading a different cache! */
> int read_index_from(struct index_state *istate, const char *path)
> {
> @@ -1499,6 +1514,9 @@ int read_index_from(struct index_state *istate, const char *path)
> ce = create_from_disk(disk_ce, &consumed, previous_name);
> set_index_entry(istate, i, ce);
>
> + if (i > 0)
> + check_next_ce(istate->cache[i-1], ce);
Have a SP each on both sides of binary operator "-".
Judging from the way this helper function is used, it looks like
check_with_previous_ce() is a more appropriate name. After all, you
are not checking the next ce which you haven't even created yet ;-)
Thanks.
next prev parent reply other threads:[~2014-08-21 18:51 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-12 15:31 [PATCH] read-cache.c: Ensure unmerged entries are removed Jaime Soriano Pastor
2014-08-12 15:31 ` Jaime Soriano Pastor
2014-08-12 18:39 ` Junio C Hamano
2014-08-13 22:10 ` Jaime Soriano Pastor
2014-08-13 23:04 ` Junio C Hamano
2014-08-15 19:50 ` Jaime Soriano Pastor
2014-08-15 21:45 ` Junio C Hamano
2014-08-16 14:51 ` Jaime Soriano Pastor
2014-08-18 16:34 ` Junio C Hamano
2014-08-18 17:23 ` Jaime Soriano Pastor
2014-08-20 11:25 ` [PATCH 0/4] Handling unmerged files with merged entries Jaime Soriano Pastor
2014-08-20 11:26 ` [PATCH 1/4] read_index_unmerged doesn't loop forever if merged stage exists for unmerged file Jaime Soriano Pastor
2014-08-20 11:26 ` [PATCH 2/4] Error out when adding a file with merged and unmerged entries Jaime Soriano Pastor
2014-08-20 11:26 ` [PATCH 3/4] Added tests for the case of merged and unmerged entries for the same file Jaime Soriano Pastor
2014-08-20 21:00 ` Junio C Hamano
2014-08-21 13:51 ` Jaime Soriano Pastor
2014-08-21 22:21 ` Junio C Hamano
2014-08-20 11:26 ` [PATCH 4/4] git update-index --cacheinfo can be used to select a stage when there are merged and unmerged entries Jaime Soriano Pastor
2014-08-20 21:08 ` Junio C Hamano
2014-08-21 13:57 ` Jaime Soriano Pastor
2014-08-20 22:19 ` [PATCH 0/4] Handling unmerged files with merged entries Junio C Hamano
2014-08-21 13:42 ` Jaime Soriano Pastor
2014-08-21 13:43 ` [PATCH] Check order when reading index Jaime Soriano Pastor
2014-08-21 13:49 ` Jaime Soriano Pastor
2014-08-21 13:59 ` Duy Nguyen
2014-08-21 18:51 ` Junio C Hamano [this message]
2014-08-24 17:57 ` [PATCH 1/2] " Jaime Soriano Pastor
2014-08-24 17:57 ` [PATCH 2/2] Loop index increases monotonically when reading unmerged entries Jaime Soriano Pastor
2014-08-24 18:04 ` Jaime Soriano Pastor
2014-08-25 17:09 ` Junio C Hamano
2014-08-25 17:21 ` [PATCH 1/2] Check order when reading index Junio C Hamano
2014-08-25 19:44 ` Jeff King
2014-08-25 20:52 ` Junio C Hamano
2014-08-26 12:08 ` Jaime Soriano Pastor
2014-08-26 12:20 ` Jeff King
2014-08-26 16:53 ` Junio C Hamano
2014-08-26 17:22 ` Jaime Soriano Pastor
2014-08-26 17:43 ` Junio C Hamano
2014-08-27 19:48 ` [PATCH 1/2] read_index_from(): catch out of order entries when reading an index file Jaime Soriano Pastor
2014-08-27 19:48 ` [PATCH 2/2] read_index_unmerged(): remove unnecessary loop index adjustment Jaime Soriano Pastor
2014-08-29 2:16 ` [PATCH 1/2] read_index_from(): catch out of order entries when reading an index file Eric Sunshine
2014-08-29 8:54 ` [PATCH] " Jaime Soriano Pastor
2014-08-29 17:06 ` Junio C Hamano
2014-08-27 19:52 ` [PATCH 1/2] Check order when reading index Jaime Soriano Pastor
2014-08-27 21:11 ` Junio C Hamano
2014-08-27 22:13 ` Jaime Soriano Pastor
2014-08-25 20:26 ` Jaime Soriano Pastor
2014-08-21 18:40 ` [PATCH 0/4] Handling unmerged files with merged entries Johannes Sixt
2014-08-21 22:18 ` Junio C Hamano
2014-08-12 18:31 ` [PATCH] read-cache.c: Ensure unmerged entries are removed Junio C Hamano
2014-08-13 22:10 ` Jaime Soriano Pastor
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=xmqq38cpsmli.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=jsorianopastor@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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