Goswin von Brederlow <goswin-...@web.de> writes:
>> 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?
Absolutely.
Think of this sequence:
... edit edit edit to enhance the program a lot
... oops, noticed that there is a small typo in hello.c
... fix and do "git add hello.c" (at least I thought I did)
... edit edit edit to enhance the program a lot more.
... it is a good time to get rid of the trivial fix first.
$ git commit -m 'hello.c: typofix the message'
... oops, I mistyped the earlier one as "git ad hello.c" and
... didn't notice it.
which is just an example.
And the problem is a lot bigger at the _conceptual_ level.
We promise to the user that "git commit" without paths (nor -a which is
merely a short hand to specify all the paths that have changed) to commit
only what has been added to the index. If you earlier did "git add foo"
and "git add bar", changes made to these two files are the only changes
that are committed. If you did only "git add foo", then changes made to
this one file are the only changes that are committed. If you haven't
added anything yet, there is no change to be committed.
Special casing the last case (and only the last case) breaks consistency a
big way. It is one more pitfall that users need to worry about.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
