On Thu, 21 Dec 2006 21:10:51 -0800, Junio C Hamano wrote:
> Running diff with index is what I do almost all the time.
Yes, me too. As I said, months ago I had complained about "git diff"
meaning diff from index. But I was wrong. It really is the right thing
> And it is not just limited to adding the contents of a path that
> happened to be told git for the first time. Adding the contents
> of a path that was known to git also happens only when it is in
> a presentable good state. So running "git diff" and not seeing
> what I added before is a GOOD THING.
Yes. Whenever consciously using the index, being able to stash stuff
there and not see it in "git diff" is definitely a good thing.
After a thread not so long ago, someone told me privately that they
really wished they could see more examples of when using the index is
obviously a net win to the user. He mentioned that the oft-cited
"split commit along file boundaries" isn't compelling since the same
behavior can be achieved with "commit file1 file2".
So here's another example that I was using just yesterday:
I implemented an optimization and started testing it. It had the
performance characteristics I wanted, but also introduced a couple
few regressions noticed by the test suite.
So this code wasn't ready to commit, but I stashed it all into the
index. Then I went through an iterative process of fixing the
little regressions (off-by-one bugs, etc.), using "git diff" to
see _only_ the incremental fix, and then stashing the whole result
into the index again.
Then I only committed once all the regressions were fixed.
Note that in the above scenario, the command I've been proposing
recently, ("update the index with the content of all tracked files"),
would have been quite useful.
Also note that with "git commit --amend" one could get a very similar
result by simply using the HEAD commit as the staging area instead of
the index. (And with reflogs, some might like that even better.)
So yes, "git diff" showing the difference from the index is definitely
the right thing. And it's useful whenever I'm consciously using the
index to stash some content, (as in this example), or when git does
that on my behalf (as in a conflicted merge).
My point is that I'm not always interested in stashing content just
because I want to add a new path to the index. For example, let's say
I sit down with my working tree and I just want to remember what I had
been in the middle of doing. I examine the state of things with "git
diff". It doesn't show me the content of any newly-created files, but
I want to see those as well. So I'd love to be able to easily get the
index into a state where "git diff" shows me that content.
And I'm definitely not ready to stash the content of these new
files---I haven't even looked at them yet---that's what I'd like "git
diff" to help me do at this point.
Anyway, you already said you did understand this mode of operation. So
I won't explain it over and over anymore. I really just wanted to
throw out that index-staging example for people.
-Carl
Attachment:
pgpYZLmkMZYQ7.pgp
Description: PGP signature