Re: Please default to 'commit -a' when no changes were added

[Tor Arntsen <tor@spacetec.no>]

On Fri, Apr 23, 2010 at 11:09, Goswin von Brederlow <goswin-v-b@web.de> wrote:

> 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.

I come from CVS, i.e. a similar background.

> 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.

I wouldn't agree it's highly confusing. As soon as you understand why
(and it shouldn't take long), it's a relief. With CVS I would
constantly make copies of my working tree so that I could sort out all
the different things I was working on at the same time (which is a
necessity when you work with development and bugfixing and customer
reports with different priorities are dropping in). It's much easier
now (with Git) to do a couple of different things at the same time.

Besides, I would argue that the SVN/CVS behaviour is creating problems
also for SVN/CVS users. Where I work it's not unusual that developers
accidentally commit different changes in the same commit, making it
hard to extract the one you want when you later wish to e.g. push a
specific change to a maintenance branch or hotfix tree.

And git add --patch is also wonderful sometimes. (Unfortunately that
won't work on systems with pre-5.8 versions of Perl, which I just
found out - but that's another story.)

I plan to create a short course for my fellow co-workers when we move
more stuff over from CVS to Git. Just an hour should do I think. I'll
clarify how the index works very early on and I believe they'll all
"get it" very quickly. I'll probably also take some parts from 'Git
from the bottom up' by John Wiegley, at least I found (after having
used Git for some time) that knowing how it works from blobs and up
actually helps a lot.

I won't join in on the discussion of any actual changes to Git, for
that I'm too fresh as Git user. I would only like to stress that I
wouldn't want the current flexibility to get limited or changed to be
more like SVN/CVS -- I come from there, remember, and I don't see why
I would wish to go back.

-Tor