From: Thomas Rast <tr@thomasrast.ch>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, "Grégory Pakosz" <gregory.pakosz@gmail.com>
Subject: Re: [PATCH] diff: do not reuse_worktree_file for submodules
Date: Sun, 23 Feb 2014 13:46:37 +0100 [thread overview]
Message-ID: <87bnxyq9n6.fsf@thomasrast.ch> (raw)
In-Reply-To: <8738jbtmji.fsf@thomasrast.ch> (Thomas Rast's message of "Sat, 22 Feb 2014 12:27:29 +0100")
Thomas Rast <tr@thomasrast.ch> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Thomas Rast <tr@thomasrast.ch> writes:
>>
>>> @@ -2845,8 +2845,9 @@ static struct diff_tempfile *prepare_temp_file(const char *name,
>>> remove_tempfile_installed = 1;
>>> }
>>>
>>> - 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))) {
>>
>> I agree with the goal/end result, but I have to wonder if the
>> reuse_worktree_file() be the helper function that ought to
>> encapsulate such a logic?
>>
>> Instead of feeding it an object name and a path, if we passed a
>> diff_filespec to the helper, it would have access to the mode as
>> well. It would result in a more intrusive change, so I'd prefer to
>> see your patch applied first and then build such a refactor on top,
>> perhaps like the attached.
>
> I see that you already queued 721e727, which has the change you
> described plus moving the S_ISGITLINK test into reuse_worktree_file.
> The change looks good to me.
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?
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
--
Thomas Rast
tr@thomasrast.ch
next prev parent reply other threads:[~2014-02-23 12:47 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 [this message]
2014-02-24 17:39 ` 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=87bnxyq9n6.fsf@thomasrast.ch \
--to=tr@thomasrast.ch \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=gregory.pakosz@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.