Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Dec 1, 2006, 00:06 UTC
- Message-ID
- <eknrig$n27$1@sea.gmane.org>
- In-Reply-To
- <7vlklsfsgz.fsf@assigned-by-dhcp.cox.net>
Linus Torvalds wrote:
Show 16 quoted lines
> At least for me, it turns out that the only mode I _never_ use personally > is the "git commit -i" thing, which was actually the original behaviour, > and which you'd think that I would encourage for that reason. But no. Of > all the modes of "git commit", that's the one I think is the least > important, and least interesting. > > Of course, during a merge, you do need "-i" if you list files, but I think > "-a" subsumes almost all cases (you _can_ use "-i file-list" or totally > manually decide to have some extra edits you did that you don't want to > commit together with the merge, but that's such a special case that I > doubt anybody does it, so I don't think it's a big deal). > > Anyway, we have "-i", and we don't force anybody to use it, so the fact > that it's a bit odd and not that useful doesn't really matter. It > certainly "fits" in the git commit family as another case, it's just not > one of the important cases.
So, in short, -i is easier to explain, but is also least used. Perhaps also because one can simply update index with <files> before git commit instead of doing "git commit -i <files>".
-- Jakub Narebski Warsaw, Poland ShadeHawk on #git