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

Karl Hasselström wrote:
> On 2006-02-14 15:58:02 -0500, Chuck Lever wrote:
> 
> 
>>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
> 

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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html