From: Junio C Hamano <gitster@pobox.com>
To: Thomas Rast <tr@thomasrast.ch>
Cc: git@vger.kernel.org, "Grégory Pakosz" <gregory.pakosz@gmail.com>
Subject: Re: [PATCH] diff: do not reuse_worktree_file for submodules
Date: Mon, 24 Feb 2014 09:39:21 -0800 [thread overview]
Message-ID: <xmqq4n3obeba.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <87bnxyq9n6.fsf@thomasrast.ch> (Thomas Rast's message of "Sun, 23 Feb 2014 13:46:37 +0100")
Thomas Rast <tr@thomasrast.ch> writes:
> I spoke too soon; it breaks the test I wrote to cover this case, for a
> reason that gives me a headache.
>
> When we hit the conditional
>
>>>> - if (!one->sha1_valid ||
>>>> - reuse_worktree_file(name, one->sha1, 1)) {
>>>> + if (!S_ISGITLINK(one->mode) &&
>>>> + (!one->sha1_valid ||
>>>> + reuse_worktree_file(name, one->sha1, 1))) {
>
> sha1_valid=0 for the submodule on the worktree side of the diff. The
> reason is that we start out with sha1_valid=0 and sha1=000..000 for the
> worktree side of all dirty entries, which makes sense at that point. We
> later set the sha1 by looking inside the submodule in
> diff_fill_sha1_info(), but we never set sha1_valid. So the above
> conditional will now trigger on the !one->sha1_valid arm, completely
> defeating the change to reuse_worktree_file().
>
> We can fix it like below, but it feels a bit wrong to me. Are
> submodules the only case where it makes sense to set sha1_valid when we
> fill the sha1?
The meaning of filespec->sha1_valid is "Is it known that the
filespec->sha1 and filespec->mode field should be used?"; I agree
that this feels wrong.
Which means that the previous one was wrong, and your original was
the right approach. I'll drop the update.
Thanks.
>
> diff.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git i/diff.c w/diff.c
> index dabf913..cf7281d 100644
> --- i/diff.c
> +++ w/diff.c
> @@ -3081,6 +3082,8 @@ static void diff_fill_sha1_info(struct diff_filespec *one)
> die_errno("stat '%s'", one->path);
> if (index_path(one->sha1, one->path, &st, 0))
> die("cannot hash %s", one->path);
> + if (S_ISGITLINK(one->mode))
> + one->sha1_valid = 1;
> }
> }
> else
prev parent reply other threads:[~2014-02-24 17:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-15 12:19 git diff, external diff tool, and submodules Grégory Pakosz
2014-02-16 16:52 ` [PATCH] diff: do not reuse_worktree_file for submodules Thomas Rast
2014-02-18 21:01 ` Junio C Hamano
2014-02-22 11:27 ` Thomas Rast
2014-02-23 12:46 ` Thomas Rast
2014-02-24 17:39 ` Junio C Hamano [this message]
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=xmqq4n3obeba.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gregory.pakosz@gmail.com \
--cc=tr@thomasrast.ch \
/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.