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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: May 10, 2007, 02:39 UTC
Message-ID: <alpine.LFD.0.98.0705091934440.4062@woody.linux-foundation.org>
In-Reply-To: <4642831C.2090401@midwinter.com>

On Wed, 9 May 2007, Steven Grimm wrote:

Show 11 quoted lines

> Junio C Hamano wrote:
> > I obviously agree with this.  As I said a few times I regret
> > introducing "add -i" --- it encourages a wrong workflow, in that
> > what you commit in steps never match what you had in the working
> > tree and could have tested until the very end.
> >   
> 
> On the other hand, not all changes require any testing at all. For example, if
> you're using git to manage documentation, it is totally reasonable to commit a
> fix for a simple spelling error in one part of a file while not committing an
> in-progress rewrite of another part.

Yeah, I don't think "git add -i" is a horrible flow - it just shouldn't be the only or the primary one (ie apparently it *is* the primary one for darcs, and that's a mistake!)

Of course, whether "git add -i" is a nice interface or not, I dunno. Personally, if I wanted to do hunk selection, I think I'd stick to something graphical where I can just click on the hunks. But that's just me.

		Linus