On Tue, Mar 12, 2013 at 3:24 PM, John Keeping <john@xxxxxxxxxxxxx> 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 http://www.matthewlmcclure.com http://www.mapmyfitness.com/profile/matthewlmcclure -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html