git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Andreas Ericsson <ae@op5.se>
To: "Karl Hasselström" <kha@treskal.com>
Cc: git@vger.kernel.org
Subject: Re: [ANNOUNCE] pg - A patch porcelain for GIT
Date: Wed, 15 Feb 2006 11:42:55 +0100	[thread overview]
Message-ID: <43F305AF.70808@op5.se> (raw)
In-Reply-To: <20060215101136.GB26911@diana.vm.bytemark.co.uk>

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

  reply	other threads:[~2006-02-15 10:43 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-10 19:59 [ANNOUNCE] pg - A patch porcelain for GIT Shawn Pearce
2006-02-10 20:41 ` Greg KH
2006-02-10 21:04   ` Shawn Pearce
2006-02-10 23:20     ` Greg KH
2006-02-10 21:17 ` Petr Baudis
2006-02-10 21:38   ` Shawn Pearce
2006-02-10 21:47     ` Petr Baudis
2006-02-10 22:07       ` Junio C Hamano
2006-02-13 21:00   ` Petr Baudis
2006-02-14  9:26     ` Catalin Marinas
2006-02-14 10:08       ` Karl Hasselström
2006-02-14 15:22         ` Chuck Lever
2006-02-14 16:07           ` Karl Hasselström
2006-02-14 20:58             ` Chuck Lever
2006-02-14 22:29               ` Petr Baudis
2006-02-15  0:22                 ` Sam Vilain
2006-02-15  0:35                   ` Shawn Pearce
2006-02-15  1:14                     ` Petr Baudis
2006-02-15  4:11                     ` J. Bruce Fields
2006-02-15  6:54                       ` Shawn Pearce
2006-02-15 19:45                         ` J. Bruce Fields
2006-02-16 10:24                         ` Junio C Hamano
2006-02-16 10:33                           ` Catalin Marinas
2006-02-16 10:42                             ` Fernando J. Pereda
2006-02-16 10:52                               ` Junio C Hamano
2006-02-16 11:10                                 ` Catalin Marinas
2006-02-15 17:25                 ` Catalin Marinas
2006-02-16  7:54                   ` Karl Hasselström
2006-02-17  4:27                   ` [PATCH 0/2] stg uncommit Karl  Hasselström
2006-02-17  4:31                     ` [PATCH 1/2] Update .git/refs/heads/base after patch deletion Karl  Hasselström
2006-02-17  4:31                     ` [PATCH 2/2] Add 'stg uncommit' command Karl  Hasselström
2006-02-19 10:51                       ` Catalin Marinas
2006-02-19 13:45                         ` Karl Hasselström
2006-02-19 14:47                           ` Karl Hasselström
2006-02-19 21:15                             ` Sam Vilain
2006-02-20 17:20                             ` Catalin Marinas
2006-02-20 17:30                               ` Karl Hasselström
2006-02-20 22:49                                 ` Catalin Marinas
2006-02-21  7:55                                   ` Karl Hasselström
2006-02-15 10:11               ` [ANNOUNCE] pg - A patch porcelain for GIT Karl Hasselström
2006-02-15 10:42                 ` Andreas Ericsson [this message]
2006-02-15 11:25                   ` Karl Hasselström
2006-02-15 11:27                     ` Karl Hasselström
2006-02-17 21:57     ` Catalin Marinas
2006-02-13  2:49 ` Sam Vilain
2006-02-13  3:29   ` Shawn Pearce
2006-02-13  4:40     ` Sam Vilain
2006-02-13  6:03       ` Shawn Pearce
2006-02-13 14:40 ` Catalin Marinas
2006-02-14  4:56   ` Shawn Pearce
2006-02-14  6:14     ` Shawn Pearce
2006-02-15 17:20       ` Catalin Marinas
2006-02-15 17:12     ` Catalin Marinas
2006-02-15 17:55       ` Shawn Pearce

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43F305AF.70808@op5.se \
    --to=ae@op5.se \
    --cc=git@vger.kernel.org \
    --cc=kha@treskal.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).