On Sat, 24 April 2010, Miles Bader wrote: > Jakub Narebski <jnareb@xxxxxxxxx> 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 -- 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