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

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

Karl Hasselström [off-list ref] wrote:

quoted

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.

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