Re: [ANNOUNCE] pg - A patch porcelain for GIT

From: Karl Hasselström <kha@treskal.com>
Date: Feb 15, 2006, 10:11 UTC
Message-ID: <20060215101136.GB26911@diana.vm.bytemark.co.uk>
In-Reply-To: <43F2445A.6020109@citi.umich.edu>

On 2006-02-14 15:58:02 -0500, Chuck Lever wrote:

Show 8 quoted lines

> Karl Hasselström wrote:
>
> > No, I literally want the opposite of "stg commit", so that the
> > sequence "stg commit; stg uncommit" has zero net effect.
>
> well, that would work OK for maintainers, but would be kind of
> strange for folks who are pulling from such a repository. how would
> that work?

I didn't plan to publish branches where this kind of history munging was being done. It's precisely like "git rebase" in that regard -- it's a tool for cleaning up history before it is published.

> my impression of git is that you don't change stuff that's already
> committed. you revert changes by applying a new commit that backs
> out the original changes.

You don't change stuff that's already committed _and published_ (well, except for pu branches :-). Rewriting history is perfectly OK up until the moment someone has pulled your branch.

> i'm speculating, but i suspect that's why there's a "stg pick
> --reverse" and not a "stg uncommit."

I don't think I've been very successful in communicating exactly what I want "stg uncommit" for. It's not that I want to undo a committed change -- what I want is to transform it into an stgit patch so that I can edit it with a minimum of effort.

  $ edit edit edit
  $ git-commit -a -m "create foo"
  $ edit edit edit
  $ git-commit -a -m "improve foo"
  $ edit edit edit
  $ git-commit -a -m "improve bar"

  # Oops, I realize that the "create foo" changeset had a debug
  # printout left in it, and I wasn't already using stgit.

  $ stg init
  $ stg uncommit improve-bar improve-foo create-foo
  $ stg stg pop --to=create-foo
  $ edit --remove=debug-printout
  $ stg refresh
  $ stg push --all

Similar use-cases for e.g. reordering commits, merging commits, deleting one commit in the middle of a chain of good ones, etc. are easy to come up with. The point is that stgit alreay handles all this, _but only if you have been using stgit from the start_. What "stg uncommit" does is basically to import (linear) git history into stgit, where a powerful toolset exists to edit it.

You can actually do this today; just create a new branch where you want your new stgit stack to be based, and "stg pick" the commits/patches from the old branch:

  $ git-checkout -b new-branch HEAD^^^
  $ stg init
  $ stg pick old-branch^^^ -n create-foo
  $ stg pick old-branch^^ -n improve-foo
  $ stg pick old-branch^ -n improve-bar
  $ git-branch -D old-branch
  $ git-checkout -b old-branch
  $ git-branch -d new-branch

This series of commands also converts the top three commits to stgit patches, and leaves the user on the same branch where she started (it does _exactly_ the same job as "stg uncommit improve-bar improve-foo create-foo"), but it's a lot of work, and a typo could lose commits.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle