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

2013-03-13 Thread John Keeping
On Tue, Mar 12, 2013 at 08:26:21PM -0400, Matt McClure wrote: > On Tue, Mar 12, 2013 at 3:24 PM, John Keeping wrote: > > 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

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

2013-03-12 Thread Matt McClure
On Tue, Mar 12, 2013 at 3:24 PM, John Keeping 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" be

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

2013-03-12 Thread John Keeping
On Tue, Mar 12, 2013 at 05:12:28PM -0600, Matt McClure wrote: > On Mar 12, 2013, at 1:25 PM, John Keeping wrote: > > > When I tried this I got the expected behaviour even without this patch. > > git diff --raw commit > > emits the null SHA1 if the working tree file's stat differs from the >

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

2013-03-12 Thread Matt McClure
On Mar 12, 2013, at 1:25 PM, John Keeping wrote: > When I tried this I got the expected behaviour even without this patch. git diff --raw commit emits the null SHA1 if the working tree file's stat differs from the blob corresponding to commit. Is that the case you observed? -- To unsubscrib

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

2013-03-12 Thread John Keeping
> 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 diff