[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:       Thomas Rast <trast () student ! ethz ! ch>
Date:       2009-07-27 10:06:10
Message-ID: 200907271206.11431.trast () student ! ethz ! ch
[Download RAW message or body]

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

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.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
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]