Re: [PATCH] difftool: Make directory diff symlink work tree

From: Matt McClure <matthewlmcclure@gmail.com>
Date: Mar 13, 2013, 00:26 UTC
Message-ID: <CAJELnLEmrBSiua3xe_Y7MS1SCL8TD28sQH-R6Kfn9Zk+Zm6=kw@mail.gmail.com>
In-Reply-To: <20130312192459.GD2317@serenity.lan>

On Tue, Mar 12, 2013 at 3:24 PM, John Keeping <john@keeping.me.uk> wrote:

Show 5 quoted lines

> 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?

I tried this:

$ git diff --raw HEAD^ :100644 100644 f35de0f... ead9399... M diff-lib.c

$ git reset HEAD^ Unstaged changes after reset: M diff-lib.c

$ git diff --raw :100644 100644 f35de0f... 0000000... M diff-lib.c

$ git difftool -d

and the last command did indeed create symlinks into my working tree rather than file copies.

So... it seems that using git-reset is at least a workaround to get the symlink behavior I want as a user, though the dance I have to do is a little more awkward than `git difftool -d HEAD^` would be.

> If so I think you want some new mode of operation for difftool instead
> of this patch which will also affect unrelated commands.

Are you suggesting that difftool do the reset work above given a new option or by default?

-- Matt McClure http://www.matthewlmcclure.com http://www.mapmyfitness.com/profile/matthewlmcclure