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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 22 Apr 2010, Goswin von Brederlow wrote:

> Nicolas Pitre <nico@xxxxxxxxxxx> writes:
> 
> > On Thu, 22 Apr 2010, Goswin von Brederlow wrote:
> >
> >> I do commit often and commit early and I start and finish one thing
> >> before I start another. Also I keep my files small so they do one thing
> >> and do it well. Overall that means I don't end up with multiple changes
> >> in a single file so I never need to cherry pick changes for a commit.
> >
> > Good for you.  I'm not that disciplined. Hence I often end up working on 
> > more than one thing in parallel.  The index is just so incredibly useful 
> > in that case.  I'm also a big fan of 'git add -e'.
> 
> As soon as you do 'git add -e' then you have an index. In that case a
> 'git commit' would use the index. There would be no change in worflow or
> behaviour for you.

But the point is if I did not use 'git add'.

> >> So I don't think people should be forced to utilize the index. Imho that
> >> is a matter of the workflow people use. Some people work better with the
> >> index and some people (or projects) don't need it.
> >
> > 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
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]