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

Karl Hasselström wrote:

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

quoted

Karl Hasselström wrote:

quoted

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.

quoted

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.

quoted

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

The same workflow, with less hassle (and already implemented)

$ git format-patch -k HEAD~3
$ edit 0001-*
$ git am -k 000*

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.

Isn't this akin to what "git cherry-pick" does, except for the "convert 
to stgit patches" thing?

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231