Re: Please default to 'commit -a' when no changes were added

> On Thu, 22 Apr 2010, Goswin von Brederlow wrote:
>
>> Nicolas Pitre <nico@fluxnic.net> writes:
>> 
>> > On Thu, 22 Apr 2010, Goswin von Brederlow wrote:
>> > Exact.  It is therefore not progress to impose some inconvenience to one 
>> > work flow in order to make another one easier.  And in this case we're 
>> > talking about the difference between having to type an additional -a vs 
>> > the risk of creating a commit with unexpected content.
>> 
>> Is there a risk? You do get an editor with all the files affected listed
>> giving you a big fat warning what you are about to commit. Yes I
>> sometimes do start to commit wrongly too (no matter what RCS used) but
>> then I just close the editor to abort and commit the things seperately.
>
> Yes, but this is a much greater burden to 1) not forget to empty the 
> editor, and 2) actually save the empty file.  Simply exiting the editor 
> will cause unwanted commit.
>
> Compare that with simply adding -a to your commit command when told so.

>> >> Alternatively an option to take all changes but only if the index is
>> >> empty would be helpfull. Then people could define an alias for that or
>> >> set the option in the config. Other than setting -a that would allow
>> >> using an index when needed and commit everything in the normal case
>> >> without having to change the command used to commit.
>> >
>> > But you're proposing to change the semantics for that command.  And I 
>> > also suspect that you're trying to make the index more hidden while what 
>> > we're actually trying to do is to promote it.
>> 
>> Yes, it would hide the index. But you are not just promoting it. You are
>> forcing people to always use it, even if only through the -a option.
>
> Well, sure.
>
> And you might be glad that the -a option is there at all.  When this was 
> debated, the concensus was that the index is what makes Git so 
> different, and actually *better* than the alternatives.
>
> Concerns were raised about natural human resistance to change and the 
> fact that some people would have problem adapting to a different model.  
> So the -a argument was added as a compromize, although the concensus was 
> much less strong in that case.
>
> And experience so far has shown that the vast majority of new Git users 
> started to really appreciate the index once they've past the initial 
> hurdle of getting used to a different concept.
>
> So we can say that Git's index is one of its major feature.  You should 
> learn to use it or stick to -a, but please don't try to make Git into 
> what it was meant to be different from.
>
>> > What _you_ can do though, is this:
>> >
>> > 	git config --global alias.ci "commit -a"
>> 
>> But then when I accidentally use 'git ci' while having an index the
>> index gets ignored and all changed files get commited in one big mess.
>
> Not at all.  You will end up in the same text editor with the same 
> opportunity to abort the messed up commit as you are claiming above.  
> Except now this is your own burden instead of mine.  See?  One's gain is 
> another one's loss.
>
> However in this case this would happen because you mixed up an 
> index-using workflow with a non-index-using workflow.  While with your 
> suggested change the messed up commit could occur without mixing up 
> workflows.

> So either you use the index or you don't.  And of course I'd strongly 
> suggest you truly consider using it.
>
>> Given how seldom I need an index (so far never) the risk of using 'git
>> ci' accidentally is way to high. Same with typing -a. I do it so often
>> that when I actualy don't want it I will probably type it anyway out of
>> habbit.
>
> This is a strawman.  If you do not use the index and never used it so 
> far, why are you so afraid of this ci alias?  Please get over it.
>
>
> Nicolas