On Fri, Apr 23, 2010 at 11:09, Goswin von Brederlow <goswin-...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
