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