On Tue, Mar 12, 2013 at 12:09 PM, John Keeping <j...@keeping.me.uk> wrote:
> On Tue, Mar 12, 2013 at 02:12:29PM -0400, Matt McClure wrote:
>> On Tue, Nov 27, 2012 at 7:41 AM, Matt McClure <matthewlmccl...@gmail.com>
>> wrote:
>> Your thoughts on the change?
>
> Please include the patch in your message so that interested parties can
> comment on it here, especially since the compare view on GitHub seems to
> mangle the tabs.
>
> For others' reference the patch is:
>
> -- >8 --
> From: Matt McClure <matt.mccl...@mapmyfitness.com>
> Subject: [PATCH] difftool: Make directory diff symlink work tree
>
> 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
Interesting approach. While this does get the intended behavior
for difftool, I'm afraid this would be a grave regression for
existing "git diff --raw" users who cannot have such behavior.
I don't think we could do this without adding an additional flag
to trigger this change in behavior (e.g. --null-sha1-for-....?)
so that existing users are unaffected by the change.
It feels like forcing the null SHA-1 is heavy-handed, but I
haven't thought it through enough.
While this may be a quick way to get this behavior,
I wonder if there is a better way.
Does anybody else have any comments/suggestions on how to
better accomplish this?
> ---
> 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
>
--
David
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
