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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html