I like how gitk shows the local changes as an unnamed commit at the top, 
but what I *don't* like is how it just ignored the difference between 
stuff that has been added to the index, and stuff that hasn't..

It would be very nice to have *two* such commits (either or both of which 
just disappear), where the top-most is the diff to the index, and the 
second is the diff from the index to HEAD.

That would not only be useful in general, it would be a wonderful way to 
visually introduce people to the notion of what the staging area is all 
about.

I think "gitk" was a great way early in git history to show how the git 
commit history works and that it made a lot of people understand a lot 
more how everything tied together (in a way that would have been much 
nastier to visualize with just the SHA1's in "git log"), and I think it 
could do the same thing for the staging area, which still seems to 
occasionally come up as an issue that confuses some people.

But my inability with tcl/tk precludes me from actually changing the logic 
that does

	git diff-index HEAD

into two different things that do the two operations

	git diff-index --cached HEAD
	git diff-files

respectively and ties them together as the two fake commits...

Paul?

			Linus
-

Try this, let me know what you think.  I called the changes in the
working directory "Local uncommitted changes, not checked in to index"
and the changes in the index "Local changes checked in to index but
not committed".  If you prefer some other wording, let me know.  I
made the working directory commit red (as before) and the index commit
magenta, as being between red and blue.  The index commit gets a fake
SHA1 id of 00..001.

Paul.

diff --git a/gitk b/gitk
index 39e452a..7ce86b8 100755
--- a/gitk
+++ b/gitk
@@ -262,11 +262,11 @@ proc chewcommits {view} {
 	set tlimit [expr {[clock clicks -milliseconds] + 50}]
 	set more [layoutmore $tlimit $allread]
 	if {$allread && !$more} {
-	    global displayorder nullid commitidx phase
+	    global displayorder commitidx phase
 	    global numcommits startmsecs
 
 	    if {[info exists pending_select]} {
-		set row [expr {[lindex $displayorder 0] eq $nullid}]
+		set row [first_real_row]
 		selectline $row 1
 	    }
 	    if {$commitidx($curview) > 0} {
@@ -437,6 +437,19 @@ proc readrefs {} {
     }
 }
 
+# skip over fake commits
+proc first_real_row {} {
+    global nullid nullid2 displayorder numcommits
+
+    for {set row 0} {$row < $numcommits} {incr row} {
+	set id [lindex $displayorder $row]
+	if {$id ne $nullid && $id ne $nullid2} {
+	    break
+	}
+    }
+    return $row
+}
+
 # update things for a head moved to a child of its previous location
 proc movehead {id name} {
     global headids idheads
@@ -1871,7 +1884,7 @@ proc showview {n} {
     } elseif {$selid ne {}} {
 	set pending_select $selid
     } else {
-	set row [expr {[lindex $displayorder 0] eq $nullid}]
+	set row [first_real_row]
 	if {$row < $numcommits} {
 	    selectline $row 0
 	} else {
@@ -2643,7 +2656,7 @@ proc layoutmore {tmax allread} {
 
 proc showstuff {canshow last} {
     global numcommits commitrow pending_select selectedline curview
-    global lookingforhead mainheadid displayorder nullid selectfi...
[ message continues ]

ACK.

This matches exactly what I was thinking of.

The red vs magenta looks a bit too close in color for me (red, green and 
blue?), but quite frankly, it's not like I really care.

Those author/date fields look really empty, but that's probably a good way 
to emphasize that they aren't real commits, so while it's visually a bit 
strange, it probably is the right thing to do.

		Linus
-

I should add that I'm sure that gitk won't yet do the right thing if
there are files in the index at other than stage 0, or if the local
changes are the result of an incomplete merge.  (In the latter case I
suppose one or other of the fake commits should have multiple parents,
but I don't have the infrastructure to add fake commits with multiple
parents yet.)

Paul.
-

That would be beautiful to see, indeed, when you're in the middle of a 
merge. "gitk --merge" already does most of it, but actually seeing the 
diff of the currently merged stuff would be pretty darn cool.

		Linus
-

Interesting, as I was thinking about something similar when I
typed "git show stash" by mistake. I meant to say "git stash
show", but "git show stash" output actually was even closer to
what I wanted to see.

"git stash" internally creates two commits, based on your HEAD:

         .----W
        /    / 
    ---H----I

Here, W keeps the state of the working tree, I is the index
state and H is the HEAD.  Commit I is direct child of H, Commit
W is an evil merge between H and I, and that is what is kept as
refs/stash, so "git show stash" would end up showing that merge
in --cc format.



-

Clarification.  I do not mean gitk should create such a view
using git-stash (for one thing that would nuke your local
modifications after saving it away).  I just meant that I agree
with you that --cc between HEAD, index and the working tree is a
wonderful way to view the current state.

It might make sense to teach "git diff" itself to show this
3-way diff with a new option ("git diff --h-i-w").  The
necessary machinery is already there to handle "git diff maint
master next pu" (four trees!), and "git diff maint:Makefile
master:Makefile next:Makefile" (three blobs).

-

Heh. I wasn't thinking of --cc, and if seen as a combination diff, I think 
--combined would be better (we very much want to see *all* changes, not 
just the conflicting ones, no?).

I was literally meaning two separate diffs, as two separate commits. But 
yes, I do agree that it might be very interesting to make "git diff-index" 

Actually, I think that if you teach "git diff-index" about --combined and 
--cc, then you'll automatically get it when you just do "git diff HEAD". 
No?

		Linus
-