From: Tor Arntsen Date: Fri, 23 Apr 2010 09:35:02 GMT Subject: Re: Please default to 'commit -a' when no changes were added Message-ID: In-Reply-To: <87r5m6tu0l.fsf@frosties.localdomain> On Fri, Apr 23, 2010 at 11:09, Goswin von Brederlow 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