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 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 - 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.htmlReceived on Wed Feb 15 21:13:49 2006
This archive was generated by hypermail 2.1.8 : 2006-02-15 21:14:02 EST