{"thread":{"id":"3286","subject":"[ANNOUNCE] pg - A patch porcelain for GIT","startedAt":"2006-02-10T19:59:14Z","lastAt":"2006-02-21T07:55:39Z","messageCount":54,"participants":["Shawn Pearce","Petr Baudis","Junio C Hamano","Greg KH","Sam Vilain","Catalin Marinas","Karl Hasselström","Chuck Lever","J. Bruce Fields","Andreas Ericsson","Fernando J. Pereda"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"15856","messageId":"20060210195914.GA1350@spearce.org","threadId":"3286","inReplyTo":null,"subject":"[ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-02-10T19:59:14Z","receivedAt":"2006-02-10T19:59:14Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"I just posted the first public version of pg, a GIT porcelain for\nmanaging patches. Think StGIT, but better in some ways:\n\nFeature Summary:\n\n- Maximum compatibility with other GIT porcelains.\n\n pg was designed to interoperate with core GIT and the other\n GIT porcelains as much as possible. GIT favorites like git-am\n can be used to modify a pg managed patch, and vice-versa,\n and without requiring changes to the other GIT tools.\n\n- Simplified command line user interface.\n\n pg tries to simplify GIT by 'hiding' the index and behaving like\n more traditional SCMs which only look at `HEAD` (last commit)\n and the working directory (files).\n\n- Preserves change history of patches.\n\n The complete change history associated with each patch is\n maintained directly within GIT. By storing the evolution of a\n patch as a sequence of GIT commits standard GIT history tools\n such as gitk can be used.\n\n- Its prune proof.\n\n The metadata structure is stored entirely within the refs\n directory and the object database, which means you can safely use\n git-prune without damaging your work, even for unapplied patches.\n\n- Preserves patch series during clone.\n\n The metadata structure used by pg allows git-clone to preserve\n the patch series information, without changes required to\n git-clone. (Patch series information is not preserved during\n git-pull/git-push however.)\n\n- Mix and matching of changes (bug fixes/features).\n\n By maintaining changes as individual patches it is possible to\n apply individual changes to the current working directory and\n to unapply them just as easily.\n\n- Automatic detection (and cancellation) of returning patches.\n\n pg automatically detects when a patch is received from\n the upstream GIT repository during a pg-rebase and deletes\n (cancels) the local version of the patch from the patch series.\n The automatic cancelling makes it easy to use pg to track and\n develop changes on top of a GIT project.\n\n- Fast\n\n pg operations generally perform faster than StGIT operations,\n at least on my large (~7000 file) repositories.\n\n\nAnd for those so inclined:\n\n Homepage: http://www.spearce.org/projects/scm/pg/\n GIT Repository: http://www.spearce.org/projects/scm/pg.git\n\n\n-- \nShawn.\n"},{"id":"15878","messageId":"20060210204143.GA18784@kroah.com","threadId":"3286","inReplyTo":"20060210195914.GA1350@spearce.org","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Greg KH","fromEmail":"greg@kroah.com","sentAt":"2006-02-10T20:41:43Z","receivedAt":"2006-02-10T20:41:43Z","isPatch":false,"sender":{"key":"greg@kroah.com","avatar":"https://gravatar.com/avatar/5bb5aa0cc2e01c00ec899d11130c07796bc186e465bae57bc34873b13b72c7c8?d=mp&s=160"},"body":"On Fri, Feb 10, 2006 at 02:59:14PM -0500, Shawn Pearce wrote:\n> I just posted the first public version of pg, a GIT porcelain for\n> managing patches. Think StGIT, but better in some ways:\n> \n> Feature Summary:\n\nHm, is there any way to import an existing patch into pg?\n\nthanks,\n\ngreg k-h\n"},{"id":"15860","messageId":"20060210210401.GA1604@spearce.org","threadId":"3286","inReplyTo":"20060210204143.GA18784@kroah.com","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-02-10T21:04:01Z","receivedAt":"2006-02-10T21:04:01Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Greg KH wrote:\n> On Fri, Feb 10, 2006 at 02:59:14PM -0500, Shawn Pearce wrote:\n> > I just posted the first public version of pg, a GIT porcelain for\n> > managing patches. Think StGIT, but better in some ways:\n> > \n> > Feature Summary:\n> \n> Hm, is there any way to import an existing patch into pg?\n\nDoh! I haven't needed to do that yet. I'll code up a pg-import\nlater tonight. But since git and pg play nice together you can\ndo this:\n\n\tpg-new Patch-Name\n\tgit-apply the-patch-file.patch\n\tpg-ci -m\"Importing the-patch-file.patch...\"\n\nor even:\n\n\tpg-new Patch-Name\n\tgit-am mbox\n\nand keep the 'history' stored in the mailbox.\n\nSo pg-import won't amount to a very long script. :-|\n"},{"id":"15863","messageId":"20060210211740.GO31278@pasky.or.cz","threadId":"3286","inReplyTo":"20060210195914.GA1350@spearce.org","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-02-10T21:17:40Z","receivedAt":"2006-02-10T21:17:40Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\nDear diary, on Fri, Feb 10, 2006 at 08:59:14PM CET, I got a letter\nwhere Shawn Pearce said that...\n> I just posted the first public version of pg, a GIT porcelain for\n> managing patches. Think StGIT, but better in some ways:\n\n it sounds interesting. I've been thinking about wrapping some patch\nqueue tool in Cogito (post-1.0) and pg might be a better choice than\nStGIT.\n\n One thing I dislike on both StGIT and pg is that they both try to\nbuild a full-fledged porcelain on top of GIT, instead of just focusing\non the patch management, doing it well and providing a convenient user\ninterface (well, can't say about pg's interface, didn't try it yet).\nInstead of having pg-add, pg-log, or pg-status it might be more fruitful\nto contribute the features you are missing to git-core or Cogito.\n\n> And for those so inclined:\n> \n> Homepage: http://www.spearce.org/projects/scm/pg/\n> GIT Repository: http://www.spearce.org/projects/scm/pg.git\n\nBut while it claims to be compatible with all the porcelains, it at\nleast cannot be clone by them. ;) The GIT repository is not quite a\nvalid GIT repository since it is missing the HEAD and Cogito clones\nbased on this file instead of just assuming that your head is on the\nmaster branch.\n\n\nAlso, when cloning it gives me a little unnerving errors like\n\nerror: File 6427c0154400f578d9cdff178e01e946db6f714f\n(http://www.spearce.org/projects/scm/pg.git/objects/64/27c0154400f578d9cdff178e01e946db6f714f)\ncorrupt\n\n(but strangely, fsck-objects later does not complain).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nOf the 3 great composers Mozart tells us what it's like to be human,\nBeethoven tells us what it's like to be Beethoven and Bach tells us\nwhat it's like to be the universe. -- Douglas Adams\n"},{"id":"15877","messageId":"20060210213818.GB1604@spearce.org","threadId":"3286","inReplyTo":"20060210211740.GO31278@pasky.or.cz","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-02-10T21:38:18Z","receivedAt":"2006-02-10T21:38:18Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Petr Baudis wrote:\n> One thing I dislike on both StGIT and pg is that they both try to\n> build a full-fledged porcelain on top of GIT, instead of just focusing\n> on the patch management, doing it well and providing a convenient user\n> interface (well, can't say about pg's interface, didn't try it yet).\n> Instead of having pg-add, pg-log, or pg-status it might be more fruitful\n> to contribute the features you are missing to git-core or Cogito.\n\nVery valid points. Before writing pg I used Cogito exclusively\nand found git-core too cumbersome to use directly. When I started\nwriting pg I didn't intend on replacing everything GIT and Cogito\noffers; I was trying to only create the patch stack but still use\nthe Cogito tools for everything else.\n\nBut two things happened:\n\n 1) Cogito didn't run well on a Solaris box I wanted to try and\n use it in; apparently we don't have enough GNU shell commands\n available and Cogito fell over. (But right now I'd bet pg\n will behave the same if not worse. I haven't had time to try\n it. *sigh*)\n\n 2) I found myself suddenly typing 'pg-log' and 'pg-diff' rather\n than 'git-log' and 'git-diff'. Call it future muscle memory?\n I hadn't written either of these scripts so I was getting a lot\n of '-bash: pg-log: command not found' errors from my shell.\n So they both became 1 line wrappers around the git-core\n versions, just to save my sanity.\n\nI would agree with trying to integrate some of the workflow idealogy\npresented by StGIT and pg into something more mainstream such as\ngit-core or Cogito. Right now I'm using pg as a proving ground to\nfeel out how some of that might work in one particular environment:\n\n A development team I work with is stuck using PVCS Version\n Manager 6. Moving source code from a developer to a tester is a\n huge nightmare; not only must the developer check the code into\n the version control system but he/she must also write a bug report\n in a bug database to tell someone else to get the source file\n and give it to the tester. Its a horrible workflow. GIT + pg +\n additional custom scripts seems to be easing the pain somewhat;\n but sadly we can't just rip out PVCS Version Manager and use GIT.\n\n\n> > And for those so inclined:\n> > \n> > Homepage: http://www.spearce.org/projects/scm/pg/\n> > GIT Repository: http://www.spearce.org/projects/scm/pg.git\n> \n> But while it claims to be compatible with all the porcelains, it at\n> least cannot be clone by them. ;) The GIT repository is not quite a\n> valid GIT repository since it is missing the HEAD and Cogito clones\n> based on this file instead of just assuming that your head is on the\n> master branch.\n\nFixed. That's my fault - my hosting provider doesn't have GIT\ninstalled and thus I had to publish my repository over rsync+ssh.\nBut git-push doesn't support that protocol type anymore. :-| So\nI packed everything into pack files, pruned the object directory,\nand rsync'd it up. I guess my rsync script didn't copy HEAD.\n\n> Also, when cloning it gives me a little unnerving errors like\n> \n> error: File 6427c0154400f578d9cdff178e01e946db6f714f\n> (http://www.spearce.org/projects/scm/pg.git/objects/64/27c0154400f578d9cdff178e01e946db6f714f)\n> corrupt\n\nI've seen the same. I think it is either a bug in my rsync script\nor a bug in the GIT http clone code; because that is the current\ntip commit of the master branch. And I've only seen that error for\nthe tip commit, and only if the object doesn't exist in the object\ndirectory because I've done git-pack && git-prune-packed.\n\n-- \nShawn.\n"},{"id":"15866","messageId":"20060210214723.GP31278@pasky.or.cz","threadId":"3286","inReplyTo":"20060210213818.GB1604@spearce.org","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-02-10T21:47:23Z","receivedAt":"2006-02-10T21:47:23Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Feb 10, 2006 at 10:38:18PM CET, I got a letter\nwhere Shawn Pearce said that...\n> But two things happened:\n> \n> 1) Cogito didn't run well on a Solaris box I wanted to try and\n> use it in; apparently we don't have enough GNU shell commands\n> available and Cogito fell over. (But right now I'd bet pg\n> will behave the same if not worse. I haven't had time to try\n> it. *sigh*)\n\nI'm always listening for bugreports. Besides requiring bash, Cogito _is_\nexpected to run on POSIX stuff!\n\n> 2) I found myself suddenly typing 'pg-log' and 'pg-diff' rather\n> than 'git-log' and 'git-diff'. Call it future muscle memory?\n> I hadn't written either of these scripts so I was getting a lot\n> of '-bash: pg-log: command not found' errors from my shell.\n> So they both became 1 line wrappers around the git-core\n> versions, just to save my sanity.\n\nI see. IIRC Catalin gave the similar reasoning. (Obviously, my\negoistical me might be just hurt by it not wrapping Cogito. ;))\n\n> > But while it claims to be compatible with all the porcelains, it at\n> > least cannot be clone by them. ;) The GIT repository is not quite a\n> > valid GIT repository since it is missing the HEAD and Cogito clones\n> > based on this file instead of just assuming that your head is on the\n> > master branch.\n> \n> Fixed.\n\nThanks.\n\n> > Also, when cloning it gives me a little unnerving errors like\n> > \n> > error: File 6427c0154400f578d9cdff178e01e946db6f714f\n> > (http://www.spearce.org/projects/scm/pg.git/objects/64/27c0154400f578d9cdff178e01e946db6f714f)\n> > corrupt\n> \n> I've seen the same. I think it is either a bug in my rsync script\n> or a bug in the GIT http clone code; because that is the current\n> tip commit of the master branch. And I've only seen that error for\n> the tip commit, and only if the object doesn't exist in the object\n> directory because I've done git-pack && git-prune-packed.\n\nOn a second thought, this is probably simply caused by the web server\nnot reporting 404 on missing files.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nOf the 3 great composers Mozart tells us what it's like to be human,\nBeethoven tells us what it's like to be Beethoven and Bach tells us\nwhat it's like to be the universe. -- Douglas Adams\n"},{"id":"15868","messageId":"7vd5huvpfd.fsf@assigned-by-dhcp.cox.net","threadId":"3286","inReplyTo":"20060210214723.GP31278@pasky.or.cz","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-10T22:07:02Z","receivedAt":"2006-02-10T22:07:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> On a second thought, this is probably simply caused by the web server\n> not reporting 404 on missing files.\n\nI suspect that is it. The webserver is broken^W not being a\ngood network citizen.\n"},{"id":"15873","messageId":"20060210232039.GC21468@kroah.com","threadId":"3286","inReplyTo":"20060210210401.GA1604@spearce.org","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Greg KH","fromEmail":"greg@kroah.com","sentAt":"2006-02-10T23:20:39Z","receivedAt":"2006-02-10T23:20:39Z","isPatch":false,"sender":{"key":"greg@kroah.com","avatar":"https://gravatar.com/avatar/5bb5aa0cc2e01c00ec899d11130c07796bc186e465bae57bc34873b13b72c7c8?d=mp&s=160"},"body":"On Fri, Feb 10, 2006 at 04:04:01PM -0500, Shawn Pearce wrote:\n> Greg KH wrote:\n> > On Fri, Feb 10, 2006 at 02:59:14PM -0500, Shawn Pearce wrote:\n> > > I just posted the first public version of pg, a GIT porcelain for\n> > > managing patches. Think StGIT, but better in some ways:\n> > > \n> > > Feature Summary:\n> > \n> > Hm, is there any way to import an existing patch into pg?\n> \n> Doh! I haven't needed to do that yet. I'll code up a pg-import\n> later tonight. But since git and pg play nice together you can\n> do this:\n> \n> \tpg-new Patch-Name\n> \tgit-apply the-patch-file.patch\n> \tpg-ci -m\"Importing the-patch-file.patch...\"\n> \n> or even:\n> \n> \tpg-new Patch-Name\n> \tgit-am mbox\n\nwell, as my quilt tree is around 200 patches right now, that would be\nannoying to have to do by hand :)\n\nthanks,\n\ngreg k-h\n"},{"id":"16013","messageId":"43EFF3D0.4090701@vilain.net","threadId":"3286","inReplyTo":"20060210195914.GA1350@spearce.org","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-02-13T02:49:52Z","receivedAt":"2006-02-13T02:49:52Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Shawn Pearce wrote:\n> I just posted the first public version of pg, a GIT porcelain for\n> managing patches. Think StGIT, but better in some ways:\n> \n> Feature Summary:\n> - Maximum compatibility with other GIT porcelains.\n> - Simplified command line user interface.\n\nHow do I edit the description of an existing patch using pg? Perhaps an\noption to pg-push ?\n\nSam.\n"},{"id":"16014","messageId":"20060213032903.GA32121@spearce.org","threadId":"3286","inReplyTo":"43EFF3D0.4090701@vilain.net","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-02-13T03:29:03Z","receivedAt":"2006-02-13T03:29:03Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sam Vilain wrote:\n> Shawn Pearce wrote:\n> >I just posted the first public version of pg, a GIT porcelain for\n> >managing patches. Think StGIT, but better in some ways:\n> >\n> >Feature Summary:\n> >- Maximum compatibility with other GIT porcelains.\n> >- Simplified command line user interface.\n> \n> How do I edit the description of an existing patch using pg? Perhaps an\n> option to pg-push ?\n\nThere isn't any description associated with a patch beyond its name\n(which can be changed with pg-rename). Unlike StGIT pg currently\ndoesn't store a description with each patch.\n\nThis is partly because I want pg to extract the comments given to\npg-ci to make the description of the patch during an export with\npg-export - but I haven't written the code to walk back along the\nrelated commits and extract each comment. On the other hand this\nmight not be the best description for a patch. :-)\n\n-- \nShawn.\n"},{"id":"16018","messageId":"43F00DB6.4040306@vilain.net","threadId":"3286","inReplyTo":"20060213032903.GA32121@spearce.org","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-02-13T04:40:22Z","receivedAt":"2006-02-13T04:40:22Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Shawn Pearce wrote:\n>>>I just posted the first public version of pg, a GIT porcelain for\n>>>managing patches. Think StGIT, but better in some ways:\n>>>Feature Summary:\n>>>- Maximum compatibility with other GIT porcelains.\n>>>- Simplified command line user interface.\n>>How do I edit the description of an existing patch using pg? Perhaps an\n>>option to pg-push ?\n> There isn't any description associated with a patch beyond its name\n> (which can be changed with pg-rename). Unlike StGIT pg currently\n> doesn't store a description with each patch.\n> This is partly because I want pg to extract the comments given to\n> pg-ci to make the description of the patch during an export with\n> pg-export - but I haven't written the code to walk back along the\n> related commits and extract each comment. On the other hand this\n> might not be the best description for a patch. :-)\n\nok. Well, perhaps a nice solution might be just to aggregate the\ncomments as each new commit is made. ie, the previous comment is\nprepended to the new comment unless you use the editor or a special\n-M (or whatever) option that replaces the running comment.\n\nI tried importing a patchset into pg, and made some changes to it to see\nthe patch revisioning going on. However, I can't see this happening.\nCan you perhaps include this information in your tutorial?\n\nAs far as other, more general critiques of the software goes: What\nabout merging? stgit has a very nice way of merging; I specify how to\nmerge using a config file, and when I rebase my patches with \"stg pull\",\nit fires up my custom editor. All I really want is a way to specify how\nto handle merges, with the ancestor/left/right files on hand. I want to\nuse something as simple as this script:\n\n#!/bin/sh\n\nbranch1=\"$1\"\nbranch2=\"$2\"\nancestor=\"$3\"\noutput=\"$4\"\n\necho \"Merging:\"\necho\necho \" $branch1\"\necho \" - $ancestor\"\necho\necho \" with:\"\necho\necho \" $branch2\"\necho \" - $ancestor\"\necho\necho \" to: $output\"\necho \"\"\necho -n \"Trying diff3...\"\n\nif diff3 -L local -L older -L remote -m -E \"$branch1\" \"$ancestor\" \\\n \"$branch2\" > \"$output\"\nthen\n echo \"OK\"\nelse\n echo \"failed\"\n echo \"falling back to ediff-merge\"\n emacs --eval \"(ediff-merge-files-with-ancestor \\\"${branch1}\\\"\n \\\"${branch2}\\\" \\\"${ancestor}\\\" nil \\\"${output}\\\")\"\nfi\n\nThose commands I got from the default .stgitrc config.\n\nThat's all the features I'm really after.\n\nSam.\n"},{"id":"16024","messageId":"20060213060321.GA32704@spearce.org","threadId":"3286","inReplyTo":"43F00DB6.4040306@vilain.net","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-02-13T06:03:21Z","receivedAt":"2006-02-13T06:03:21Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sam Vilain wrote:\n> ok. Well, perhaps a nice solution might be just to aggregate the\n> comments as each new commit is made. ie, the previous comment is\n> prepended to the new comment unless you use the editor or a special\n> -M (or whatever) option that replaces the running comment.\n\nYea, that's not a bad idea. If you are creating a new commit you\nprobably would want to edit the running description for the patch;\nor at least be reminded of what it is.\n \n> I tried importing a patchset into pg, and made some changes to it to see\n> the patch revisioning going on. However, I can't see this happening.\n> Can you perhaps include this information in your tutorial?\n\nRevisioning doesn't happen for the series, just the individual\npatches. But I've thought about series revisoning and keeping a\nsecondary GIT index/commit chain external to the main repository\nfor exactly this purpose.\n\nEach change to a patch (pg-ci) is a new commit object in GIT with\nthe prior commit object as its parent; if you use pg-ci a few times\nwith the same patch on the stack then look at the log with git-log\nor gitk you'll see the commits are chained together.\n\nWhen you pop patches and reorder them in the series the resulting\nmerges are stored as commits with two parents: one for the HEAD\nat the time of the merge and one for the commit which was the last\ncommit in the patch being pushed (HEAD^1 and HEAD^2 respectively).\nFor example:\n\n\tpg-new A\n\techo a >>somefile\n\tpg-ci -m\"This is a\"\n\tpg-new B\n\techo b >>somefile\n\tpg-ci -m\"This is b\"\n\n\tpg-pop -a\n\tpg-push B # base used to be HEAD+A, now its HEAD\n\tpg-push A # base used to be HEAD, now its HEAD+B\n\nThe challenge then becomes walking through the merge history.\nIf you look at pg's own history you'll see an interesting knot\nin gitk at a7e73545e511c5c2daea1f6c7bf06cf3179e7f0da (Refreshed\npatch Create-Rebase-Tool). This was produced because I reorded\nthe patches in the stack and thus had to merge them. It was an\nautomatic merge, but it still generated merge commit objects.\n\nGood suggestion about including some details about it in the\ntutorial.\n\n> As far as other, more general critiques of the software goes: What\n> about merging? stgit has a very nice way of merging; I specify how to\n> merge using a config file, and when I rebase my patches with \"stg pull\",\n> it fires up my custom editor. All I really want is a way to specify how\n> to handle merges, with the ancestor/left/right files on hand. I want to\n> use something as simple as this script:\n> \n> echo \"falling back to ediff-merge\"\n> emacs --eval \"(ediff-merge-files-with-ancestor \\\"${branch1}\\\"\n> \\\"${branch2}\\\" \\\"${ancestor}\\\" nil \\\"${output}\\\")\"\n\npg doesn't currently invoke any user code when an automatic merge\nfails during pg-push or pg-rebase. It does attempt to produce\na 3 way merge and leaves the resulting portions for you in the\nfilesystem. If you look at MERGING.txt you'll see that up to 5\nfiles can come out of a merge (here I'm using the tracked file X.c):\n\n\tX.c\n\tX.c-head\n\tX.c-last\n\tX.c-pbase\n\tX.c-rej\n\nThese just get left in the filesystem for you to use as you want;\nin your case it sounds like you'd want to invoke:\n\n\temacs --eval \"(ediff-merge-files-with-ancestor\n\t\t\\\"X.c-head\\\"\n\t\t\\\"X.c-last\\\"\n\t\t\\\"X.c-pbase\\\"\n\t\tnil\n\t\t\\\"X.c\\\"\n\t\t)\"\n\nX.c already contains the result of performing:\n\n\tdiff X.c-pbase X.c-last | patch X.c\n\nso it already has any hunks which were part of your patch and\nwhich applied cleanly to X.c-head (which is the file coming in as\nthe new base). Thus you are left only with the rejecting hunks,\nwhich are in X.c-rej.\n\nPersonally I've always preferred being given the rejects from\npatch to work out a merge problem then to be given the mess that\nRCS merge leaves you with. (I've _never_ been able to decipher\nwhat I want from an RCS merge conflict.)\n\nWhat is the desired behavior when multiple files have conflicts?\nStop and let the user work on one file before moving to the next?\nOpen all merge editors in parallel? Neither seems right to me in\nall situations, which is why I just left the `mess' in the filesystem\nfor the user to resolve at their own pace.\n\n> That's all the features I'm really after.\n\nI like what you are suggesting and will try to incorporate these\nimprovements this week.\n\n-- \nShawn.\n"},{"id":"16046","messageId":"tnxy80fe2zo.fsf@arm.com","threadId":"3286","inReplyTo":"20060210195914.GA1350@spearce.org","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@arm.com","sentAt":"2006-02-13T14:40:27Z","receivedAt":"2006-02-13T14:40:27Z","isPatch":false,"sender":{"key":"catalin.marinas@arm.com","avatar":null},"body":"Shawn Pearce wrote:\n> I just posted the first public version of pg, a GIT porcelain for\n> managing patches. Think StGIT, but better in some ways:\n\nCouldn't help replying to such a topic :-) (only that the \":\" ending\nof the above phrase might make people think that some features you\nlisted are not available in StGIT).\n\nWithout much testing, I think pg is a good tool but it is different\nfrom StGIT in many ways. It mainly resembles the topic branches way of\nworking with the advantage of having them stacked on each-other. Each\npatch seems to be equivalent to a topic branch where you can commit\nchanges. Rebasing a patch is equivalent to a merge in a branch with\nthe merge commit having a general description like \"Refreshed patch\n...\" and two parents - the new base and the old top.\n\nWhile I don't say the above is a bad thing, it is pretty different\nfrom StGIT. With StGIT, the history of the tree only shows one commit\nper patch with the patch description chosen by the user. If you edit\nthe description or modify the patch, the old patch or description is\ndropped from the main branch (visible via HEAD) and you only get the\nlatest one. This clean history has many advantages when sending\npatches upstream either via e-mail or by asking for a pull.\n\n> - Simplified command line user interface.\n>\n> pg tries to simplify GIT by 'hiding' the index and behaving like\n> more traditional SCMs which only look at `HEAD` (last commit)\n> and the working directory (files).\n\nThis is the case with StGIT as well. It doesn't usually require the\nuse of GIT commands directly.\n\n> - Preserves change history of patches.\n>\n> The complete change history associated with each patch is\n> maintained directly within GIT. By storing the evolution of a\n> patch as a sequence of GIT commits standard GIT history tools\n> such as gitk can be used.\n\nThere have been discussions to adding this to StGIT as well (and there\nis a patch already from Chuck). It is a good thing to have but I'm\nopposed to the idea of having the history accessible from the top of\nthe patch. Since the patch can be refreshed indefinitely, it would\nmake the main history (visible from HEAD) really ugly and also cause\nproblems with people pulling from a tree. I prefer to have a separate\ncommand (like 'stg id patch/log') that gives access to the history.\n\n> - Its prune proof.\n>\n> The metadata structure is stored entirely within the refs\n> directory and the object database, which means you can safely use\n> git-prune without damaging your work, even for unapplied\n> patches.\n\nThat's missing indeed in StGIT but it will be available in the next\nrelease. I didn't push this yet because I wasn't sure what to do with\nthe refresh history of a patch.\n\n> - Automatic detection (and cancellation) of returning patches.\n>\n> pg automatically detects when a patch is received from\n> the upstream GIT repository during a pg-rebase and deletes\n> (cancels) the local version of the patch from the patch series.\n> The automatic cancelling makes it easy to use pg to track and\n> develop changes on top of a GIT project.\n\nStGIT has been doing this from the beginning. You would need to run a\n'stg clean' after a rebase (or push). I prefer to run this command\nmanually so that 'stg series -e' would show the empty patches and let\nme decided what to do with them.\n\n> - Fast\n>\n> pg operations generally perform faster than StGIT operations,\n> at least on my large (~7000 file) repositories.\n\nMight be possible but I haven't done any tests. There are some\noptimisations in StGIT that make it pretty fast: (1) if the base of\nthe patch has not changed, it can fast-forward the pushed patches\nwhich is O(1) and (2) StGIT first tries to use git-apply when pushing\na patch and use a three-way merge only if this fails (the operation\nusually succeeds for most of the patches). There are some speed\nproblems with three-way merging if there are many file\nremovals/additions because the external merge tool is called for each\nof them but the same problem exists for any other tool.\n\n-- \nCatalin\n"},{"id":"16057","messageId":"20060213210001.GA31278@pasky.or.cz","threadId":"3286","inReplyTo":"20060210211740.GO31278@pasky.or.cz","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-02-13T21:00:01Z","receivedAt":"2006-02-13T21:00:01Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\nDear diary, on Fri, Feb 10, 2006 at 10:17:40PM CET, I got a letter\nwhere Petr Baudis said that...\n> > I just posted the first public version of pg, a GIT porcelain for\n> > managing patches. Think StGIT, but better in some ways:\n> \n> it sounds interesting. I've been thinking about wrapping some patch\n> queue tool in Cogito (post-1.0) and pg might be a better choice than\n> StGIT.\n\n so I've used it a bit and I'm going back to StGIT, at least for now.\nIt is not really usable for me so far, since it is missing two crucial\nthings:\n\n\t* Patch description tracking. Patch description is almost as\n\timportant as patch contents for me, and pg just doesn't track it\n\tfor now. It would be best if it just seeded the patch\n\tdescription by the first commit message and then allow you edit\n\tit at the refresh time.\n\n\t* Mail interface. StGIT can pre-fill the patch description with\n\tmy signoff line, but more importantly when I write\n\n\t\tstg mail patchname\n\n\tit will mail the patch to the addresses I configured it to,\n\tprepend [PATCH] to the subject line and stuff.\n\n So, my patchqueue workflow is \"I do some random third-party patches\nfor some software and want to manage, update, and submit them easily.\"\nPG does not make it much easier now, unfortunately.\n\n Some common gripes for both StGIT and pg (well, I'm using some\nridiculously old StGIT version, so this may not apply anymore there):\n\n\t* stg new --force - seriously, what's the point?! I always to\n\tthe change first and when it's any good, I want to create a\n\tpatch for it.\n\n\t* I can't just get the patch in its \"canonical ready-to-mail\n\tform\" on stdout so that I could easily review it. Why is\n\tpg-export insisting to dump it to a file?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nOf the 3 great composers Mozart tells us what it's like to be human,\nBeethoven tells us what it's like to be Beethoven and Bach tells us\nwhat it's like to be the universe. -- Douglas Adams\n"},{"id":"16085","messageId":"20060214045618.GA12844@spearce.org","threadId":"3286","inReplyTo":"tnxy80fe2zo.fsf@arm.com","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-02-14T04:56:18Z","receivedAt":"2006-02-14T04:56:18Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Catalin Marinas wrote:\n> Without much testing, I think pg is a good tool but it is different\n> from StGIT in many ways. It mainly resembles the topic branches way of\n> working with the advantage of having them stacked on each-other. Each\n> patch seems to be equivalent to a topic branch where you can commit\n> changes. Rebasing a patch is equivalent to a merge in a branch with\n> the merge commit having a general description like \"Refreshed patch\n> ...\" and two parents - the new base and the old top.\n\nYes, exactly.\n \n> While I don't say the above is a bad thing, it is pretty different\n> from StGIT. With StGIT, the history of the tree only shows one commit\n> per patch with the patch description chosen by the user. If you edit\n> the description or modify the patch, the old patch or description is\n> dropped from the main branch (visible via HEAD) and you only get the\n> latest one. This clean history has many advantages when sending\n> patches upstream either via e-mail or by asking for a pull.\n\nYes. I didn't intend on exporting the entire patch history for\ndelivery upstream; I only intended on exporting the batch between\nits base and last markers, which amounts to giving a single diff\nsuch as what StGIT would generate. But I had planned on pulling\nthe commit comments from all history into the header of the patch\nduring export, I just haven't gotten there yet.\n \n> > - Preserves change history of patches.\n> >\n> > The complete change history associated with each patch is\n> > maintained directly within GIT. By storing the evolution of a\n> > patch as a sequence of GIT commits standard GIT history tools\n> > such as gitk can be used.\n> \n> There have been discussions to adding this to StGIT as well (and there\n> is a patch already from Chuck). It is a good thing to have but I'm\n> opposed to the idea of having the history accessible from the top of\n> the patch. Since the patch can be refreshed indefinitely, it would\n> make the main history (visible from HEAD) really ugly and also cause\n> problems with people pulling from a tree. I prefer to have a separate\n> command (like 'stg id patch/log') that gives access to the history.\n\nI definately agree. I have been rather unhappy with the log\nstructure that pg is giving me when I flip patches around on the\nstack. So I'm certainly considering keeping the history of the\npatch in a parallel tree stored within the same object and refs\ndatabase but I haven't really figured out how this could work.\n \n> > - Its prune proof.\n> >\n> > The metadata structure is stored entirely within the refs\n> > directory and the object database, which means you can safely use\n> > git-prune without damaging your work, even for unapplied\n> > patches.\n> \n> That's missing indeed in StGIT but it will be available in the next\n> release. I didn't push this yet because I wasn't sure what to do with\n> the refresh history of a patch.\n\nI see you actually already pushed out a change for this for StGIT.\nThat's good news. :-) I noticed the solution StGIT used is close to\npg's, except that StGIT has the simplified single-commit-per-patch\nmodel so its less refs than pg.\n\n> > - Automatic detection (and cancellation) of returning patches.\n> >\n> > pg automatically detects when a patch is received from\n> > the upstream GIT repository during a pg-rebase and deletes\n> > (cancels) the local version of the patch from the patch series.\n> > The automatic cancelling makes it easy to use pg to track and\n> > develop changes on top of a GIT project.\n> \n> StGIT has been doing this from the beginning. You would need to run a\n> 'stg clean' after a rebase (or push). I prefer to run this command\n> manually so that 'stg series -e' would show the empty patches and let\n> me decided what to do with them.\n\nActually StGIT didn't do this correctly for one of my use cases\nand that's one of the things that drove me to trying to write pg\n(because I wondered if there was a way to resolve it automatically).\nTry building a patch series such as:\n\n\t... start with an empty stack ...\n\n\t... create patch A ...\n\t... edit file hello.c ...\n\t... refresh patch A ...\n\n\t... create patch B ...\n\t... edit file hello.c (same line region as patch A) ...\n\t... refresh patch B ...\n\n\t... generate patch A+B (as one patch!) ...\n\t... send A+B upstream ...\n\n\t... pull upstream down ...\n\nStGIT seemed to not handle this when it tried to reapply the two\nalready applied patches. A won't apply because the file coming\ndown is actually A+B, not A's predecessor and not A. B won't apply\nbecause the file also isn't A (B's predecessor).\n\npg resolves this by attempting to automatically fold patches during\na pg-rebase (equiv. of stg pull). If a patch fails to push cleanly\nand there's another patch immediately behind it which also should\nbe reapplied pg aborts and retries pushing the combination of the\npatches. This fixes my A+B case quite nicely during a rebase. :-)\n\nOf course it doesn't deal with the upstream giving me A+B+C and I\nhave only A+B locally in my patches. But I can't have everything\nnow can I. :-)\n \n> > - Fast\n> >\n> > pg operations generally perform faster than StGIT operations,\n> > at least on my large (~7000 file) repositories.\n> \n> Might be possible but I haven't done any tests. There are some\n> optimisations in StGIT that make it pretty fast: (1) if the base of\n> the patch has not changed, it can fast-forward the pushed patches\n> which is O(1) and (2) StGIT first tries to use git-apply when pushing\n> a patch and use a three-way merge only if this fails (the operation\n> usually succeeds for most of the patches). There are some speed\n> problems with three-way merging if there are many file\n> removals/additions because the external merge tool is called for each\n> of them but the same problem exists for any other tool.\n\npg uses the same optimization for pushing and popping patches. It\nalso has a special case for the trivially empty patch which StGIT\ndoesn't seem to have (as StGIT must have a commit for every patch,\npg doesn't require a commit in an empty patch).\n\nHowever one thing I'm playing around with is using git-read-tree -u\n-m to rebase a patch rather than git-diff-tree piped to git-apply\n(at least when its not a trivial forward or rewind). I found that\nmost of the time to push a patch was spent in git-diff-tree and\nhardly anytime was in git-apply. Using git-read-tree to merge in the\nchange works nicely in the common case of different patches changing\ndifferent files with it falling back to the external merge strategy\nwhen there's unmerged stages in the index. The open question is\nwhat percentage is this one way or the other?\n\nSo I think StGIT is causing a bit more CPU and disk IO than pg is,\nbut some of these `optimizations' were only put into pg today (and\npushed to my website around 5 pm EST). I'm actually considering\nbenchmarking StGIT and pg against the same set of changes to see\nhow pg compares to StGIT - because I'm now rather curious if pg is\nbetter or worse.\n\n\nAnother difference is the fast-forward when the base of the patch\nisn't changed. In pg this is just:\n\n\tgit-update-ref HEAD $last $head &&\n\tgit-read-tree -u -m $head $last\n\nwhich should be slightly faster than StGIT as pg is skipping the\nupdate-index step:\n\n\tgit-update-index -q --unmerged --refresh\n\tgit-read-tree -u -m head patch\n\tgit-update-ref HEAD patch head\n\nbecause like StGIT I check for a clean tree before starting the\npush; a tree is only clean if the index doesn't need to be refreshed\n(plus all the other normal considerations like no unmerged files).\nThis drops a working directory scan before the read-tree. :-)\n\n-- \nShawn.\n"},{"id":"16093","messageId":"20060214061406.GA13238@spearce.org","threadId":"3286","inReplyTo":"20060214045618.GA12844@spearce.org","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-02-14T06:14:06Z","receivedAt":"2006-02-14T06:14:06Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Shawn Pearce wrote:\n> > > pg operations generally perform faster than StGIT operations,\n> > > at least on my large (~7000 file) repositories.\n> > \n> > Might be possible but I haven't done any tests. There are some\n> > optimisations in StGIT that make it pretty fast: (1) if the base of\n> > the patch has not changed, it can fast-forward the pushed patches\n> > which is O(1) and (2) StGIT first tries to use git-apply when pushing\n> > a patch and use a three-way merge only if this fails (the operation\n> > usually succeeds for most of the patches). There are some speed\n> > problems with three-way merging if there are many file\n> > removals/additions because the external merge tool is called for each\n> > of them but the same problem exists for any other tool.\n\nI did a quick benchmark of the latest StGIT and pg versions available\nby cloning a linux repository twice (pg and stg) and constructing\nan identical patch in in each which modified the same set of files\n(3 files in 3 different subdirectories).\n\nPopping and pushing this patch of 3 files is a fast forward/rewind\ncase to both implementations, but pg was faster for me:\n\nstg pop; stg push (fast-forward)\n pop real 0m13.824s user 0m1.904s sys 0m3.934s\n pop real 0m13.670s user 0m1.882s sys 0m3.973s\n pop real 0m21.070s user 0m2.005s sys 0m4.069s\n pop real 0m15.346s user 0m1.757s sys 0m3.846s\n pop real 0m16.960s user 0m1.888s sys 0m3.866s\n \n push real 0m20.650s user 0m2.027s sys 0m4.015s\n push real 0m15.624s user 0m1.958s sys 0m3.966s\n push real 0m13.277s user 0m1.746s sys 0m3.796s\n push real 0m12.739s user 0m1.764s sys 0m3.822s\n push real 0m15.161s user 0m1.973s sys 0m3.939s\n \npg-pop; pg-push (fast-forward)\n pop real 0m10.009s user 0m1.919s sys 0m2.265s\n pop real 0m 4.710s user 0m1.692s sys 0m1.560s\n pop real 0m 4.333s user 0m1.664s sys 0m1.554s\n pop real 0m 5.480s user 0m1.848s sys 0m1.638s\n pop real 0m 4.412s user 0m1.680s sys 0m1.604s\n \n push real 0m5.813s user 0m1.750s sys 0m1.733s\n push real 0m4.345s user 0m1.686s sys 0m1.632s\n push real 0m5.326s user 0m1.721s sys 0m1.658s\n push real 0m4.740s user 0m1.691s sys 0m1.647s\n push real 0m4.487s user 0m1.702s sys 0m1.637s\n\n\nI tried to do the merge case which requires reconstructing the\npatch onto a new base revision. This was easy to test over and over\nagain on pg (pg-rebase; pg-rebase --undo) but I don't know how I can\nsafely undo the stg pull so I can repeat it on the stg repository.\nInstead I tested git-diff-tree|git-apply as that's what StGIT uses\ninternally. StGIT does a check for a clean tree before starting\nits merge so I cheated here and used the pg version of that check\nas part of the diff/apply cost to try and make it slightly more\nfair to pg-rebase.\n\ngit-diff-tree -p %s %s | git-apply --index\n diff/apply real 0m6.246s user 0m1.377s sys 0m1.634s\n diff/apply real 0m5.293s user 0m1.342s sys 0m1.591s\n diff/apply real 0m5.929s user 0m1.445s sys 0m1.614s\n diff/apply real 0m5.258s user 0m1.333s sys 0m1.567s\n diff/apply real 0m5.255s user 0m1.339s sys 0m1.581s\n\npg-rebase; pg-rebase --undo (merge)\n rebase real 0m9.505s user 0m4.028s sys 0m3.366s\n rebase real 0m9.415s user 0m4.020s sys 0m3.334s\n rebase real 0m9.387s user 0m4.028s sys 0m3.364s\n rebase real 0m9.159s user 0m4.024s sys 0m3.353s\n rebase real 0m9.008s user 0m4.025s sys 0m3.326s\n\n undo real 0m6.531s user 0m1.852s sys 0m2.403s\n undo real 0m6.383s user 0m1.815s sys 0m2.405s\n undo real 0m6.510s user 0m1.849s sys 0m2.406s\n undo real 0m6.519s user 0m1.846s sys 0m2.408s\n undo real 0m6.496s user 0m1.878s sys 0m2.413s\n\nI guess you could say I didn't entirely expect this result.\nThe diff-tree/apply approach is faster for a single commit then\nread-tree -u -m is; even if totally different files are being\nimpacted and thus all stages collapse neatly to stage 0 in the index.\nNo wonder StGIT uses diff/apply!\n\n-- \nShawn.\n"},{"id":"16107","messageId":"tnxoe1aqoj2.fsf@arm.com","threadId":"3286","inReplyTo":"20060213210001.GA31278@pasky.or.cz","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@arm.com","sentAt":"2006-02-14T09:26:41Z","receivedAt":"2006-02-14T09:26:41Z","isPatch":false,"sender":{"key":"catalin.marinas@arm.com","avatar":null},"body":"Petr Baudis wrote:\n> Some common gripes for both StGIT and pg (well, I'm using some\n> ridiculously old StGIT version, so this may not apply anymore there):\n>\n> \t* stg new --force - seriously, what's the point?! I always to\n> \tthe change first and when it's any good, I want to create a\n> \tpatch for it.\n\nThis was fixed couple of weeks ago in the main branch. No need to pass\n--force anymore.\n\n> \t* I can't just get the patch in its \"canonical ready-to-mail\n> \tform\" on stdout so that I could easily review it. Why is\n> \tpg-export insisting to dump it to a file?\n\nTo view the patch you can use 'stg diff -r /' but it doesn't\nshow the description. Dumping the full patch on stdout would be\nuseful, indeed. The export and mail commands use different templates\nand the latter even adds the standard mail headers. Which of these two\ncommands would you prefer to dump the patch on stdout (both is fine as\nwell)?\n\nAnother thing that's missing in StGIT is the import of a series of\npatches. At the moment I run a small shell script to import individual\npatches.\n\n-- \nCatalin\n"},{"id":"16108","messageId":"20060214100844.GA1234@diana.vm.bytemark.co.uk","threadId":"3286","inReplyTo":"tnxoe1aqoj2.fsf@arm.com","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-02-14T10:08:44Z","receivedAt":"2006-02-14T10:08:44Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-02-14 09:26:41 +0000, Catalin Marinas wrote:\n\n> Another thing that's missing in StGIT is the import of a series of\n> patches. At the moment I run a small shell script to import\n> individual patches.\n\nOne thing I would like to see in stgit is the opposite of \"stg\ncommit\"; instead of converting patches to regular commits, take the\ntopmost regular commits and convert them to patches.\n\nFor example, \"stg uncommit foo bar baz\" would -- regardless of any\nexisting patches, applied or not -- convert the top three regular\ncommits, with comments and all, to stgit patches called foo, bar, and\nbaz. These would be already applied, at the bottom of the stack. I\nimagine all one would have to do is to modify some stgit metadata, so\nthe operation could be really cheap.\n\nOf course, \"stg uncommit\" is allowed to reject any commit with more\nthan one parent, since those can't be represented as stgit patches.\n\nThis would perhaps not add much power to an all-stgit workflow, but it\nwould be a really convenient way to edit recent git history. Sort of\nlike a more convenient rebase. And a great way to lure new users. :-)\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"16111","messageId":"43F1F5CB.10402@citi.umich.edu","threadId":"3286","inReplyTo":"20060214100844.GA1234@diana.vm.bytemark.co.uk","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Chuck Lever","fromEmail":"cel@citi.umich.edu","sentAt":"2006-02-14T15:22:51Z","receivedAt":"2006-02-14T15:22:51Z","isPatch":false,"sender":{"key":"cel@citi.umich.edu","avatar":null},"body":"Karl Hasselström wrote:\n> On 2006-02-14 09:26:41 +0000, Catalin Marinas wrote:\n> \n> \n>>Another thing that's missing in StGIT is the import of a series of\n>>patches. At the moment I run a small shell script to import\n>>individual patches.\n> \n> \n> One thing I would like to see in stgit is the opposite of \"stg\n> commit\"; instead of converting patches to regular commits, take the\n> topmost regular commits and convert them to patches.\n> \n> For example, \"stg uncommit foo bar baz\" would -- regardless of any\n> existing patches, applied or not -- convert the top three regular\n> commits, with comments and all, to stgit patches called foo, bar, and\n> baz. These would be already applied, at the bottom of the stack. I\n> imagine all one would have to do is to modify some stgit metadata, so\n> the operation could be really cheap.\n> \n> Of course, \"stg uncommit\" is allowed to reject any commit with more\n> than one parent, since those can't be represented as stgit patches.\n> \n> This would perhaps not add much power to an all-stgit workflow, but it\n> would be a really convenient way to edit recent git history. Sort of\n> like a more convenient rebase. And a great way to lure new users. :-)\n\ni think you want \"stg pick --reverse\" ?\n\n\nbegin:vcard\nfn:Chuck Lever\nn:Lever;Charles\norg:Network Appliance, Incorporated;Open Source NFS Client Development\nadr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA\nemail;internet:cel@citi.umich.edu\ntitle:Member of Technical Staff\ntel;work:+1 734 763-4415\ntel;fax:+1 734 763 4434\ntel;home:+1 734 668-1089\nx-mozilla-html:FALSE\nurl:http://troy.citi.umich.edu/u/cel/\nversion:2.1\nend:vcard\n\n"},{"id":"16113","messageId":"20060214160747.GA6350@diana.vm.bytemark.co.uk","threadId":"3286","inReplyTo":"43F1F5CB.10402@citi.umich.edu","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-02-14T16:07:47Z","receivedAt":"2006-02-14T16:07:47Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-02-14 10:22:51 -0500, Chuck Lever wrote:\n\n> Karl Hasselström wrote:\n>\n> > One thing I would like to see in stgit is the opposite of \"stg\n> > commit\"; instead of converting patches to regular commits, take\n> > the topmost regular commits and convert them to patches.\n> >\n> > For example, \"stg uncommit foo bar baz\" would -- regardless of any\n> > existing patches, applied or not -- convert the top three regular\n> > commits, with comments and all, to stgit patches called foo, bar,\n> > and baz. These would be already applied, at the bottom of the\n> > stack. I imagine all one would have to do is to modify some stgit\n> > metadata, so the operation could be really cheap.\n> >\n> > Of course, \"stg uncommit\" is allowed to reject any commit with\n> > more than one parent, since those can't be represented as stgit\n> > patches.\n> >\n> > This would perhaps not add much power to an all-stgit workflow,\n> > but it would be a really convenient way to edit recent git\n> > history. Sort of like a more convenient rebase. And a great way to\n> > lure new users. :-)\n>\n> i think you want \"stg pick --reverse\" ?\n\nNo, I literally want the opposite of \"stg commit\", so that the\nsequence \"stg commit; stg uncommit\" has zero net effect.\n\nSay we have the following situation (stack growing downward, of\ncourse):\n\n :\n |\n a\n |\n b\n |\n c <- bases/master\n |\n d <- applied patch \"foo\"\n |\n e <- applied patch \"bar\"; HEAD\n |\n f <- unapplied patch \"baz\"\n |\n :\n\nIn this situation, the hypothetical \"stg uncommit\" command would have\nthe following effect:\n\n $ stg uncommit goo baa\n\n :\n |\n a <- bases/master\n |\n b <- applied patch \"baa\"\n |\n c <- applied patch \"goo\"\n |\n d <- applied patch \"foo\"\n |\n e <- applied patch \"bar\"; HEAD\n |\n f <- unapplied patch \"baz\"\n |\n :\n\nNote that HEAD is unchanged; the only thing that has happend is that\nstgit has taken over the topmost two commits, and turned them into\npatches. No git operations whatsoever have taken place; all stgit had\nto do was change the value of bases/master and add bookkeeping\ninformation for the two new patches.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"16149","messageId":"43F2445A.6020109@citi.umich.edu","threadId":"3286","inReplyTo":"20060214160747.GA6350@diana.vm.bytemark.co.uk","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Chuck Lever","fromEmail":"cel@citi.umich.edu","sentAt":"2006-02-14T20:58:02Z","receivedAt":"2006-02-14T20:58:02Z","isPatch":false,"sender":{"key":"cel@citi.umich.edu","avatar":null},"body":"Karl Hasselström wrote:\n> On 2006-02-14 10:22:51 -0500, Chuck Lever wrote:\n> \n> \n>>Karl Hasselström wrote:\n>>\n>>\n>>>One thing I would like to see in stgit is the opposite of \"stg\n>>>commit\"; instead of converting patches to regular commits, take\n>>>the topmost regular commits and convert them to patches.\n>>>\n>>>For example, \"stg uncommit foo bar baz\" would -- regardless of any\n>>>existing patches, applied or not -- convert the top three regular\n>>>commits, with comments and all, to stgit patches called foo, bar,\n>>>and baz. These would be already applied, at the bottom of the\n>>>stack. I imagine all one would have to do is to modify some stgit\n>>>metadata, so the operation could be really cheap.\n>>>\n>>>Of course, \"stg uncommit\" is allowed to reject any commit with\n>>>more than one parent, since those can't be represented as stgit\n>>>patches.\n>>>\n>>>This would perhaps not add much power to an all-stgit workflow,\n>>>but it would be a really convenient way to edit recent git\n>>>history. Sort of like a more convenient rebase. And a great way to\n>>>lure new users. :-)\n>>\n>>i think you want \"stg pick --reverse\" ?\n> \n> \n> No, I literally want the opposite of \"stg commit\", so that the\n> sequence \"stg commit; stg uncommit\" has zero net effect.\n\ngotcha.\n\nwell, that would work OK for maintainers, but would be kind of strange \nfor folks who are pulling from such a repository. how would that work?\n\nmy impression of git is that you don't change stuff that's already \ncommitted. you revert changes by applying a new commit that backs out \nthe original changes. i'm speculating, but i suspect that's why there's \na \"stg pick --reverse\" and not a \"stg uncommit.\"\n\n\n\nbegin:vcard\nfn:Chuck Lever\nn:Lever;Charles\norg:Network Appliance, Incorporated;Open Source NFS Client Development\nadr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA\nemail;internet:cel@citi.umich.edu\ntitle:Member of Technical Staff\ntel;work:+1 734 763 4415\ntel;fax:+1 734 763 4434\ntel;home:+1 734 668 1089\nx-mozilla-html:FALSE\nurl:http://troy.citi.umich.edu/u/cel/\nversion:2.1\nend:vcard\n\n"},{"id":"16161","messageId":"20060214222913.GK31278@pasky.or.cz","threadId":"3286","inReplyTo":"43F2445A.6020109@citi.umich.edu","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-02-14T22:29:13Z","receivedAt":"2006-02-14T22:29:13Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Feb 14, 2006 at 09:58:02PM CET, I got a letter\nwhere Chuck Lever said that...\n> my impression of git is that you don't change stuff that's already \n> committed. you revert changes by applying a new commit that backs out \n> the original changes. i'm speculating, but i suspect that's why there's \n> a \"stg pick --reverse\" and not a \"stg uncommit.\"\n\nIt is ok as long as you know what are you doing - if you don't push out\nthe commits you've just \"undid\" (or work on a public accessible\nrepository in the first place, but I think that's kind of rare these\ndays; quick survey - does anyone reading these lines do that?), there's\nnothing wrong on it, and it gives you nice flexibility.\n\nFor example, to import bunch of patches (I guess that's the original\nintention behind this) you just run git-am on them and then stg uncommit\nall of the newly added commits.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nOf the 3 great composers Mozart tells us what it's like to be human,\nBeethoven tells us what it's like to be Beethoven and Bach tells us\nwhat it's like to be the universe. -- Douglas Adams\n"},{"id":"16170","messageId":"43F2745D.4010800@vilain.net","threadId":"3286","inReplyTo":"20060214222913.GK31278@pasky.or.cz","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-02-15T00:22:53Z","receivedAt":"2006-02-15T00:22:53Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Petr Baudis wrote:\n>>my impression of git is that you don't change stuff that's already \n>>committed. you revert changes by applying a new commit that backs out \n>>the original changes. i'm speculating, but i suspect that's why there's \n>>a \"stg pick --reverse\" and not a \"stg uncommit.\"\n> It is ok as long as you know what are you doing - if you don't push out\n> the commits you've just \"undid\" (or work on a public accessible\n> repository in the first place, but I think that's kind of rare these\n> days; quick survey - does anyone reading these lines do that?), there's\n> nothing wrong on it, and it gives you nice flexibility.\n\nYes, and this is one problem I envision with publishing a git repository\nwith an stgit stack applied - somebody later doing a pull of it will not\nfind the head revision they had. I'm not sure what the net effect of\nthis will be, though.\n\nSam.\n"},{"id":"16172","messageId":"20060215003510.GA25715@spearce.org","threadId":"3286","inReplyTo":"43F2745D.4010800@vilain.net","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-02-15T00:35:10Z","receivedAt":"2006-02-15T00:35:10Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sam Vilain wrote:\n> Petr Baudis wrote:\n> >>my impression of git is that you don't change stuff that's already \n> >>committed. you revert changes by applying a new commit that backs out \n> >>the original changes. i'm speculating, but i suspect that's why there's \n> >>a \"stg pick --reverse\" and not a \"stg uncommit.\"\n> >It is ok as long as you know what are you doing - if you don't push out\n> >the commits you've just \"undid\" (or work on a public accessible\n> >repository in the first place, but I think that's kind of rare these\n> >days; quick survey - does anyone reading these lines do that?), there's\n> >nothing wrong on it, and it gives you nice flexibility.\n> \n> Yes, and this is one problem I envision with publishing a git repository\n> with an stgit stack applied - somebody later doing a pull of it will not\n> find the head revision they had. I'm not sure what the net effect of\n> this will be, though.\n\nIt would cause some pain for anyone pulling from it with git-pull, as\ngit-pull won't happily go backwards from what I've seen. But I think\nyou can force it to do so even if it won't make sense during the\nresulting merge, which then leaves the user in an interesting state.\n\nThis is actually why pg-rebase doesn't care what you move to\nwhen you grab the remote's commit; it just jumps to that commit\nand pushes your patch stack back down onto it. So if the remote\nrebuilds itself through a new commit lineage which you have never\nseen before the next pg-rebase will still update to it. But on\nthe other hand if you have a commit that isn't in your local patch\nstack its gone into the bit bucket.\n\nPublishing a repository with a stg (or pg) patch series isn't\na problem; the problem is that no clients currently know how to\nfollow along with the remote repository's patch series. And I can't\nthink of a sensible behavior for doing so that isn't what git-core is\nalready doing today for non patch series type clients (as in don't go\nbackwards by popping but instead by pushing a negative delta). :-)\n\n-- \nShawn.\n"},{"id":"16175","messageId":"20060215011425.GM31278@pasky.or.cz","threadId":"3286","inReplyTo":"20060215003510.GA25715@spearce.org","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-02-15T01:14:25Z","receivedAt":"2006-02-15T01:14:25Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Feb 15, 2006 at 01:35:10AM CET, I got a letter\nwhere Shawn Pearce said that...\n> Publishing a repository with a stg (or pg) patch series isn't\n> a problem; the problem is that no clients currently know how to\n> follow along with the remote repository's patch series. And I can't\n> think of a sensible behavior for doing so that isn't what git-core is\n> already doing today for non patch series type clients (as in don't go\n> backwards by popping but instead by pushing a negative delta). :-)\n\nNew Cogito will automagically do the right thing if you are just\nfast-forwarding and you are using cg-update - if the branch rebased, it\nwill happily follow (but cg-fetch + cg-merge will NOT and it will fall\nback to the tree merge).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nOf the 3 great composers Mozart tells us what it's like to be human,\nBeethoven tells us what it's like to be Beethoven and Bach tells us\nwhat it's like to be the universe. -- Douglas Adams\n"},{"id":"16185","messageId":"20060215041142.GA21048@fieldses.org","threadId":"3286","inReplyTo":"20060215003510.GA25715@spearce.org","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-02-15T04:11:42Z","receivedAt":"2006-02-15T04:11:42Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Tue, Feb 14, 2006 at 07:35:10PM -0500, Shawn Pearce wrote:\n> Publishing a repository with a stg (or pg) patch series isn't\n> a problem; the problem is that no clients currently know how to\n> follow along with the remote repository's patch series. And I can't\n> think of a sensible behavior for doing so that isn't what git-core is\n> already doing today for non patch series type clients (as in don't go\n> backwards by popping but instead by pushing a negative delta). :-)\n\nIf you represent each patch as a branch, with each modification to the\npatch a commit on the corresponding branch, and each \"push\" operation a\nmerge from the branch corresponding to the previous patch to a branch\ncorresponding to the new patch (isn't that what pg's trying to do?),\nthen it should be possible just to track the branch corresponding to the\ntop patch.\n\nIn theory I guess it should also be possible to merge patch series that\nhave followed two lines of development, by merging each corresponding\nbranch.\n\nThe history would be really complicated. You'd need to figure out how\nto track the patch comments too, and you'd need scripts to convert to\njust a simple series of commits for submitting upstream. Probably not\nworth the trouble, but I don't know.\n\nIf you really want revision control on patches the simplest thing might\nbe just to run quilt or Andrew Morton's scripts on top of a git\nrepository--the documentation with Andrew's scripts recommends doing\nthat with CVS.\n\n--b,\n"},{"id":"16191","messageId":"20060215065411.GB26632@spearce.org","threadId":"3286","inReplyTo":"20060215041142.GA21048@fieldses.org","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-02-15T06:54:11Z","receivedAt":"2006-02-15T06:54:11Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"J. Bruce Fields\" wrote:\n> On Tue, Feb 14, 2006 at 07:35:10PM -0500, Shawn Pearce wrote:\n> > Publishing a repository with a stg (or pg) patch series isn't\n> > a problem; the problem is that no clients currently know how to\n> > follow along with the remote repository's patch series. And I can't\n> > think of a sensible behavior for doing so that isn't what git-core is\n> > already doing today for non patch series type clients (as in don't go\n> > backwards by popping but instead by pushing a negative delta). :-)\n> \n> If you represent each patch as a branch, with each modification to the\n> patch a commit on the corresponding branch, and each \"push\" operation a\n> merge from the branch corresponding to the previous patch to a branch\n> corresponding to the new patch (isn't that what pg's trying to do?),\n> then it should be possible just to track the branch corresponding to the\n> top patch.\n\nYes that's pg in a nutshell.\n\nBut what happens when I pop back two patches (of three) and then push\ndown a different (fourth) patch? The tree just rewound backwards\nand then forwards again in a different direction. (I apologize for\nnot being able to draw a nice ASCII art diagram of this, that's a\nskill I'll have to learn to keep up with you guys.) This is the\nissue with Junio's pu branch in git.git and is why some people\napparently don't follow it.\n\nStGIT and pg aren't the only ones who suffer from this wonderful\nlittle feature of GIT.\n\n> In theory I guess it should also be possible to merge patch series that\n> have followed two lines of development, by merging each corresponding\n> branch.\n\nOf course. If I delete all of the refs used by pg to mark the patch\nboundaries its just another GIT branch. Ditto for StGIT. So clearly\nyou can merge them together just like any other GIT branch.\n\nThe open question is could you preserve the patch boundaries\nwhile doing the merge. Probably not. It would become way to\ncomplicated as you would want to merge the entire branch and not each\nindividual patch as the individual patch merges may not work but the\nlarger branch merge might go through without human intervention.\nOf course you can try to keep the patch boundaries by exporting\nall of the patches from the one branch and push them on top of\nthe current branch. But isn't that what a 3 way merge is anyway?\nAnd again that might not work as well as taking the larger patch\nand pushing that down. :-)\n\n> The history would be really complicated. You'd need to figure out how\n> to track the patch comments too, and you'd need scripts to convert to\n> just a simple series of commits for submitting upstream. Probably not\n> worth the trouble, but I don't know.\n\nI think I'm almost there with pg. One of my next tasks is the\npatch log ripping code. This is really only complicated because GIT\nwon't let me store the base of a 3 way merge as part of a commit;\nall I can store is the set of parents. If I had the base in the\ncommit (and specifically marked as such so I can tell it from the\nend points) then I could easily walk through the log to extract all\ncommits relevant to a patch and seek forward and backward over it.\n\nPerhaps I could cheat and record 3 parents: (HEAD, base, last).\nI wonder what gitk would make of that mess. I doubt it would display\nany better than the current (HEAD, last) format I'm using now.\n\n> If you really want revision control on patches the simplest thing might\n> be just to run quilt or Andrew Morton's scripts on top of a git\n> repository--the documentation with Andrew's scripts recommends doing\n> that with CVS.\n\nTrue but you also then run into problems about needing to know which\nbase each patch revision was applied against so you can reproduce\na source tree plus patch at a specific point in time.\n\nWhen I started pg I first thought about recording a patch in a\nsecondary index/working directory where each patch was its own file\nand use git-diff-tree to extract the patch, commit it as a blob in\nthe secondary index/directory, and push it onto the series by reading\nthe blob in and running git-apply on the patch stored within it.\n\nI ruled this strategy out as it just felt like it would be too\nslow and rather unnatural to work on with existing GIT tools.\nI didn't want to write a full porcelain; I was really hoping to just\nextend Cogito to get a patch stack that worked the way *I* wanted a\npatch stack to work, which was close to StGIT but not quite StGIT.\n(Of course it didn't work out this way when I picked a prefix of\n'pg' instead of 'cg' for my new commands.) :-|\n\n-- \nShawn.\n"},{"id":"16205","messageId":"20060215101136.GB26911@diana.vm.bytemark.co.uk","threadId":"3286","inReplyTo":"43F2445A.6020109@citi.umich.edu","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-02-15T10:11:36Z","receivedAt":"2006-02-15T10:11:36Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-02-14 15:58:02 -0500, Chuck Lever wrote:\n\n> Karl Hasselström wrote:\n>\n> > No, I literally want the opposite of \"stg commit\", so that the\n> > sequence \"stg commit; stg uncommit\" has zero net effect.\n>\n> well, that would work OK for maintainers, but would be kind of\n> strange for folks who are pulling from such a repository. how would\n> that work?\n\nI didn't plan to publish branches where this kind of history munging\nwas being done. It's precisely like \"git rebase\" in that regard --\nit's a tool for cleaning up history before it is published.\n\n> my impression of git is that you don't change stuff that's already\n> committed. you revert changes by applying a new commit that backs\n> out the original changes.\n\nYou don't change stuff that's already committed _and published_ (well,\nexcept for pu branches :-). Rewriting history is perfectly OK up until\nthe moment someone has pulled your branch.\n\n> i'm speculating, but i suspect that's why there's a \"stg pick\n> --reverse\" and not a \"stg uncommit.\"\n\nI don't think I've been very successful in communicating exactly what\nI want \"stg uncommit\" for. It's not that I want to undo a committed\nchange -- what I want is to transform it into an stgit patch so that I\ncan edit it with a minimum of effort.\n\n $ edit edit edit\n $ git-commit -a -m \"create foo\"\n $ edit edit edit\n $ git-commit -a -m \"improve foo\"\n $ edit edit edit\n $ git-commit -a -m \"improve bar\"\n\n # Oops, I realize that the \"create foo\" changeset had a debug\n # printout left in it, and I wasn't already using stgit.\n\n $ stg init\n $ stg uncommit improve-bar improve-foo create-foo\n $ stg stg pop --to=create-foo\n $ edit --remove=debug-printout\n $ stg refresh\n $ stg push --all\n\nSimilar use-cases for e.g. reordering commits, merging commits,\ndeleting one commit in the middle of a chain of good ones, etc. are\neasy to come up with. The point is that stgit alreay handles all this,\n_but only if you have been using stgit from the start_. What \"stg\nuncommit\" does is basically to import (linear) git history into stgit,\nwhere a powerful toolset exists to edit it.\n\nYou can actually do this today; just create a new branch where you\nwant your new stgit stack to be based, and \"stg pick\" the\ncommits/patches from the old branch:\n\n $ git-checkout -b new-branch HEAD^^^\n $ stg init\n $ stg pick old-branch^^^ -n create-foo\n $ stg pick old-branch^^ -n improve-foo\n $ stg pick old-branch^ -n improve-bar\n $ git-branch -D old-branch\n $ git-checkout -b old-branch\n $ git-branch -d new-branch\n\nThis series of commands also converts the top three commits to stgit\npatches, and leaves the user on the same branch where she started (it\ndoes _exactly_ the same job as \"stg uncommit improve-bar improve-foo\ncreate-foo\"), but it's a lot of work, and a typo could lose commits.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"16206","messageId":"43F305AF.70808@op5.se","threadId":"3286","inReplyTo":"20060215101136.GB26911@diana.vm.bytemark.co.uk","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-02-15T10:42:55Z","receivedAt":"2006-02-15T10:42:55Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Karl Hasselström wrote:\n> On 2006-02-14 15:58:02 -0500, Chuck Lever wrote:\n> \n> \n>>Karl Hasselström wrote:\n>>\n>>\n>>>No, I literally want the opposite of \"stg commit\", so that the\n>>>sequence \"stg commit; stg uncommit\" has zero net effect.\n>>\n>>well, that would work OK for maintainers, but would be kind of\n>>strange for folks who are pulling from such a repository. how would\n>>that work?\n> \n> \n> I didn't plan to publish branches where this kind of history munging\n> was being done. It's precisely like \"git rebase\" in that regard --\n> it's a tool for cleaning up history before it is published.\n> \n> \n>>my impression of git is that you don't change stuff that's already\n>>committed. you revert changes by applying a new commit that backs\n>>out the original changes.\n> \n> \n> You don't change stuff that's already committed _and published_ (well,\n> except for pu branches :-). Rewriting history is perfectly OK up until\n> the moment someone has pulled your branch.\n> \n> \n>>i'm speculating, but i suspect that's why there's a \"stg pick\n>>--reverse\" and not a \"stg uncommit.\"\n> \n> \n> I don't think I've been very successful in communicating exactly what\n> I want \"stg uncommit\" for. It's not that I want to undo a committed\n> change -- what I want is to transform it into an stgit patch so that I\n> can edit it with a minimum of effort.\n> \n> $ edit edit edit\n> $ git-commit -a -m \"create foo\"\n> $ edit edit edit\n> $ git-commit -a -m \"improve foo\"\n> $ edit edit edit\n> $ git-commit -a -m \"improve bar\"\n> \n> # Oops, I realize that the \"create foo\" changeset had a debug\n> # printout left in it, and I wasn't already using stgit.\n> \n> $ stg init\n> $ stg uncommit improve-bar improve-foo create-foo\n> $ stg stg pop --to=create-foo\n> $ edit --remove=debug-printout\n> $ stg refresh\n> $ stg push --all\n> \n\nThe same workflow, with less hassle (and already implemented)\n\n$ git format-patch -k HEAD~3\n$ edit 0001-*\n$ git am -k 000*\n\n\n> Similar use-cases for e.g. reordering commits, merging commits,\n> deleting one commit in the middle of a chain of good ones, etc. are\n> easy to come up with. The point is that stgit alreay handles all this,\n> _but only if you have been using stgit from the start_. What \"stg\n> uncommit\" does is basically to import (linear) git history into stgit,\n> where a powerful toolset exists to edit it.\n> \n> You can actually do this today; just create a new branch where you\n> want your new stgit stack to be based, and \"stg pick\" the\n> commits/patches from the old branch:\n> \n> $ git-checkout -b new-branch HEAD^^^\n> $ stg init\n> $ stg pick old-branch^^^ -n create-foo\n> $ stg pick old-branch^^ -n improve-foo\n> $ stg pick old-branch^ -n improve-bar\n> $ git-branch -D old-branch\n> $ git-checkout -b old-branch\n> $ git-branch -d new-branch\n> \n> This series of commands also converts the top three commits to stgit\n> patches, and leaves the user on the same branch where she started (it\n> does _exactly_ the same job as \"stg uncommit improve-bar improve-foo\n> create-foo\"), but it's a lot of work, and a typo could lose commits.\n> \n\nIsn't this akin to what \"git cherry-pick\" does, except for the \"convert \nto stgit patches\" thing?\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"16210","messageId":"20060215112502.GC26911@diana.vm.bytemark.co.uk","threadId":"3286","inReplyTo":"43F305AF.70808@op5.se","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-02-15T11:25:02Z","receivedAt":"2006-02-15T11:25:02Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-02-15 11:42:55 +0100, Andreas Ericsson wrote:\n\n> Karl Hasselström wrote:\n>\n> > You can actually do this today; just create a new branch where you\n> > want your new stgit stack to be based, and \"stg pick\" the\n> > commits/patches from the old branch:\n> >\n> > $ git-checkout -b new-branch HEAD^^^\n> > $ stg init\n> > $ stg pick old-branch^^^ -n create-foo\n> > $ stg pick old-branch^^ -n improve-foo\n> > $ stg pick old-branch^ -n improve-bar\n> > $ git-branch -D old-branch\n> > $ git-checkout -b old-branch\n> > $ git-branch -d new-branch\n> >\n> > This series of commands also converts the top three commits to\n> > stgit patches, and leaves the user on the same branch where she\n> > started (it does _exactly_ the same job as \"stg uncommit\n> > improve-bar improve-foo create-foo\"), but it's a lot of work, and\n> > a typo could lose commits.\n>\n> Isn't this akin to what \"git cherry-pick\" does, except for the\n> \"convert to stgit patches\" thing?\n\nYes, \"stg pick\" and git-cherry-pick are very similar as far as I know,\nthe only difference being that \"stg pick\" creates an stgit patch while\ngit-cherry-pick creates a regular commit. (And an applied stgit patch\nis just a regular commit which stgit maintains some metadata about.)\n\nHowever, using git-cherry-pick in this scenario would just recreate\nthe initial state exactly, since converting the commits to stgit\npatches was what it was all about.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"16211","messageId":"20060215112728.GD26911@diana.vm.bytemark.co.uk","threadId":"3286","inReplyTo":"20060215112502.GC26911@diana.vm.bytemark.co.uk","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-02-15T11:27:28Z","receivedAt":"2006-02-15T11:27:28Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-02-15 12:25:02 +0100, Karl Hasselström wrote:\n\n> However, using git-cherry-pick in this scenario would just recreate\n> the initial state exactly, since converting the commits to stgit\n> patches was what it was all about.\n\n\"since\" -> \"and\"\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"16221","messageId":"b0943d9e0602150912h55fb87d0r@mail.gmail.com","threadId":"3286","inReplyTo":"20060214045618.GA12844@spearce.org","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2006-02-15T17:12:55Z","receivedAt":"2006-02-15T17:12:55Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 14/02/06, Shawn Pearce wrote:\n> Catalin Marinas wrote:\n> > > - Automatic detection (and cancellation) of returning patches.\n[...]\n> > StGIT has been doing this from the beginning. You would need to run a\n> > 'stg clean' after a rebase (or push). I prefer to run this command\n> > manually so that 'stg series -e' would show the empty patches and let\n> > me decided what to do with them.\n>\n> Actually StGIT didn't do this correctly for one of my use cases\n> and that's one of the things that drove me to trying to write pg\n> (because I wondered if there was a way to resolve it automatically).\n> Try building a patch series such as:\n[...]\n> StGIT seemed to not handle this when it tried to reapply the two\n> already applied patches. A won't apply because the file coming\n> down is actually A+B, not A's predecessor and not A. B won't apply\n> because the file also isn't A (B's predecessor).\n\nYou are right, if two patches modify the same line and both were\nmerged upstream, the three-way merging would report a conflict for the\nfirst patch and maybe the second (depending on how the first conflict\nwas resolved).\n\n> pg resolves this by attempting to automatically fold patches during\n> a pg-rebase (equiv. of stg pull). If a patch fails to push cleanly\n> and there's another patch immediately behind it which also should\n> be reapplied pg aborts and retries pushing the combination of the\n> patches. This fixes my A+B case quite nicely during a rebase. :-)\n\nBut what would happen if there was a third-party patch that's\nmodifying the same line? A+B application would fail in this case. Does\npg go back to only apply A and report a conflict?\n\nThere is another problem with this approach if you have tens of\npatches. Would pg try to fold all of them?\n\nSome time ago I had a look at Darcs and its patch theory (patch\ncommuting). Their approach to conflicts was to include the conflicts\nin patch A and propagate them to the last patch to be merged. It's\nlike creating two versions of the conflicting hunk, one of them\ncorresponding to the local tree (that in patch A) and the other to the\nupstream tree. Merging patch B is only done in the local hunk in the\nend both conflicting hunks would be identical and one of them removed.\n\nWhile the above algrithm seems to work OK in Darcs (but quite resource\nintensive), it's pretty hard to implement and I don't think it's worth\nfor a small number of cases this could occur.\n\n--\nCatalin\n"},{"id":"16223","messageId":"b0943d9e0602150920y242a161w@mail.gmail.com","threadId":"3286","inReplyTo":"20060214061406.GA13238@spearce.org","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2006-02-15T17:20:28Z","receivedAt":"2006-02-15T17:20:28Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 14/02/06, Shawn Pearce wrote:\n> The diff-tree/apply approach is faster for a single commit then\n> read-tree -u -m is; even if totally different files are being\n> impacted and thus all stages collapse neatly to stage 0 in the index.\n> No wonder StGIT uses diff/apply!\n\nFor the simple tests you did the difference is not that big. It\nbecomes a real problem when there are many file deletions/additions in\nthe upstream tree since git-read-tree doesn't handle them and\ngit-merge-index would need to call the external tool for each of them.\n\nTo test the above, clone the 2.6.12 kernel version, create some\ntrivial patches and rebase to 2.6.16-rc3. StGIT was running even for 5\nminutes per patch before implementing the diff-tree/apply method.\n\n--\nCatalin\n"},{"id":"16224","messageId":"b0943d9e0602150925v6f01accfw@mail.gmail.com","threadId":"3286","inReplyTo":"20060214222913.GK31278@pasky.or.cz","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2006-02-15T17:25:30Z","receivedAt":"2006-02-15T17:25:30Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 14/02/06, Petr Baudis wrote:\n> Dear diary, on Tue, Feb 14, 2006 at 09:58:02PM CET, I got a letter\n> where Chuck Lever said that...\n> > my impression of git is that you don't change stuff that's already\n> > committed. you revert changes by applying a new commit that backs out\n> > the original changes. i'm speculating, but i suspect that's why there's\n> > a \"stg pick --reverse\" and not a \"stg uncommit.\"\n>\n> It is ok as long as you know what are you doing - if you don't push out\n> the commits you've just \"undid\" (or work on a public accessible\n> repository in the first place, but I think that's kind of rare these\n> days; quick survey - does anyone reading these lines do that?), there's\n> nothing wrong on it, and it gives you nice flexibility.\n>\n> For example, to import bunch of patches (I guess that's the original\n> intention behind this) you just run git-am on them and then stg uncommit\n> all of the newly added commits.\n\nThis is a sensible way of using an uncommit command but I initially\nthought it would be better to make things harder for people wanting to\nre-write the history. Anyway, I'll keep this command on my todo list.\n\n--\nCatalin\n"},{"id":"16225","messageId":"20060215175556.GA5742@spearce.org","threadId":"3286","inReplyTo":"b0943d9e0602150912h55fb87d0r@mail.gmail.com","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-02-15T17:55:56Z","receivedAt":"2006-02-15T17:55:56Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Catalin Marinas wrote:\n> > pg resolves this by attempting to automatically fold patches during\n> > a pg-rebase (equiv. of stg pull). If a patch fails to push cleanly\n> > and there's another patch immediately behind it which also should\n> > be reapplied pg aborts and retries pushing the combination of the\n> > patches. This fixes my A+B case quite nicely during a rebase. :-)\n> \n> But what would happen if there was a third-party patch that's\n> modifying the same line? A+B application would fail in this case. Does\n> pg go back to only apply A and report a conflict?\n\nWhen this occurs pg just gives up and leaves both patches A and\nB unapplied and gives you the list of patches which it couldn't\napply but wanted to. The working directory is left clean; its the\nnew base plus whatever patches before A that did apply cleanly.\nI could have pg go back and try pushing A again and leave the\nconflict ready for you to resolve but I don't always want that.\nSince the user can have that happen with a quick no-arg `pg-push`\nI leave it to the user to retry pushing A if they really think\nthat's worth trying.\n\nHowever if the last patch fails to push during a pg-rebase then pg\nleaves it alone and your working directory is dirty and you are left\nwith that last patch partially applied. At which point you can back\nit out by popping it off the stack or finish the conflict resolution.\n \n> There is another problem with this approach if you have tens of\n> patches. Would pg try to fold all of them?\n\nYea. Which might not be pretty. 10 patches would cause pg to\nattempt applying 11 patches before giving up, but each time the patch\nis increased in size to include its predecessors who also didn't\napply cleanly. As soon as a larger cluster applies pg goes back to\ntrying single patch application. Obviously this could take a while\nas the patch size is growing on each attempt and we are duplicating\nwork every time as pg always starts from a clean working directory.\n\nExample: Say I have A, B, C, D, E, F on the stack. A wasn't provided\nby the upstream and pushes down cleanly. B+C+D was given to me\nby the upstream so pg first tries B, fails, then B+C, fails, then\nB+C+D, succeeds, so it folds B+C+D into D and finishes pushing D.\nThen it tries E, if E succeeds it tries F on its own. If E fails it\ntries E+F. What's left in the working directory depends on if the\nlast operation was an auto-fold attempt or not and if it applied\ncleanly (or not).\n\n> Some time ago I had a look at Darcs and its patch theory (patch\n> commuting). Their approach to conflicts was to include the conflicts\n> in patch A and propagate them to the last patch to be merged. It's\n> like creating two versions of the conflicting hunk, one of them\n> corresponding to the local tree (that in patch A) and the other to the\n> upstream tree. Merging patch B is only done in the local hunk in the\n> end both conflicting hunks would be identical and one of them removed.\n> \n> While the above algrithm seems to work OK in Darcs (but quite resource\n> intensive), it's pretty hard to implement and I don't think it's worth\n> for a small number of cases this could occur.\n\nHmm. I had looked at Darcs over a year ago and found it to be a\nrather interesting idea but at the time it couldn't handle my ~7000\nfile tree (and GIT wasn't even getting started yet). I was actually\nthinking about trying to drag the rejecting hunks forward somehow\nwhen doing the auto-folding but I hadn't quite found a way to do\nthat easily. I have a gut feeling that most of the time when this\nproblem occurs its on a subset of the files involved in any given\npatch and that if I can push down a patch cleanly for 90+% of the\nfiles while delaying the conflicts forward that might actually be\nsomewhat reasonable. But maybe not. :-)\n\n-- \nShawn.\n"},{"id":"16227","messageId":"20060215194535.GA22007@fieldses.org","threadId":"3286","inReplyTo":"20060215065411.GB26632@spearce.org","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-02-15T19:45:35Z","receivedAt":"2006-02-15T19:45:35Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Wed, Feb 15, 2006 at 01:54:11AM -0500, Shawn Pearce wrote:\n> \"J. Bruce Fields\" wrote:\n> > On Tue, Feb 14, 2006 at 07:35:10PM -0500, Shawn Pearce wrote:\n> > > Publishing a repository with a stg (or pg) patch series isn't\n> > > a problem; the problem is that no clients currently know how to\n> > > follow along with the remote repository's patch series. And I can't\n> > > think of a sensible behavior for doing so that isn't what git-core is\n> > > already doing today for non patch series type clients (as in don't go\n> > > backwards by popping but instead by pushing a negative delta). :-)\n> > \n> > If you represent each patch as a branch, with each modification to the\n> > patch a commit on the corresponding branch, and each \"push\" operation a\n> > merge from the branch corresponding to the previous patch to a branch\n> > corresponding to the new patch (isn't that what pg's trying to do?),\n> > then it should be possible just to track the branch corresponding to the\n> > top patch.\n> \n> Yes that's pg in a nutshell.\n> \n> But what happens when I pop back two patches (of three) and then push\n> down a different (fourth) patch? The tree just rewound backwards\n> and then forwards again in a different direction.\n\nSo you've got p1, p2, and p3 applied, each with its corresponding\nbranch--respectively, b1, b2, and b3. Popping two patches just checks\nout b1, and doesn't affect the repository at all. If you push a new\npatch, p4, you've just created a new branch, b4--you haven't touched the\nexisting branches. If you push p2 and p3 back on, you're just merging\nthe new changes from b4 into b2 and then merging the newly merged b2\ninto b3.\n\n>From the point of view of someone tracking b3, this is all fine. OK,\nmaybe it's excessively complicated, but pulls should work, because it\nnever sees history diseappear as it does when you represent each patch\nwith a commit on a single branch.\n\n> > If you really want revision control on patches the simplest thing might\n> > be just to run quilt or Andrew Morton's scripts on top of a git\n> > repository--the documentation with Andrew's scripts recommends doing\n> > that with CVS.\n> \n> True but you also then run into problems about needing to know which\n> base each patch revision was applied against so you can reproduce\n> a source tree plus patch at a specific point in time.\n\nRight, so you keep the tree under revision control as well as the\npatches.\n\n--b.\n"},{"id":"16253","messageId":"20060216075440.GA11939@diana.vm.bytemark.co.uk","threadId":"3286","inReplyTo":"b0943d9e0602150925v6f01accfw@mail.gmail.com","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-02-16T07:54:40Z","receivedAt":"2006-02-16T07:54:40Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-02-15 17:25:30 +0000, Catalin Marinas wrote:\n\n> On 14/02/06, Petr Baudis wrote:\n>\n> > It is ok as long as you know what are you doing - if you don't\n> > push out the commits you've just \"undid\" (or work on a public\n> > accessible repository in the first place, but I think that's kind\n> > of rare these days; quick survey - does anyone reading these lines\n> > do that?), there's nothing wrong on it, and it gives you nice\n> > flexibility.\n> >\n> > For example, to import bunch of patches (I guess that's the\n> > original intention behind this) you just run git-am on them and\n> > then stg uncommit all of the newly added commits.\n>\n> This is a sensible way of using an uncommit command but I initially\n> thought it would be better to make things harder for people wanting\n> to re-write the history. Anyway, I'll keep this command on my todo\n> list.\n\nstgit rewrites history all the time anyway. And as far as I recall,\nthere's nothing in the documentation that warns the user not to\npublish stgit-managed branches. :-)\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"16264","messageId":"7vbqx7bnz7.fsf@assigned-by-dhcp.cox.net","threadId":"3286","inReplyTo":"20060215065411.GB26632@spearce.org","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-16T10:24:28Z","receivedAt":"2006-02-16T10:24:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> I think I'm almost there with pg. One of my next tasks is the\n> patch log ripping code. This is really only complicated because GIT\n> won't let me store the base of a 3 way merge as part of a commit;\n> all I can store is the set of parents. If I had the base in the\n> commit (and specifically marked as such so I can tell it from the\n> end points) then I could easily walk through the log to extract all\n> commits relevant to a patch and seek forward and backward over it.\n\nI think I know what you are talking about. Maybe you might be\ninterested to take a look at TO script in my todo branch [*1*]?\n\nAlso there is a sample hook script templates/hooks--pre-rebase \nthat uses the same idea used in the said script. These are what\nI use to manage the \"next\" branch (an aggregation of topic\nbranches being cooked).\n\nBy the way, please do *not* do this:\n\n Mail-Followup-To: \"J. Bruce Fields\" ,\n Sam Vilain , Petr Baudis ,...\n\t ...\n\nI wanted to reply to *you*, but by having the header you robbed\nabout 30 seconds from me, forcing me to edit the \"To:\"\naddressee.\n\n\n[Footnote]\n\n*1* todo branch does not have *any* ancestry relationship with\nmy primary branches, so please do not try to merge it in your\nprimary repository (unless you know what you are doing). Make a\nclone into a separate directory and running \"git checkout todo\"\nthere is the cleanest way to peek into it.\n"},{"id":"16265","messageId":"b0943d9e0602160233i68fe5879y@mail.gmail.com","threadId":"3286","inReplyTo":"7vbqx7bnz7.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2006-02-16T10:33:12Z","receivedAt":"2006-02-16T10:33:12Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 16/02/06, Junio C Hamano wrote:\n> By the way, please do *not* do this:\n>\n> Mail-Followup-To: \"J. Bruce Fields\" ,\n> Sam Vilain , Petr Baudis ,...\n> ...\n\nI think that's a \"feature\" of mutt that I couldn't understand. Every\ntime I got this header and looked at the mail client, it was... mutt\n:-).\n\n--\nCatalin\n"},{"id":"16266","messageId":"20060216104224.GA29192@ferdyx.org","threadId":"3286","inReplyTo":"b0943d9e0602160233i68fe5879y@mail.gmail.com","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Fernando J. Pereda","fromEmail":"ferdy@ferdyx.org","sentAt":"2006-02-16T10:42:24Z","receivedAt":"2006-02-16T10:42:24Z","isPatch":false,"sender":{"key":"ferdy@ferdyx.org","avatar":"https://gravatar.com/avatar/96bf7c1ddf7ccd430255bd12d9d42b212dbc033b28c668a2bdf9c3995aa81e61?d=mp&s=160"},"body":"On Thu, Feb 16, 2006 at 10:33:12AM +0000, Catalin Marinas wrote:\n> On 16/02/06, Junio C Hamano wrote:\n> > By the way, please do *not* do this:\n> >\n> > Mail-Followup-To: \"J. Bruce Fields\" ,\n> > Sam Vilain , Petr Baudis ,...\n> > ...\n> \n> I think that's a \"feature\" of mutt that I couldn't understand. Every\n> time I got this header and looked at the mail client, it was... mutt\n> :-).\n\nThat's because you told mutt you are subscribed to that list, so mutt\nwon't add you to Mail-Followup-To:, so you don't get duplicates. If you\ndon't tell mutt you are subscribed to the list, It will add your own\naddres there.\n\nI think it is a nice feature, although it seems to annoy Junio :)\n\nCheers,\nFerdy\n\n-- \nFernando J. Pereda Garcimartín\nGentoo Developer (Alpha,net-mail,mutt,git)\n20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4\n"},{"id":"16267","messageId":"7v64nfbmo6.fsf@assigned-by-dhcp.cox.net","threadId":"3286","inReplyTo":"20060216104224.GA29192@ferdyx.org","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-16T10:52:41Z","receivedAt":"2006-02-16T10:52:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Fernando J. Pereda\" writes:\n\n> That's because you told mutt you are subscribed to that list, so mutt\n> won't add you to Mail-Followup-To:, so you don't get duplicates. If you\n> don't tell mutt you are subscribed to the list, It will add your own\n> addres there.\n>\n> I think it is a nice feature, although it seems to annoy Junio :)\n\nRightfully so.\n\nLast I heard that was a feature mutt people regret. Go back to\nthe mail archive for details -- you robbed me 30 seconds so I\nwon't do a research for you this time as I usually do ;-).\n\nThe \"feature\" is to allow you be lazy and not filter on your own\nend and force everybody who wants to respond to you to fix up\nthe addressee header. In other words, it is not a \"feature\" for\npeople who receives your mail at all.\n"},{"id":"16268","messageId":"tnxfymjd0ei.fsf@arm.com","threadId":"3286","inReplyTo":"7v64nfbmo6.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@arm.com","sentAt":"2006-02-16T11:10:45Z","receivedAt":"2006-02-16T11:10:45Z","isPatch":false,"sender":{"key":"catalin.marinas@arm.com","avatar":null},"body":"Junio C Hamano wrote:\n> \"Fernando J. Pereda\" writes:\n>\n>> That's because you told mutt you are subscribed to that list, so mutt\n>> won't add you to Mail-Followup-To:, so you don't get duplicates. If you\n>> don't tell mutt you are subscribed to the list, It will add your own\n>> addres there.\n>>\n>> I think it is a nice feature, although it seems to annoy Junio :)\n>\n> Rightfully so.\n>\n> Last I heard that was a feature mutt people regret. Go back to\n> the mail archive for details -- you robbed me 30 seconds so I\n> won't do a research for you this time as I usually do ;-).\n\nFor Gnus users:\n\n(setq message-use-mail-followup-to nil)\n\n-- \nCatalin\n"},{"id":"16301","messageId":"20060217042728.14175.39928.stgit@backpacker.hemma.treskal.com","threadId":"3286","inReplyTo":"b0943d9e0602150925v6f01accfw@mail.gmail.com","subject":"[PATCH 0/2] stg uncommit","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-02-17T04:27:28Z","receivedAt":"2006-02-17T04:27:28Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"Here is that uncommit command I was going on and on and on about.\nThere's also some stricter checking that refs/heads/bases is reset to\nHEAD whenever we reach zero applied patches, since otherwise you can't\nuncommit patches on an empty stomach.\n\nNote the extremely cool feature that you can uncommit regardless of\nhow dirty your working tree is!\n\n-- \nKarl Hasselström\n"},{"id":"16303","messageId":"20060217043126.14175.21930.stgit@backpacker.hemma.treskal.com","threadId":"3286","inReplyTo":"20060217042728.14175.39928.stgit@backpacker.hemma.treskal.com","subject":"[PATCH 1/2] Update .git/refs/heads/base after patch deletion","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-02-17T04:31:26Z","receivedAt":"2006-02-17T04:31:26Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"Save the current HEAD into refs/heads/base if the stack is empty after\na patch has been deleted. This was not done before, which caused\nrefs/heads/base to not be updated after 'stg commit'. To guard against\nexisting repositories with no applied patches and HEAD !=\nrefs/heads/base, also do the update every time someone asks for the\nname of refs/heads/base.\n\nSigned-off-by: Karl Hasselström \n\n---\n\n stgit/stack.py | 2 ++\n 1 files changed, 2 insertions(+), 0 deletions(-)\n\ndiff --git a/stgit/stack.py b/stgit/stack.py\nindex 68a2936..bc39d14 100644\n--- a/stgit/stack.py\n+++ b/stgit/stack.py\n@@ -366,6 +366,7 @@ class Series:\n return names\n \n def get_base_file(self):\n+ self.__begin_stack_check()\n return self.__base_file\n \n def get_protected(self):\n@@ -686,6 +687,7 @@ class Series:\n f = file(self.__unapplied_file, 'w+')\n f.writelines([line + '\\n' for line in unapplied])\n f.close()\n+ self.__begin_stack_check()\n \n def forward_patches(self, names):\n \"\"\"Try to fast-forward an array of patches.\n"},{"id":"16302","messageId":"20060217043128.14175.60168.stgit@backpacker.hemma.treskal.com","threadId":"3286","inReplyTo":"20060217042728.14175.39928.stgit@backpacker.hemma.treskal.com","subject":"[PATCH 2/2] Add 'stg uncommit' command","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-02-17T04:31:29Z","receivedAt":"2006-02-17T04:31:29Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"Add an uncommit command, which is exactly the opposite of 'stg\ncommit'.\n\nSigned-off-by: Karl Hasselström \n\n---\n\n stgit/commands/commit.py | 5 ++-\n stgit/commands/uncommit.py | 80 ++++++++++++++++++++++++++++++++++++++++++++\n stgit/main.py | 2 +\n stgit/stack.py | 12 +++++--\n 4 files changed, 94 insertions(+), 5 deletions(-)\n\ndiff --git a/stgit/commands/commit.py b/stgit/commands/commit.py\nindex a3b7277..ed9a0b3 100644\n--- a/stgit/commands/commit.py\n+++ b/stgit/commands/commit.py\n@@ -28,8 +28,9 @@ usage = \"\"\"%prog [options]\n Merge the applied patches into the base of the current stack and\n remove them from the series while advancing the base.\n \n-Use this command only if you want to permanently store the applied\n-patches and no longer manage them with StGIT.\"\"\"\n+Use this command if you want to permanently store the applied patches\n+and no longer manage them with StGIT. If you should change your mind\n+later, use 'stg uncommit'.\"\"\"\n \n options = []\n \ndiff --git a/stgit/commands/uncommit.py b/stgit/commands/uncommit.py\nnew file mode 100644\nindex 0000000..4ac0dfb\n--- /dev/null\n+++ b/stgit/commands/uncommit.py\n@@ -0,0 +1,80 @@\n+__copyright__ = \"\"\"\n+Copyright (C) 2006, Catalin Marinas \n+\n+This program is free software; you can redistribute it and/or modify\n+it under the terms of the GNU General Public License version 2 as\n+published by the Free Software Foundation.\n+\n+This program is distributed in the hope that it will be useful,\n+but WITHOUT ANY WARRANTY; without even the implied warranty of\n+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n+GNU General Public License for more details.\n+\n+You should have received a copy of the GNU General Public License\n+along with this program; if not, write to the Free Software\n+Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA\n+\"\"\"\n+\n+import sys, os\n+from optparse import OptionParser, make_option\n+\n+from stgit.commands.common import *\n+from stgit.utils import *\n+from stgit import stack, git\n+\n+help = 'turn regular git commits into StGIT patches'\n+usage = \"\"\"%prog [options] [ ... ]\n+\n+Takes one or more git commits at the base of the current stack, and\n+turns them into StGIT patches. These new patches are alreay applied,\n+at the bottom of the stack. This is the exact opposite of 'stg\n+commit'.\n+\n+You can either give one patch name for each commit you wish to\n+uncommit, or use the --number option and exactly one patch name; StGIT\n+will then create numbered patches with the given patch name as prefix.\n+\n+Only commits with exactly one parent can be uncommitted; in other\n+words, you can't uncommmit a merge.\"\"\"\n+\n+options = [make_option('-n', '--number', type = 'int',\n+ help = 'uncommit the specified number of commits')]\n+\n+def func(parser, options, args):\n+ if len(args) == 0:\n+ parser.error('you must specify at least one patch name')\n+ if options.number:\n+ if len(args) != 1:\n+ parser.error('when using --number, specify exactly one patch name')\n+ patchnames = ['%s%d' % (args[0], i)\n+ for i in xrange(options.number - 1, -1, -1)]\n+ else:\n+ patchnames = args\n+\n+ if crt_series.get_protected():\n+ raise CmdException, 'This branch is protected. Uncommit is not permitted'\n+\n+ print 'Uncommitting %d patches...' % len(patchnames),\n+ sys.stdout.flush()\n+\n+ for patchname in patchnames:\n+ base_file = crt_series.get_base_file()\n+ commit_id = read_string(base_file)\n+ commit = git.Commit(commit_id)\n+ try:\n+ parent, = commit.get_parents()\n+ except ValueError:\n+ raise CmdException, ('Commit %s does not have exactly one parent'\n+ % commit_id)\n+ author_name, author_email, author_date = name_email_date(\n+ commit.get_author())\n+ crt_series.new_patch(patchname,\n+ can_edit = False, before_existing = True,\n+ top = commit_id, bottom = parent,\n+ message = commit.get_log(),\n+ author_name = author_name,\n+ author_email = author_email,\n+ author_date = author_date)\n+ write_string(base_file, parent)\n+\n+ print 'done'\ndiff --git a/stgit/main.py b/stgit/main.py\nindex 6d86ee4..4a48668 100644\n--- a/stgit/main.py\n+++ b/stgit/main.py\n@@ -57,6 +57,7 @@ import stgit.commands.series\n import stgit.commands.status\n import stgit.commands.top\n import stgit.commands.unapplied\n+import stgit.commands.uncommit\n \n \n #\n@@ -92,6 +93,7 @@ commands = {\n 'status': stgit.commands.status,\n 'top': stgit.commands.top,\n 'unapplied':stgit.commands.unapplied,\n+ 'uncommit': stgit.commands.uncommit,\n }\n \n def print_help():\ndiff --git a/stgit/stack.py b/stgit/stack.py\nindex bc39d14..05389bb 100644\n--- a/stgit/stack.py\n+++ b/stgit/stack.py\n@@ -621,7 +621,8 @@ class Series:\n unapplied = False, show_patch = False,\n top = None, bottom = None,\n author_name = None, author_email = None, author_date = None,\n- committer_name = None, committer_email = None):\n+ committer_name = None, committer_email = None,\n+ before_existing = False):\n \"\"\"Creates a new patch\n \"\"\"\n if self.__patch_applied(name) or self.__patch_unapplied(name):\n@@ -664,8 +665,13 @@ class Series:\n f.writelines([line + '\\n' for line in patches])\n f.close()\n else:\n- append_string(self.__applied_file, patch.get_name())\n- self.__set_current(name)\n+ if before_existing:\n+ insert_string(self.__applied_file, patch.get_name())\n+ if not self.get_current():\n+ self.__set_current(name)\n+ else:\n+ append_string(self.__applied_file, patch.get_name())\n+ self.__set_current(name)\n \n def delete_patch(self, name):\n \"\"\"Deletes a patch\n"},{"id":"16344","messageId":"43F646DD.8040103@gmail.com","threadId":"3286","inReplyTo":"20060213210001.GA31278@pasky.or.cz","subject":"Re: [ANNOUNCE] pg - A patch porcelain for GIT","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2006-02-17T21:57:49Z","receivedAt":"2006-02-17T21:57:49Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Petr Baudis wrote:\n> \t* I can't just get the patch in its \"canonical ready-to-mail\n> \tform\" on stdout so that I could easily review it. Why is\n> \tpg-export insisting to dump it to a file?\n\nI pushed tonight 2 patches for this. One of them adds a --stdout option\nto 'export' so that you can see the patches. The other patch adds a\n--mbox option to 'mail' that generates an mbox file on the stdout. This\nis useful not only for reviewing patches.\n\n-- \nCatalin\n"},{"id":"16400","messageId":"43F84D9A.2010905@gmail.com","threadId":"3286","inReplyTo":"20060217043128.14175.60168.stgit@backpacker.hemma.treskal.com","subject":"Re: [PATCH 2/2] Add 'stg uncommit' command","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2006-02-19T10:51:06Z","receivedAt":"2006-02-19T10:51:06Z","isPatch":true,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Karl Hasselström wrote:\n> Add an uncommit command, which is exactly the opposite of 'stg\n> commit'.\n\nApplied with two minor modifications. See below:\n\n> --- a/stgit/commands/commit.py\n> +++ b/stgit/commands/commit.py\n> @@ -28,8 +28,9 @@ usage = \"\"\"%prog [options]\n> Merge the applied patches into the base of the current stack and\n> remove them from the series while advancing the base.\n> \n> -Use this command only if you want to permanently store the applied\n> -patches and no longer manage them with StGIT.\"\"\"\n> +Use this command if you want to permanently store the applied patches\n> +and no longer manage them with StGIT. If you should change your mind\n> +later, use 'stg uncommit'.\"\"\"\n\nI removed this change because, even if uncommit does the opposite of\ncommit does, the intended use is not to use commit/uncommit in pairs.\n\n> diff --git a/stgit/commands/uncommit.py b/stgit/commands/uncommit.py\n> new file mode 100644\n> index 0000000..4ac0dfb\n> --- /dev/null\n> +++ b/stgit/commands/uncommit.py\n> @@ -0,0 +1,80 @@\n> +__copyright__ = \"\"\"\n> +Copyright (C) 2006, Catalin Marinas \n\nI added your name on the copyright since this is a new file.\n\nThanks,\n\nCatalin\n"},{"id":"16409","messageId":"20060219134558.GA4784@diana.vm.bytemark.co.uk","threadId":"3286","inReplyTo":"43F84D9A.2010905@gmail.com","subject":"Re: [PATCH 2/2] Add 'stg uncommit' command","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-02-19T13:45:58Z","receivedAt":"2006-02-19T13:45:58Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-02-19 10:51:06 +0000, Catalin Marinas wrote:\n\n> Karl Hasselström wrote:\n>\n> > diff --git a/stgit/commands/uncommit.py b/stgit/commands/uncommit.py\n> > new file mode 100644\n> > index 0000000..4ac0dfb\n> > --- /dev/null\n> > +++ b/stgit/commands/uncommit.py\n> > @@ -0,0 +1,80 @@\n> > +__copyright__ = \"\"\"\n> > +Copyright (C) 2006, Catalin Marinas \n>\n> I added your name on the copyright since this is a new file.\n\nI did that too at first, but then I changed it back since I reckoned\nmore than 50% of the file was copy-pasted from elsewhere. But thanks.\n:-)\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"16411","messageId":"20060219144752.GA5541@diana.vm.bytemark.co.uk","threadId":"3286","inReplyTo":"20060219134558.GA4784@diana.vm.bytemark.co.uk","subject":"Re: [PATCH 2/2] Add 'stg uncommit' command","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-02-19T14:47:52Z","receivedAt":"2006-02-19T14:47:52Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-02-19 14:45:58 +0100, Karl Hasselström wrote:\n\n> On 2006-02-19 10:51:06 +0000, Catalin Marinas wrote:\n>\n> > I added your name on the copyright since this is a new file.\n>\n> I did that too at first, but then I changed it back since I reckoned\n> more than 50% of the file was copy-pasted from elsewhere. But\n> thanks. :-)\n\nBy the way, it seems like my name got munged when you edited the\ncommit.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"16422","messageId":"43F8E008.3010103@vilain.net","threadId":"3286","inReplyTo":"20060219144752.GA5541@diana.vm.bytemark.co.uk","subject":"Re: [PATCH 2/2] Add 'stg uncommit' command","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-02-19T21:15:52Z","receivedAt":"2006-02-19T21:15:52Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Karl Hasselström wrote:\n>>>I added your name on the copyright since this is a new file.\n>>I did that too at first, but then I changed it back since I reckoned\n>>more than 50% of the file was copy-pasted from elsewhere. But\n>>thanks. :-)\n> By the way, it seems like my name got munged when you edited the\n> commit.\n\nI have noticed this munging happening, when I am using a UTF-8 locale.\n\nWhile we are talking about non-linear messing around with the commit\nhistory, can I request a feature?\n\nCurrently, I have a patch stack where I want the top of one of the\npatches to always be a particular revision. Consider the last revision\nto be like a \"difference\" revision (ie \"what's left\" when re-organising\na patch set).\n\nHow about a \"stg push --fudge-to c033171d...\" command for this?\n\nSam.\n"},{"id":"16457","messageId":"b0943d9e0602200920v10ef8788o@mail.gmail.com","threadId":"3286","inReplyTo":"20060219144752.GA5541@diana.vm.bytemark.co.uk","subject":"Re: [PATCH 2/2] Add 'stg uncommit' command","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2006-02-20T17:20:47Z","receivedAt":"2006-02-20T17:20:47Z","isPatch":true,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 19/02/06, Karl Hasselström wrote:\n> By the way, it seems like my name got munged when you edited the\n> commit.\n\nI fixed the escaping in the name_email* functions (I'll push it\ntonight). It was adding a \\ for every character it didn't know. It now\nonly escapes the quotes and back-slashes. This is needed when passing\nthe strings via the GIT_AUTHOR_* variables.\n\n--\nCatalin\n"},{"id":"16458","messageId":"20060220173048.GC23501@diana.vm.bytemark.co.uk","threadId":"3286","inReplyTo":"b0943d9e0602200920v10ef8788o@mail.gmail.com","subject":"Re: [PATCH 2/2] Add 'stg uncommit' command","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-02-20T17:30:48Z","receivedAt":"2006-02-20T17:30:48Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-02-20 17:20:47 +0000, Catalin Marinas wrote:\n\n> On 19/02/06, Karl Hasselström wrote:\n>\n> > By the way, it seems like my name got munged when you edited the\n> > commit.\n>\n> I fixed the escaping in the name_email* functions (I'll push it\n> tonight). It was adding a \\ for every character it didn't know. It\n> now only escapes the quotes and back-slashes. This is needed when\n> passing the strings via the GIT_AUTHOR_* variables.\n\nIt put curly braces around the name as well.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"16479","messageId":"b0943d9e0602201449j15541f8aw@mail.gmail.com","threadId":"3286","inReplyTo":"20060220173048.GC23501@diana.vm.bytemark.co.uk","subject":"Re: [PATCH 2/2] Add 'stg uncommit' command","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2006-02-20T22:49:22Z","receivedAt":"2006-02-20T22:49:22Z","isPatch":true,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 20/02/06, Karl Hasselström wrote:\n> On 2006-02-20 17:20:47 +0000, Catalin Marinas wrote:\n> > I fixed the escaping in the name_email* functions (I'll push it\n> > tonight). It was adding a \\ for every character it didn't know. It\n> > now only escapes the quotes and back-slashes. This is needed when\n> > passing the strings via the GIT_AUTHOR_* variables.\n>\n> It put curly braces around the name as well.\n\nIt wasn't StGIT. Running \"git log\" on my machine only shows \\'s and\nsome weird characters. Maybe it's your terminal showing braces.\n\n--\nCatalin\n"},{"id":"16495","messageId":"20060221075539.GA5889@diana.vm.bytemark.co.uk","threadId":"3286","inReplyTo":"b0943d9e0602201449j15541f8aw@mail.gmail.com","subject":"Re: [PATCH 2/2] Add 'stg uncommit' command","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-02-21T07:55:39Z","receivedAt":"2006-02-21T07:55:39Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-02-20 22:49:22 +0000, Catalin Marinas wrote:\n\n> On 20/02/06, Karl Hasselström wrote:\n>\n> > It put curly braces around the name as well.\n>\n> It wasn't StGIT. Running \"git log\" on my machine only shows \\'s and\n> some weird characters.\n\nThose weird characters are the two bytes that make up the character\n\"ö\" (o with two dots on top of it) in utf8. That's what the utf8\nvariant of my name looks like when displayed in latin1. :-/\n\n> Maybe it's your terminal showing braces.\n\nYou're right, they don't show when I use git-log, so I guess they\naren't really there after all. But they do show up in gitk.\n\nHopefully all this weirdness will go away with the backslashes. :-)\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"}]}