[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [PATCH] git-add -p: be able to undo a given hunk
From:       Jeff King <peff () peff ! net>
Date:       2009-07-27 10:36:09
Message-ID: 20090727103609.GB3131 () coredump ! intra ! peff ! net
[Download RAW message or body]

On Mon, Jul 27, 2009 at 12:06:10PM +0200, Thomas Rast wrote:

> >   5. Commit 'b' on top of new HEAD (and this would probably actually
> >      mean the changes from 'b' to the old HEAD, not setting the new HEAD
> >      state to what's in 'b').
> > 
> > So it's sort of a generalized form of the index, where you have N "index
> > registers" and you sort your changes into them. And during steps 2 and
> > 3, you could also make more changes, pick them out, etc.
> 
> I think the parenthetical remark actually contradicts the notion that
> it's an index.  It's more like a place to hold a patch.  Which then
> makes it rather similar to a temporary branch and cherry-pick, or
> interactive rebase, or whatever.

Sort of. It's not an index in the sense that you might make a tree and
commit directly from it. But I think of it as an index in that it holds
a particular state, and you can diff that state against other things. I
would probably implement it as an index via GIT_INDEX_FILE (though I
guess performance would not be as nice as if it shared the cache parts
of the main index).

Implicit in my thinking was that you could actually get rid of the
concept of "the index" and simply replace it with such a register (which
maybe would be the "default register" or something). So whether you
committed directly from it, or whether you applied its diff would be
decided not at creation time, but at the time you wanted to commit. And
that would depend on what operations you were doing (simply making a
commit, sorting changes for multiple commits, etc).

> Granted, the register idea does not directly map to interactive rebase
> because that cannot (automatically) add changes to an older commit.
> So I frequently wind up making a series of commits along the lines of
> 
>   WIP implement foo
>   WIP implement bar
>   WIP fix foo some
>   WIP docs for bar
>   WIP docs for foo
>   WIP tests for foo
> 
> and then have to sort and squash them with rebase -i.

Yes, I do that a lot. And maybe this whole thing is a stupid idea; git
already has lots of tools for working with _commits_, so maybe registers
should really just be commits. So in that sense what I am asking for is
just a multi-headed stash, and tools for doing interactive, incremental
stashing to those heads.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]