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

From: Shawn O. Pearce <spearce@spearce.org>
Date: May 8, 2007, 14:52 UTC
Message-ID: <20070508145249.GP11311@spearce.org>
In-Reply-To: <20070508073739.GA24409@diana.vm.bytemark.co.uk>

Karl Hasselstr??m <kha@treskal.com> wrote:

> 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.

Yea, I've played that game before too (reduce content lines) to try and simulate a hunk splitter. ;-) Doesn't always work.

Right now I feel like a huge chunk of the git-gui code is simply not maintainable. The 0.7.0 release is really more about refactoring the code to make it more maintainable, than it is about actual features (though there are some new things, like vi-keys).

The hunk selection stuff is just one part of the 2,000 lines still left in git-gui.sh itself, and that still uses a lot of messy globals. I want to get the code better organized before I take on major new additions to it.

Show 5 quoted lines

> > 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.

True, but that beats the tar out of copying the - lines to your clipboard and pasting them into your text editor, then deleting the - prefix. Especially if its a couple of hunks that you want to revert. Which I find myself doing all to often.

Actually I work around it today by staging what I care about, then reverting the file. Since the revert comes out of the index, I get (mostly) the same action as reverting a particular hunk. But it does mean that I lose my index state, if that happened to be of any particular interest.

> 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.

I haven't looked at StGIT in a while.  I've seen noise on the list
about nifty features being added, but I haven't kept up with what
those features actually are.  I think you are right about this and
maybe git-gui should try to be compatible with StGIT's unapplied
patches, should I get into actually implementing a shelving system.

Show 5 quoted lines

> 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).

Indeed; I was thinking that this very morning. Making an index that you stage things into, but then also saying you cannot really do that and instead have to shelve what you don't want - that's just evil. I'll have to think about it more.

The blame interface in git-gui needs help more than the index
staging features.  The colors suck.  ;-)

-- 
Shawn.