Re: [FAQ?] Rationale for git's way to manage the index

On 2007-05-06 23:53:13 +0100, Julian Phillips wrote:

On Sun, 6 May 2007, Matthieu Moy wrote:

quoted

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