On Sun, 3 Dec 2006, Alan Chandler wrote: > > > > git ls-tree HEAD -- that-file | git update-index --index-info > > git commit that-file > > I don't quite understand this - maybe it should be > > git ls-tree HEAD -- that-file | git update-index --index-info > git commit > git commit -a Sure. It depends on which file you want to commit first. If you want to commit "that-file" first, you do my sequence. If you want to commit everything _but_ "that-file", you do the second sequence (which basically removes the changes to "that-file" from the index, then commits the index, and then with "git commit -a" commits the remaining dirty state, which is obviously those changes to "that-file" that you still had in the working tree). > either I want to ONLY commit that file at the working tree state (and index > before these commands), or I want to commit ALL except this file (so I can > later come and commit just that file) Right. If you do git ls-tree HEAD -- that-file | git update-index --index-info git commit that-file you basically ONLY commit "that-file". You first reset it (in the index) to the old state, but that's just so that "git commit that-file" will now happily commit the current state (in the working tree) of "that-file". So "git commit that-file" will basically _ignore_ your current index. Because you told "git commit" (by naming "that-file") that you _only_ wanted to commit "that-file". So whatever state you had in your current index doesn't matter at all - it will only look at the HEAD tree _and_ that single file that you specified. Linus - 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