Re: Merging commits together into a super-commit

From: J. Bruce Fields <bfields@fieldses.org>
Date: May 10, 2007, 19:22 UTC
Message-ID: <20070510192212.GP13719@fieldses.org>
In-Reply-To: <87vef0350y.wl%cworth@cworth.org>

On Thu, May 10, 2007 at 11:30:37AM -0700, Carl Worth wrote:

> So, compared to the rebase usage, this does add two commands for
> bookkeeping the original state and cleaning it up. But the syntax for
> the cherry-pick part is quite a bit simpler than the original rebase
> at least.

Yeah, something like that would be great. I think I've seen others suggest similar syntax before, so it's probably just a question of one of us who want this finding time to write the patches.

Show 5 quoted lines

> Also, "reset --hard" isn't actually what I want in this case. I'd like
> this recipe to use something that would move the current branch to
> some other point, but in a safe way, (that is, not destroy any
> uncommitted changes that might exist at the beginning). I don't have
> any proposal for what that would be.

The tag creation and cleanup could get to be annoying too. You could scrounge through the reflog instead of using a temporary tag, but depending on the amount of --amend'ing and cherry-picking you do the reflog entry may end up in a different place each time, so it's probably hard to make this automatic.

Show 7 quoted lines

> stg - This probably works great if you're using it as a primary
>       interface. But trying to use it as a quick one-off when
>       generally using core git does not work well at all. Instead of
>       the two "git tag" commands in my recipe above, an stg recipe
>       would involve a lot of additional bookkeeping with stg init, stg
>       uncommit [N times for fixing a commit N steps back in the
>       history], stg goto, stg push, etc.

I also didn't like having to come up with another name for each patch--I'd rather just run git-log or gitk and cut-n-paste the sha1.

For kernel work I started out working with multiple (sym- or hard-linked) trees, then used akpm's patch scripts, then stgit. I think I'm happiest just using plain git.

The one thing I've never been good at is keeping the history of the patch series itself.

--b.