On Mon, May 9, 2011 at 7:44 AM, Jeff King <peff@xxxxxxxx> wrote: > > That still leaves an inconsistency in "git add -p" versus "git commit > -p" (e.g., if you abort "git add -p" with "^C"). But if we care, the > right solution is probably to make "git add -p" atomic. That can be a > separate topic, though, and I'm not sure anyone really cares enough to > work on it. I have pondered this problem too. "git add -p" is a particularly unintuitive, it inherits the update-the-index-after-every-complete-file semantics of "git add --interactive", but without ever making the file boundaries clear to the user. Depending on how much this bugs me, I might try to fix it in the future, but I wonder whether any users of "git add --interactive" are relying on the file based granularity. > > I have one final question. If I do abort a commit, is there any way to > recover the state that was in the temporary index? That is, if I abort > "git commit -i" by using an empty commit message, it is easy enough to > use shell history to repeat the command (possibly with a different set > of files). But if I spend some time selecting (and possibly editing) > hunks, and then decide to abort the commit, is there any way to recover > the intermediate index state? Not really. You could use your knowledge of git-commit to assume that the tree object with the most recent ctime is probably useful, but that only works some of the time. The occasions on which I have wanted to abort the process half-way, I've just created a temporary commit with what I have so far. A "git reset --soft" at that point makes the whole process long-hand for "git add -p". > >> Allow git commit --interactive with paths > > Hmm. Test t7501.8 explicitly tests that this isn't allowed. But the test > is poorly written, and falsely returns success even with your patch. > Well spotted. Thank you Junio for fixing that test. > which does properly fail with your change. Your commit should tweak that > test (speaking of which, it would be nice for patch 1 to have a test, > too). I'll try to get my head around the tests :). Conrad -- 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