On Tue, Mar 12, 2013 at 3:24 PM, John Keeping <j...@keeping.me.uk> wrote:
> 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
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

Reply via email to