Jonathan Nieder writes:
> Starting out, I can see how it would be comforting to people if
> ‘git commit’ would default to -a behavior if they ignore the index.
> That is logically a different operation, though, so it would also send
> a wrong message and make it harder in the long run to get used to the
> interface.
I agree that making 'git commit' do 'git commit -a' if there are no
staged changes would be a bad change.
> Instead, I think it would be better to focus on making the error
> message more helpful. Right now there is a screen full of status
> before the advice, which might make it easy to get scared before
> reading it.
>
> Here’s a very rough patch to suppress that screenful. What do you
> think?
It's a pity that people didn't concentrate on this part: improving
error message...
On a bit unrelated note what I'd like to have is 'git commit -a'
(optional) safety against accidentally getting rid of staged changes.
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'
Perhaps this behavior would be turned on only if some config option,
like commit.preserveIndex or something like that is set to true...
--
Jakub Narebski
Poland
ShadeHawk on #git
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
