Re: 'commit -a' safety

[Jakub Narebski <jnareb@gmail.com>]

On Sat, 24 April 2010, Miles Bader wrote:
> Jakub Narebski <jnareb@gmail.com> writes:

> > I'd like for 'git commit -a' to *fail* if there are staged changes for
> > tracked files, excluding added, removed and renamed files.  If you
> > have some staged changes you would get an error message:
> >
> >   $ git add tracked-file
> >   $ git commit -a
> >   fatal: There are staged changes to tracked files
> >   hint: To commit staged changes, use 'git commit'
> >   hint: To commit all changes, use 'git commit -f -a' 
> 
> That's bad because of the dual nature of "git add" -- someone may
> normally use "-a" most of the time to commit changes, but has really no
> choice other than git add to add a new file, So with this change, their
> normal (and reasonable) habits would suddenly result in failure.
> 
> I think it's sort of annoying that "git add" has such a dual meaning
> (instead of, for instance, having separate "add" and "stage" commands)
> -- it's one of the more confusing things about learning about git
> -- but oh well, it's unlikely to get changed at this point....

First, this is to be optional safety, by default turned off.  So if you
do not have problems with situation where you accidentally use 
'git commit -a' instead of 'git commit', committing not what you wanted
and prepared, you simply do not turn it on.


Second, to be more exact the safety would be triggered only if staged
change _differs_ from what is in working area.  Therefore

  $ git add file
  $ git commit -a

would not trigger this safety, while

  $ git add file
  $ edit file
  $ git commit -a
  fatal: There are staged changes

would trigger it.


Third, there is "git add -N" to mark file as tracked, but not add its
current context.

  $ git add -N file
  $ edit file
  $ git commit -a

should not trigger this safety.

-- 
Jakub Narebski
Poland