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

From: Karl Hasselström <kha@treskal.com>
Date: May 7, 2007, 06:35 UTC
Message-ID: <20070507063505.GA31269@diana.vm.bytemark.co.uk>
In-Reply-To: <Pine.LNX.4.64.0705062344230.29485@reaper.quantumfyre.co.uk>

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

Show 14 quoted lines

> 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