Re: [PATCH] git-add -p: be able to undo a given hunk
- From
Jeff King <peff@peff.net>
- Date
- Jul 27, 2009, 10:30 UTC
- Message-ID
- <20090727103031.GA3131@coredump.intra.peff.net>
- In-Reply-To
- <20090727082623.GB18268@laphroaig.corp>
On Mon, Jul 27, 2009 at 10:26:24AM +0200, Pierre Habouzit wrote:
Show 12 quoted lines
> > No, I don't really think so in terms of implementation, but it is > > really about a different mental model: > > > > 1. You never delete things. You only copy or move them into registers. > > > > 2. The interface should be the same whether you are moving between > > registers, or to/from the working tree. > > > > 3. It extends naturally to multiple registers. > > I like the general idea, I'm unsure what the UI for such tools would > look like though.
I was thinking of unifying the multiple interfaces that we use to move content and changes around into a single "git sort" and "git sort -i" (and yes, I just made those names up, so feel free to call them crappy), which would take a source and a destination (which would probably default to the working tree and index respectively).
So you could do the equivalent of:
- git add foo => git sort foo
- git add -p => git sort -i foo
- git checkout -- foo => git sort --from=index --to=tree foo
- git checkout HEAD -- foo => git sort --from=HEAD --to=tree foo
- git reset --mixed => git sort --from=HEAD --to=index
- git reset --mixed foo => git sort --from=HEAD --to=index foo
(note that this reset doesn't actually exist now, but is something
that people try to do)
- git stash save => git sort --to=%mystash
(and note that I just made up some "this is a register" syntax;
we maybe would really just want these as refs like refs/registers,
so you would specify registers/mystash)
- git stash -i => git sort --to=%mystash -i
(interactive stash doesn't exist yet, of course)
- git stash foo => git sort --to=%mystash foo
(partial stash doesn't exist yet)
- git diff HEAD stash -- foo | git apply => git sort --from=%mystash fooSo really, it could be a new way of interacting with the _regular_ index, as well, though perhaps it is overboard to completely redesign the git interface. :) I just think it introduces a consistency to the interface around the single concept of "moving your content around". So in a sense it would be a good candidate for an alternative porcelain. But do note that many common operations are more typing (like the checkout replacements); that would be something to fix.
Again, just thinking out loud. Feel free to ignore, but if you think there is anything interesting to pick out, let me know.
-Peff