Re: non-empty index with git commit -a
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 16, 2011, 18:51 UTC
- Message-ID
- <7vpqqrke30.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20110216100622.GA12971@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 11 quoted lines
> On Wed, Feb 16, 2011 at 09:58:52AM +0000, Sverre Rabbelier wrote: > >> On Wed, Feb 16, 2011 at 09:54, Jeff King <peff@peff.net> wrote: >> > So? Your question was whether index state is precious. If it's precious, >> > shouldn't we be keeping a history of it? >> >> I don't think it's quite _that_ precious, but the only operation that >> I regularly use that can blow away my carefully constructed index as >> side effect of doing something else is `git commit -a`. > > OK, so how precious is it? :)
The world is not that black-and-white, but is full of different shades of gray.
If you made mistakes with a second "git add", you can "reset --mixed" everything away and restart from scratch. The same thing can be said for a mistaken "git commit -a" that can be "reset HEAD^" (or --amend). So there is not much difference at the technical level.
I don't think this is primarily about "protecting the index". It is more about making the user feel better. Compared to a mistaken second "add", a mistaken "commit -a" feels like a lot heavier point-of-no-return.