> difftool -d formerly knew how to symlink to the work tree when the work
> tree contains uncommitted changes. In practice, prior to this change, it
> would not symlink to the work tree in case there were no uncommitted
> changes, even when the user invoked difftool with the form:
>
> git difftool -d [--options] <commit> [--] [<path>...]
> This form is to view the changes you have in your working tree
> relative to the named <commit>. You can use HEAD to compare it
> with the latest commit, or a branch name to compare with the tip
> of a different branch.
>
> Instead, prior to this change, difftool would use the file's HEAD blob
> sha1 to find its content rather than the work tree content. This change
> teaches `git diff --raw` to emit the null SHA1 for consumption by
> difftool -d, so that difftool -d will use a symlink rather than a copy
> of the file.
>
> Before:
>
> $ git diff --raw HEAD^ -- diff-lib.c
> :100644 100644 f35de0f... ead9399... M diff-lib.c
>
> After:
>
> $ ./git diff --raw HEAD^ -- diff-lib.c
> :100644 100644 f35de0f... 0000000... M diff-lib.c
When I tried this I got the expected behaviour even without this patch.
It turns out that an uncommitted, but *staged* change emits the SHA1 of
the blob rather than the null SHA1. Do you get the desired behaviour if
you "git reset" before using difftool?
If so I think you want some new mode of operation for difftool instead
of this patch which will also affect unrelated commands.
> ---
> diff-lib.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/diff-lib.c b/diff-lib.c
> index f35de0f..ead9399 100644
> --- a/diff-lib.c
> +++ b/diff-lib.c
> @@ -319,6 +319,10 @@ static int show_modified(struct rev_info *revs,
> return -1;
> }
>
> + if (!cached && hashcmp(old->sha1, new->sha1)) {
> + sha1 = null_sha1;
> + }
> +
> if (revs->combine_merges && !cached &&
> (hashcmp(sha1, old->sha1) || hashcmp(old->sha1, new->sha1))) {
> struct combine_diff_path *p;
> --
> 1.8.2.rc2.4.g7799588
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
