Thread (29 messages) flat view 29 messages, 9 authors, 2016-06-15

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

From: Karl Hasselström <hidden>
Date: 2016-06-15 22:42:19

Possibly related (same subject, not in this thread)

On 2006-02-14 15:58:02 -0500, Chuck Lever wrote:
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.
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help