Hello, I am wondering if someone could explain and/or point me to an explanation of how the git index works. For instance, suppose I have a tracked file: "foo.c" 1) [I modify "foo.c"] 2) git add foo.c 3) [modify again] 4) git commit -m "blah blah" Since I don't include the "-a" switch, the version I added on step 2 is committed. But how does the index keep track of these changes? Does the index file actually contain the hunks of "foo.c" that have been modified? Or is there a "temporary" blob created, which the index points to? In either case, is there some interface to access these hunks and/or get a reference to the blob? Thanks, -- Shaun PS I'm considering writing an extension to git where the "diff" understands the semantics of certain types of files: hunks wouldn't just be textual blobs but would try to represent a minimal change from one version to the next based on an edit distance, so that, e.g. changing the location of a function would be represented by a "move" edit, rather than two text changes. I have been building a prototype as a wrapper around git, intervening to store extra information, etc before passing commands on to git. Blobs, commits, etc are nice abstractions I can leave as is, but the index seems sort of foggy to me. Any advice appreciated! -- 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