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

From: Tor Arntsen <tor@spacetec.no>
Date: Apr 23, 2010, 09:35 UTC
Message-ID: <p2qd2d39d861004230235tacb970bftc96f2c1473843b1c@mail.gmail.com>
In-Reply-To: <87r5m6tu0l.fsf@frosties.localdomain>

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

Show 11 quoted lines

> 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