Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes:
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> Think of this sequence:
>
> There's another case where it would be hard to decide what's "The
> Right Thing":
>
> vi existing-file.c # do some changes
> vi new-file.c # create the file
> git add new-file.c
> git commit
>
> If you take the SVN semantics, the last "git commit" should commit the
> changes to existing-file.c. But keeping the current Git semantics, it
> doesn't. There are valid reasons why a user can type the above
> sequence with today's Git, and changing it would be backward
> incompatible, and would make the senario a lot more painfull.
For SVN users it gets much worse:
vi existing-file.c # do some changes
vi new-file.c # create the file
git add new-file.c
vi new-file.c # do some more changes
git commit
A SVN user would expect the current working copies of existing-file.c
and new-file.c to be commited. Instead only new-file.c is commited and
only the fist modification.
While this case is still highly confusing to non git users I do see that
it can't be easily changed. And my suggestion doesn't change it. The
call to "git add" creates an index so the commit would only act on the
index.
MfG
Goswin
--
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