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.com \
--cc=git@vger.kernel.org \
--cc=jsorianopastor@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.