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

From: Karl Hasselström <kha@treskal.com>
Date: May 8, 2007, 07:37 UTC
Message-ID: <20070508073739.GA24409@diana.vm.bytemark.co.uk>
In-Reply-To: <20070508014114.GC11311@spearce.org>

On 2007-05-07 21:41:14 -0400, Shawn O. Pearce wrote:

Show 10 quoted lines

> Karl Hasselström <kha@treskal.com> wrote:
>
> > 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.
>
> "git add -i" has a hunk splitting feature that git-gui lacks. I'm
> thinking of adding features to git-gui to let you select a region of
> a hunk using the text selection, and then stage only that selection.

That would be useful. It's currently possible to split some hunks by reducing the number of content lines, but if the changes aren't separated by any unchanged lines at all, that doesn't work.

> I also want to let you revert hunks from the working directory copy.

That would be handy. But unlike stage/unstage, this can lose information, so there'd need to be some kind of "are you _really_ sure? [Yes] [No]" safety hatch, which would make it less convenient.

Show 5 quoted lines

> But after reading Junio's comments about "git add -i" being a
> possibly bad idea and instead letting you park everything into a
> shelf, reset --hard your working directory to HEAD and then pull
> things back off the shelf to be staged, I might want to do that
> differently in git-gui... like use a shelf. ;-)

A shelf could be handy. Actually, it could be handy to have more than one. Then one could go through the mess in one's working directory and toss changes into one bin for each commit one plans to create -- including one "trash" bin for hunks one would like to revert.

I assume that shelves would be implemented as branches that are precisely one commit on top of HEAD? If so, I'd just like to point out that they're exactly like unapplied patches in StGIT.

Hmm. I find it inconsistent to force or strongly encourage the user to commit precisely the working directory changes and not a subset thereof, which the shelf idea seems to encourage, while at the same time not committing straight from the working directory but from a specific staging area (the index).

> But I'm glad someone else finds the hunk feature useful in git-gui.
> I use it far too often myself.

I don't think it's a bad thing. If I've made several unrelated changes and want to commit them separately for the sake of readable history, how exactly is that a bad thing when compared to committing it all at once? If I care about clean history in the first place, then presumably I'll test the commits in isolation if I deem it necessary -- and if I don't, then I probably won't test anyway even if the tool makes it easy.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle