git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Andreas Ericsson <ae@op5.se>
Date
Feb 15, 2006, 10:42 UTC
Message-ID
<43F305AF.70808@op5.se>
In-Reply-To
<20060215101136.GB26911@diana.vm.bytemark.co.uk>
Karl Hasselström wrote:
Show 55 quoted lines
> 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*

Show 25 quoted lines
> 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
Previous: Karl HasselströmNext: Karl Hasselström
Message 41 of 54 in “[ANNOUNCE] pg - A patch porcelain for GIT”
  1. Shawn PearceFeb 10, 2006
  2. Greg KHFeb 10, 2006
  3. Shawn PearceFeb 10, 2006
  4. Greg KHFeb 10, 2006
  5. Petr BaudisFeb 10, 2006
  6. Shawn PearceFeb 10, 2006
  7. Petr BaudisFeb 10, 2006
  8. Junio C HamanoFeb 10, 2006
  9. Petr BaudisFeb 13, 2006
  10. Catalin MarinasFeb 14, 2006
  11. Karl HasselströmFeb 14, 2006
  12. Chuck LeverFeb 14, 2006
  13. Karl HasselströmFeb 14, 2006
  14. Chuck LeverFeb 14, 2006
  15. Petr BaudisFeb 14, 2006
  16. Sam VilainFeb 15, 2006
  17. Shawn PearceFeb 15, 2006
  18. Petr BaudisFeb 15, 2006
  19. J. Bruce FieldsFeb 15, 2006
  20. Shawn PearceFeb 15, 2006
  21. J. Bruce FieldsFeb 15, 2006
  22. Junio C HamanoFeb 16, 2006
  23. Catalin MarinasFeb 16, 2006
  24. Fernando J. PeredaFeb 16, 2006
  25. Junio C HamanoFeb 16, 2006
  26. Catalin MarinasFeb 16, 2006
  27. Catalin MarinasFeb 15, 2006
  28. Karl HasselströmFeb 16, 2006
  29. 0/2 stg uncommitKarl Hasselström, Feb 17, 2006
  30. 1/2 Update .git/refs/heads/base after patch deletionKarl Hasselström, Feb 17, 2006
  31. 2/2 Add 'stg uncommit' commandKarl Hasselström, Feb 17, 2006
  32. Catalin MarinasFeb 19, 2006
  33. Karl HasselströmFeb 19, 2006
  34. Karl HasselströmFeb 19, 2006
  35. Sam VilainFeb 19, 2006
  36. Catalin MarinasFeb 20, 2006
  37. Karl HasselströmFeb 20, 2006
  38. Catalin MarinasFeb 20, 2006
  39. Karl HasselströmFeb 21, 2006
  40. Karl HasselströmFeb 15, 2006
  41. Andreas EricssonFeb 15, 2006
  42. Karl HasselströmFeb 15, 2006
  43. Karl HasselströmFeb 15, 2006
  44. Catalin MarinasFeb 17, 2006
  45. Sam VilainFeb 13, 2006
  46. Shawn PearceFeb 13, 2006
  47. Sam VilainFeb 13, 2006
  48. Shawn PearceFeb 13, 2006
  49. Catalin MarinasFeb 13, 2006
  50. Shawn PearceFeb 14, 2006
  51. Shawn PearceFeb 14, 2006
  52. Catalin MarinasFeb 15, 2006
  53. Catalin MarinasFeb 15, 2006
  54. Shawn PearceFeb 15, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.