From: Karl Hasselström Date: Mon, 07 May 2007 06:35:05 GMT Subject: Re: [FAQ?] Rationale for git's way to manage the index Message-ID: <20070507063505.GA31269@diana.vm.bytemark.co.uk> In-Reply-To: On 2007-05-06 23:53:13 +0100, Julian Phillips wrote: > On Sun, 6 May 2007, Matthieu Moy wrote: > > > The reason why I'm posting this is that I was wondering whether > > "commit -a" not being the default was supposed to be a message > > like "you shouln't use it too often". > > Well, personally I practically never use it, I find that having a > separation between what the current state of my tree is and what > will be comitted to be one of the really "oh wow, why doens't > everything else do this?" features. However, i tend to be working on > more than one thing at once, and switch between them - so I commit > work on A while work on B is still unfinished, then start C, finish > B some point later and commit it, and then I can finish C. Git is > the first VCS that supports a butterfly mind :P. git-gui is really handy for adding/committing a subset of the changes in your working tree. Especially for those of us with goldfish memory, since it's so easy to see exactly what's happening: what's going to be committed and what not. > "git add -i" - this is a feature I have wanted since I started using > version control ... I thought "git add -i" was the best thing since sliced bread -- until I found the same feature in git-gui, but with a _much_ better interface. Just right-click on a hunk in a diff, and you have the option of staging/unstaging that hunk. Pure magic. -- Karl Hasselström, kha@treskal.com www.treskal.com/kalle