{"thread":{"id":"9368","subject":"Some ideas for StGIT","startedAt":"2007-08-03T17:50:10Z","lastAt":"2007-08-23T14:34:11Z","messageCount":32,"participants":["Pavel Roskin","Andy Parkins","Yann Dirson","Shawn O. Pearce","Theodore Tso","Chris Shoemaker","Johannes Schindelin","Josef Sipek","Jakub Narebski","Junio C Hamano","Catalin Marinas","Karl Hasselström"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"49607","messageId":"1186163410.26110.55.camel@dv","threadId":"9368","inReplyTo":null,"subject":"Some ideas for StGIT","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2007-08-03T17:50:10Z","receivedAt":"2007-08-03T17:50:10Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello!\n\nI was recently disappointed to learn that one of the Linux drivers\n(bcm43xx_mac80211, to be precise) switched from git to quilt. I asked\nwhether StGIT was considered, a discussion followed, and I think the key\npoints need to be shared with StGIT developers. I'll add some of my\nideas to the mix.\n\nThe main point in favor of quilt is that it allows to edit the patches\nwith the text editor. One can pop all patches, edit them and push the\nall back.\n\nI don't suggest that StGIT gives up on the git-based storage, but this\nmode of operation could be implemented in two ways.\n\nOne is to have a command opposite to \"export\". It would read the files\nthat \"export\" produces, replacing the existing patches.\n\nAnother approach would be to reexamine the patch after \"stg refresh -es\"\nand to apply it instead of the original patch. If the patch doesn't\napply, the options would be to discard the edits or to re-launch the\neditor.\n\nNext issue is that it should be possible to create a patch in one\noperation. StGIT follows quilt too closely here in requiring \"new\" and\n\"refresh\", instead of utilizing the advantage of the workflow that\nallows immediate editing of the sources without any commands.\n\nBasically, I want one command that:\n\n1) shows user what was changed\n2) allows user to name the patch\n3) allows user to describe the patch\n4) allows user to exclude files from the patch\n5) doesn't require another command to put the changes to the patch\n\nI think the most natural approach would be to enhance \"stg new\". I see\n\"stg new -s\" is supposed to show the changes, but it's currently broken.\nThis is run in a clean StGIT repository with no patches:\n\n$ stg new -s foo\nTraceback (most recent call last):\n File \"/home/proski/bin/stg\", line 43, in \n main()\n File \"home/proski/lib/python2.5/site-packages/stgit/main.py\", line 284, in main\n File \"/usr/lib64/python2.5/new.py\", line 82, in func\n \n File \"home/proski/lib/python2.5/site-packages/stgit/stack.py\", line 842, in new_patch\n File \"home/proski/lib/python2.5/site-packages/stgit/stack.py\", line 89, in edit_file\n File \"home/proski/lib/python2.5/site-packages/stgit/stack.py\", line 461, in get_patch\n File \"home/proski/lib/python2.5/site-packages/stgit/stack.py\", line 148, in __init__\n File \"/usr/lib64/python2.5/posixpath.py\", line 60, in join\n if b.startswith('/'):\nAttributeError: 'NoneType' object has no attribute 'startswith'\n\nAnother backtrace in \"stg new\", also run in a clean StGIT repository with no patches:\n\n$ EDITOR=true stg new todo \nInvoking the editor: \"true .stgitmsg.txt\" ... done\n$ stg export -np\nChecking for changes in the working directory ... done\nTraceback (most recent call last):\n File \"/home/proski/bin/stg\", line 43, in \n main()\n File \"home/proski/lib/python2.5/site-packages/stgit/main.py\", line 284, in main\n File \"home/proski/lib/python2.5/site-packages/stgit/commands/export.py\", line 137, in func\nAttributeError: 'NoneType' object has no attribute 'strip'\n\nFinally, it would be great to have TLS support in the mail command.\nMercurial has it, and looking at their mail.py, it doesn't seem to be\nmuch work.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"49610","messageId":"200708031914.04344.andyparkins@gmail.com","threadId":"9368","inReplyTo":"1186163410.26110.55.camel@dv","subject":"Re: Some ideas for StGIT","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-08-03T18:14:01Z","receivedAt":"2007-08-03T18:14:01Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2007, August 03, Pavel Roskin wrote:\n\n> I don't suggest that StGIT gives up on the git-based storage, but this\n> mode of operation could be implemented in two ways.\n\ngit's shiny new git rebase -i has removed, for me, those times when I needed \nstgit. Perhaps those who've move from git to quilt would try again when \n1.5.3 is out with the magic that is \"rebase -i\".\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"49640","messageId":"20070803232351.GC30277@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"9368","inReplyTo":"1186163410.26110.55.camel@dv","subject":"Re: Some ideas for StGIT","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-08-03T23:23:51Z","receivedAt":"2007-08-03T23:23:51Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Fri, Aug 03, 2007 at 01:50:10PM -0400, Pavel Roskin wrote:\n> One is to have a command opposite to \"export\". It would read the files\n> that \"export\" produces, replacing the existing patches.\n\nThis should be already possible (although I never used it), with \"stg\npop -a && stg import --replace ...\"\n\n> Another approach would be to reexamine the patch after \"stg refresh -es\"\n> and to apply it instead of the original patch. If the patch doesn't\n> apply, the options would be to discard the edits or to re-launch the\n> editor.\n\nAdded to wishes: https://gna.org/bugs/index.php?9674\n\n\n> Next issue is that it should be possible to create a patch in one\n> operation. StGIT follows quilt too closely here in requiring \"new\" and\n> \"refresh\", instead of utilizing the advantage of the workflow that\n> allows immediate editing of the sources without any commands.\n> \n> Basically, I want one command that:\n> \n> 1) shows user what was changed\n> 2) allows user to name the patch\n> 3) allows user to describe the patch\n> 4) allows user to exclude files from the patch\n> 5) doesn't require another command to put the changes to the patch\n> \n> I think the most natural approach would be to enhance \"stg new\".\n\nSure, something like this could be done. A syntax like the following\nwould IMHO fit in how things are done, but does not exactly address 4:\n\n$ stg new -m -s [--] \n\nMaybe another --exclude flag to reverse the meaning of the listed\nfiles would be a solution, but I'm not thrilled by this idea...\n\n\n> I see\n> \"stg new -s\" is supposed to show the changes, but it's currently broken.\n> This is run in a clean StGIT repository with no patches:\n> \n> $ stg new -s foo\n\nHm, I'm not sure what -s would be supposed to show here, since we're\nasking for the creation of a patch, which currently always starts\nempty.\n\nEspecially confusing is that if there are already applied patches, the\ndiff shown is the one of the previous top patch - and if there is no\napplied patches, we get the exception you noticed.\n\nI guess -s should be removed for 0.13.1.\n\n\n> Another backtrace in \"stg new\", also run in a clean StGIT repository with no patches:\n\nThis appears to occur when there is no description file, or when it is\nempty. Thanks for the report.\n\nI also tried with \"stg refresh -m ''\" to see if it caused the same\nproblem, but it appears to have another problem instead: it does not\nrefresh the patch description at all.\n\nMy guess is that we should not allow empty patch description (and\nmaybe fill it with provided patchname). What did you want to acheieve\nprecisely with that command ?\n\n\n> Finally, it would be great to have TLS support in the mail command.\n> Mercurial has it, and looking at their mail.py, it doesn't seem to be\n> much work.\n\nAdded to wishes: https://gna.org/bugs/index.php?9673\n\nThanks,\n-- \nYann\n"},{"id":"49664","messageId":"1186206085.28481.33.camel@dv","threadId":"9368","inReplyTo":"200708031914.04344.andyparkins@gmail.com","subject":"Re: Some ideas for StGIT","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2007-08-04T05:41:25Z","receivedAt":"2007-08-04T05:41:25Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello, Andy!\n\nOn Fri, 2007-08-03 at 19:14 +0100, Andy Parkins wrote:\n> On Friday 2007, August 03, Pavel Roskin wrote:\n> \n> > I don't suggest that StGIT gives up on the git-based storage, but this\n> > mode of operation could be implemented in two ways.\n> \n> git's shiny new git rebase -i has removed, for me, those times when I needed \n> stgit. Perhaps those who've move from git to quilt would try again when \n> 1.5.3 is out with the magic that is \"rebase -i\".\n\nI don't understand how one option can replace StGIT. I assume you were\ntrying to avoid StGIT already, and \"git-rebase -i\" was just the last\nmissing piece.\n\nIt would be great if you could tell me how your approach would deal with\nthe issue of editable patches I mentioned already. In case I was\nunclear, here's the quote from one of the developers:\n\n[quote]\nSometimes, I just make patches in quilt, then I do \"quilt \nrefresh\", \"quilt pop -a\", \"cd patches\" and modify the patches \nand series file manually, e.g. by moving one patch from one file \ninto the other. The \"cd ..\", \"quilt push -a\" and off I am. That \nthe \"database\" of quilt is in a known format and I can hack on \nit with an editor is a plus for me :-)\n[end of quote]\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"49667","messageId":"20070804055110.GP20052@spearce.org","threadId":"9368","inReplyTo":"1186206085.28481.33.camel@dv","subject":"Re: Some ideas for StGIT","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-08-04T05:51:11Z","receivedAt":"2007-08-04T05:51:11Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Pavel Roskin wrote:\n> \n> On Fri, 2007-08-03 at 19:14 +0100, Andy Parkins wrote:\n> > On Friday 2007, August 03, Pavel Roskin wrote:\n> > \n> > > I don't suggest that StGIT gives up on the git-based storage, but this\n> > > mode of operation could be implemented in two ways.\n> > \n> > git's shiny new git rebase -i has removed, for me, those times when I needed \n> > stgit. Perhaps those who've move from git to quilt would try again when \n> > 1.5.3 is out with the magic that is \"rebase -i\".\n\nI agree with Andy. Aside from the performance issues that I\nam currently having with a 55 patch series, \"rebase -i\" (and its\npredecessor script from Dscho) have been a major part of my toolkit,\nto the point that I really don't need something like StGIT on\nmy system.\n\n(Regarding the performance, cherry-picking 55 patches is\nslow, especially when many of them would apply trivially with\ngit-diff|git-apply --index. Be nice to improve that in 1.5.4.)\n \n> I don't understand how one option can replace StGIT. I assume you were\n> trying to avoid StGIT already, and \"git-rebase -i\" was just the last\n> missing piece.\n\nOh, I'm sure there's features in StGIT that are useful that aren't\navailable via \"rebase -i\". But to be honest, \"rebase -i\" is good\nenough. It just ain't fast enough. Editing a patch that is 50\nback in the series *sucks*.\n \n> It would be great if you could tell me how your approach would deal with\n> the issue of editable patches I mentioned already. In case I was\n> unclear, here's the quote from one of the developers:\n> \n> [quote]\n> Sometimes, I just make patches in quilt, then I do \"quilt \n> refresh\", \"quilt pop -a\", \"cd patches\" and modify the patches \n> and series file manually, e.g. by moving one patch from one file \n> into the other. The \"cd ..\", \"quilt push -a\" and off I am. That \n> the \"database\" of quilt is in a known format and I can hack on \n> it with an editor is a plus for me :-)\n> [end of quote]\n\nUh, the \"database\" of \"rebase -i\" is just a chain of commits in a\ngit repository. These are a well known format and can be easily\nedited with \"rebase -i\". This is a real plus for me as the series\ncan be edited directly in my favorite vi clone, then applied to my\nworking directory. ;-)\n\n-- \nShawn.\n"},{"id":"49673","messageId":"20070804063858.GA13758@thunk.org","threadId":"9368","inReplyTo":"1186163410.26110.55.camel@dv","subject":"Re: Some ideas for StGIT","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-08-04T06:38:58Z","receivedAt":"2007-08-04T06:38:58Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Fri, Aug 03, 2007 at 01:50:10PM -0400, Pavel Roskin wrote:\n> Hello!\n> \n> I was recently disappointed to learn that one of the Linux drivers\n> (bcm43xx_mac80211, to be precise) switched from git to quilt. I asked\n> whether StGIT was considered, a discussion followed, and I think the key\n> points need to be shared with StGIT developers. I'll add some of my\n> ideas to the mix.\n\nYou might also ask them if they considered \"guilt\", which uses\ntext-based patches. It's a lot easier to use, and if they really want\nquilt-like functionality, \"guilt\" will provide it.\n\nMy main reason for avoiding StGIT is the fact that at least in the\npast, I've found it very fragile when I forget and use \"git checkout\"\ninstead of \"stg branch\" to switch between branches. The fact that\nsometimes you have to use the StGit variant of basic git commands has\nalways struck me as confusing, and then recovering when things get\nscrewed can be exciting. Usually it's when I start having to cut and\npaste SHA1 hashes and running diffs to recreate my patch series after\nthings get screwed is usually about the time when I wonder why I tried\nusing StGIT again. (Don't get me wrong; I'm sure I did something\nreally stupid, and wrong, that caused things to get screwed up. My\ncomplaint is that when I do something stupid, StGIT isn't robust and\nis painful to recover from.)\n\nThat's why I like guilt; it doesn't require that you use alternate stg\ncommands for manipulating branches, and since it maintains an external\nset of text patches, recovering is much easier; worst case I can just\ndo a \"git reset --hard\" and then follow it up with a guilt push -a.\nAnd because it's so stupid simple, it's much rarer that something goes\nseriously wrong that requires me to use a recovery procedure in the\nfirst place.\n\nEditing patch headers are also a lot easier with guilt; you can just\ngo ahead and edit them all, and then you can fresh them in git by\ndoing a \"guilt pop -a; guilt push -a\". Since it's not using a\ngit-based storage, it doesn't have to rewrite the whole patch stack\nwhen you modify a single patch header; you can edit a whole bunch of\ntext headers and then refresh the git commit series just once.\n\nOf course, that's just my preference; others may find StGIT more\nconvenient, or folks may find the new rebase -i to be better yet.\nYMMV.\n\n \t \t\t \t \t- Ted\n"},{"id":"49685","messageId":"20070804080801.GD30277@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"9368","inReplyTo":"1186206085.28481.33.camel@dv","subject":"Re: Some ideas for StGIT","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-08-04T08:08:01Z","receivedAt":"2007-08-04T08:08:01Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Sat, Aug 04, 2007 at 01:41:25AM -0400, Pavel Roskin wrote:\n> [quote]\n> Sometimes, I just make patches in quilt, then I do \"quilt \n> refresh\", \"quilt pop -a\", \"cd patches\" and modify the patches \n> and series file manually, e.g. by moving one patch from one file \n> into the other.\n> [end of quote]\n\nFWIW, I have written a couple of scripts to help moving stuff around\nbetween patches. Those are not yet integrated in stgit proper, and it\nhappens that the 0.13 tarball does not contain them, they are only\navailable from the git tree (better use my tree[1], since I updated them\nrecently).\n\nMost notably relevant to this use are stg-fold-files-from and\nstg-dispatch, to move diff hunks between patches. They only cases\n(off the top of my hand) where they do not fit my needs are:\n - when I need to move a part of a diff hunk that is not possible to\n isolate using -U (but I have read interesting things about git-gui\n for such functionnality, so that will surely come one day)\n - when I need to move git-specific diff hunks (moves, permissions,\n etc.), since it uses filterdiff, which is not git-aware (yet ?)\n\n(in short, there are lots of dev to do in/around stgit, but there are\nnot as many contributors as there is for git - hint, hint ;)\n\nIf there are other typical situations where they need to edit patches,\nI'd be interested to hear about them. Not to avoid implementing patch\nedition in stgit, since it is occasionally useful to fix a typo when\nreviewing at refresh time, but to see what higher-level tools we could\nprovide.\n\nBest regards,\n-- \nYann\n\n[1] gitweb at http://repo.or.cz/w/stgit/ydirson.git\n"},{"id":"49686","messageId":"20070804081616.GE30277@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"9368","inReplyTo":"20070804063858.GA13758@thunk.org","subject":"Re: Some ideas for StGIT","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-08-04T08:16:16Z","receivedAt":"2007-08-04T08:16:16Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Sat, Aug 04, 2007 at 02:38:58AM -0400, Theodore Tso wrote:\n> My main reason for avoiding StGIT is the fact that at least in the\n> past, I've found it very fragile when I forget and use \"git checkout\"\n> instead of \"stg branch\" to switch between branches.\n\nFWIW, I exclusively use git-checkout to switch between git branches\nand stgit stacks, and it works like a charm. I don't remember ever\nseeing a problem with this, so I guess it has been fixed for a long\ntime.\n\nBut yes, there are still robustness issues with stgit. It looks like\nthe user base is small, since there are not so many bugreports. We\ntend to take care about the workfows we use, and people with other\nworkflows obviously should tell us what gets wrong :)\n\nBest regards,\n-- \nYann\n"},{"id":"49725","messageId":"20070804141438.GA15821@pe.Belkin","threadId":"9368","inReplyTo":"1186206085.28481.33.camel@dv","subject":"Re: Some ideas for StGIT","fromName":"Chris Shoemaker","fromEmail":"c.shoemaker@cox.net","sentAt":"2007-08-04T14:14:38Z","receivedAt":"2007-08-04T14:14:38Z","isPatch":false,"sender":{"key":"c.shoemaker@cox.net","avatar":null},"body":"On Sat, Aug 04, 2007 at 01:41:25AM -0400, Pavel Roskin wrote:\n> Hello, Andy!\n> \n> On Fri, 2007-08-03 at 19:14 +0100, Andy Parkins wrote:\n> > On Friday 2007, August 03, Pavel Roskin wrote:\n> > \n> > > I don't suggest that StGIT gives up on the git-based storage, but this\n> > > mode of operation could be implemented in two ways.\n> > \n> > git's shiny new git rebase -i has removed, for me, those times when I needed \n> > stgit. Perhaps those who've move from git to quilt would try again when \n> > 1.5.3 is out with the magic that is \"rebase -i\".\n> \n> I don't understand how one option can replace StGIT. I assume you were\n> trying to avoid StGIT already, and \"git-rebase -i\" was just the last\n> missing piece.\n\nFWIW, I'm in the same camp. I'm a huge fan of quilt, and used it\nextensively and with large stacks. (Actually, I still use it whenever\nI don't want to bother with importing-to-git a large CVS or SVN\nproject that I'm tracking.) When I started using git (and up until\nthe first time I used git-rebase -i), I assumed I'd eventually have to\nuse one of the quilt-like add-ons, but I wanted to hold off a little\nwhile until I was comfortable with core-git.\n\nBut, after using git-rebase -i, I can't see why I'd need any\nquilt-like add-on. Every time I use git-rebase -i, it's like I'm\nediting the patch stack.\n\n> It would be great if you could tell me how your approach would deal with\n> the issue of editable patches I mentioned already. In case I was\n> unclear, here's the quote from one of the developers:\n> \n> [quote]\n> Sometimes, I just make patches in quilt, then I do \"quilt \n> refresh\", \"quilt pop -a\", \"cd patches\" and modify the patches \n> and series file manually, e.g. by moving one patch from one file \n> into the other. \n\nWell, there are many different ways one might want to modify the\nstack, but I find that most of them are quite easy with git-rebase -i.\nIMO, here are things that are easier with git-rebase -i than with an\nexternal patch stack:\n\n - editing the headers (git-rebase makes it easy to find/select the\n patch and even opens the editor for me)\n - reordering patches\n - combining patches (squashing)\n - moving one file's diff from one patch to another\n\nIMO, here are some things that would probably be easier with an external\npatch stack:\n\n - directly editing the diff hunks\n - moving single diff hunks between patches\n\nMaybe there are others, too, but these are things I just don't do\nnearly as frequently as the things that git-rebase -i is good at. (I\nuse git-rebase -i *constantly*).\n\n> The \"cd ..\", \"quilt push -a\" and off I am. That \n> the \"database\" of quilt is in a known format and I can hack on \n> it with an editor is a plus for me :-)\n> [end of quote]\n\nThat sounds more like an argument from familiarity than anything else.\nNobody (reasonable) directly hacks git's internal binary format. The\n\"known format\" I can hack with my editor is just the content itself.\nHonestly, when you have commit-handling that is as good as git's,\nthere's really very little appeal left to editing the diffs directly.\n\n-chris\n"},{"id":"49738","messageId":"Pine.LNX.4.64.0708041618291.14781@racer.site","threadId":"9368","inReplyTo":"20070804141438.GA15821@pe.Belkin","subject":"Re: Some ideas for StGIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-04T15:22:36Z","receivedAt":"2007-08-04T15:22:36Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 4 Aug 2007, Chris Shoemaker wrote:\n\n> IMO, here are some things that would probably be easier with an external\n> patch stack:\n> \n> - directly editing the diff hunks\n> - moving single diff hunks between patches\n> \n> Maybe there are others, too, but these are things I just don't do\n> nearly as frequently as the things that git-rebase -i is good at. (I\n> use git-rebase -i *constantly*).\n\nGood to hear! (I almost missed this mail, since I usually skip the StGit \nmails.)\n\n> > The \"cd ..\", \"quilt push -a\" and off I am. That \n> > the \"database\" of quilt is in a known format and I can hack on \n> > it with an editor is a plus for me :-)\n> > [end of quote]\n> \n> That sounds more like an argument from familiarity than anything else.\n> Nobody (reasonable) directly hacks git's internal binary format. The\n> \"known format\" I can hack with my editor is just the content itself.\n> Honestly, when you have commit-handling that is as good as git's,\n> there's really very little appeal left to editing the diffs directly.\n\nOf course, you _could_ just export the patches as one mbox, edit them, and \nreapply them:\n\n\tgit format-patch --stdout HEAD~4 > mbox.txt\n\t$EDITOR mbox.txt # even moving hunks\n\tgit reset --hard HEAD~4\n\tgit am mbox.txt\n\nIf the need is great enough, it should be easy to hack something like this \ninto git rebase -i.\n\nCiao,\nDscho\n"},{"id":"49783","messageId":"20070804213549.GA1967@filer.fsl.cs.sunysb.edu","threadId":"9368","inReplyTo":"20070804063858.GA13758@thunk.org","subject":"Re: Some ideas for StGIT","fromName":"Josef Sipek","fromEmail":"jsipek@fsl.cs.sunysb.edu","sentAt":"2007-08-04T21:35:49Z","receivedAt":"2007-08-04T21:35:49Z","isPatch":false,"sender":{"key":"jsipek@fsl.cs.sunysb.edu","avatar":null},"body":"On Sat, Aug 04, 2007 at 02:38:58AM -0400, Theodore Tso wrote:\n> On Fri, Aug 03, 2007 at 01:50:10PM -0400, Pavel Roskin wrote:\n> > Hello!\n> > \n> > I was recently disappointed to learn that one of the Linux drivers\n> > (bcm43xx_mac80211, to be precise) switched from git to quilt. I asked\n> > whether StGIT was considered, a discussion followed, and I think the key\n> > points need to be shared with StGIT developers. I'll add some of my\n> > ideas to the mix.\n> \n> You might also ask them if they considered \"guilt\", which uses\n> text-based patches. It's a lot easier to use, and if they really want\n> quilt-like functionality, \"guilt\" will provide it.\n \nI guess I should chime in.\n\nThe goal behind guilt is to be very simple yet powerful enough to do what is\nnecessary to maintain a piece of kernel code (read: to scratch my own itch).\n\n> And because it's so stupid simple, it's much rarer that something goes\n> seriously wrong that requires me to use a recovery procedure in the\n> first place.\n\nThanks! :)\n\n> Editing patch headers are also a lot easier with guilt; you can just\n> go ahead and edit them all, and then you can fresh them in git by\n> doing a \"guilt pop -a; guilt push -a\". Since it's not using a\n> git-based storage, it doesn't have to rewrite the whole patch stack\n> when you modify a single patch header; you can edit a whole bunch of\n> text headers and then refresh the git commit series just once.\n\nFYI: v0.27 allows you to edit the patch headers with: guilt header -e\n\nPavel, if you have any questions, you know where to ask :)\n\nJosef 'Jeff' Sipek.\n\n-- \nDon't drink and derive. Alcohol and algebra don't mix.\n"},{"id":"49792","messageId":"1186272503.1948.21.camel@dv","threadId":"9368","inReplyTo":"20070804055110.GP20052@spearce.org","subject":"Re: Some ideas for StGIT","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2007-08-05T00:08:23Z","receivedAt":"2007-08-05T00:08:23Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Sat, 2007-08-04 at 01:51 -0400, Shawn O. Pearce wrote:\n\n> I agree with Andy. Aside from the performance issues that I\n> am currently having with a 55 patch series, \"rebase -i\" (and its\n> predecessor script from Dscho) have been a major part of my toolkit,\n> to the point that I really don't need something like StGIT on\n> my system.\n> \n> (Regarding the performance, cherry-picking 55 patches is\n> slow, especially when many of them would apply trivially with\n> git-diff|git-apply --index. Be nice to improve that in 1.5.4.)\n\nI understand that \"git-rebase -i\" is good for keeping local changes\nup-to-date, but the real issue is managing the local patches so that\nthey can be enhanced to the point that they are ready for submission.\n\nThat includes such things as moving chunks between patches, editing\ndescriptions, joining patches together, sorting patches into groups by\ntheir urgency and so on. Keeping the patches up-to-date is just one\naspect.\n\nAnyway, I'm going to give \"git-rebase -i\" a try.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"49793","messageId":"1186272754.1948.24.camel@dv","threadId":"9368","inReplyTo":"20070804213549.GA1967@filer.fsl.cs.sunysb.edu","subject":"Re: Some ideas for StGIT","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2007-08-05T00:12:34Z","receivedAt":"2007-08-05T00:12:34Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Sat, 2007-08-04 at 17:35 -0400, Josef Sipek wrote:\n\n> FYI: v0.27 allows you to edit the patch headers with: guilt header -e\n\n> Pavel, if you have any questions, you know where to ask :)\n\nThanks everybody. guilt and \"git-rebase -i\" are on my list of things to\ntry.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"49794","messageId":"f934ve$3oi$1@sea.gmane.org","threadId":"9368","inReplyTo":"20070804055110.GP20052@spearce.org","subject":"Re: Some ideas for StGIT","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-08-05T00:17:50Z","receivedAt":"2007-08-05T00:17:50Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Shawn O. Pearce wrote:\n\n> (Regarding the performance, cherry-picking 55 patches is\n> slow, especially when many of them would apply trivially with\n> git-diff|git-apply --index.  Be nice to improve that in 1.5.4.)\n\nPerhaps in the future you would be able to use -i/--interactive mode\nin merge driven git-rebase (git rebase --merge -i ), which I think\nshould be faster.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"49796","messageId":"20070805023130.GV20052@spearce.org","threadId":"9368","inReplyTo":"f934ve$3oi$1@sea.gmane.org","subject":"Re: Some ideas for StGIT","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-08-05T02:31:30Z","receivedAt":"2007-08-05T02:31:30Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jakub Narebski wrote:\n> Shawn O. Pearce wrote:\n> \n> > (Regarding the performance, cherry-picking 55 patches is\n> > slow, especially when many of them would apply trivially with\n> > git-diff|git-apply --index.  Be nice to improve that in 1.5.4.)\n> \n> Perhaps in the future you would be able to use -i/--interactive mode\n> in merge driven git-rebase (git rebase --merge -i ), which I think\n> should be faster.\n\nHeh. You're talking to someone who actually knows what he is talking\nabout here, and was actually involved in some of these tools...\nLet me fill the reader in on what's really happening...\n\n`git-rebase` (non -i, non -m) uses `format-patch|am` to apply the\nchanges of each commit it is rebasing. This is insanely fast as\nbuiltin diff and apply routines are quite efficient. It sometimes\nfails due to patches not applying cleanly. In those cases you\nhave to either hand edit the patch, apply and continue the rebase,\nor abort the rebase and restart with the -m flag so it uses a full\nthree-way file merge.\n\n`git-rebase -m` (aka --merge) uses git-merge-recursive to apply the\nchanges of each commit it is rebasing. (That's the merge part!)\nHowever merge-recursive usually takes longer to run then the above\n`format-patch|am` pipeline, and that is why -m is not the default.\nBut it does handle cases `format-patch|am` cannot do automatically.\n\nFor quite a long time now both `git-revert` and `git-cherry-pick`\n(which are actually the same program!) have also been using\ngit-merge-recursive as their implementation to revert or apply the\ncommit's change. This allows them to perform changes that also\ninvolve renames, as well as to apply some changes that might fail\nas a patch but succeed when done as a three-way file merge.\n\nSo really `revert`, `cherry-pick`, `rebase -m` (and also `am -3`\nas it also uses merge-recursive) are all the same underlying\nimplementation. The major differences between them is what they\ndo *after* the changes have been applied, and which direction the\nchange goes (e.g. revert undoes the change).\n\nNow the new `git-rebase -i` is really just a complicated loop around\n`cherry-pick`. Really. Go look at the code, it never calls anything\nexcept cherry-pick. So `rebase -i` is actually `rebase --merge -i`.\nThat's why its sluggish.\n\nWhy is merge-recursive sluggish? It does rename detection.\nIt does full three-way file merges, rather than just applying\na patch. It also tries to do a three-way read-tree before doing\nfile level merges. git-apply does none of these things, and is\nfaster because of it.\n\nSo that future you speak of above is today. Its also not faster,\nits slower. Faster would be to do something like `format-patch|am -3`\nso that merge-recursive is only invoked if git-apply was unable to\napply the patch automatically. Except we'd want to save the original\ntree data so we can do proper rename detection when merge-recursive\nis fired up.\n\n-- \nShawn.\n"},{"id":"49798","messageId":"7vodhmirl9.fsf@assigned-by-dhcp.cox.net","threadId":"9368","inReplyTo":"20070805023130.GV20052@spearce.org","subject":"Re: Some ideas for StGIT","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-05T03:32:34Z","receivedAt":"2007-08-05T03:32:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> So really `revert`, `cherry-pick`, `rebase -m` (and also `am -3`\n> as it also uses merge-recursive) are all the same underlying\n> implementation.\n\nMinor factual correction. \"am -3\" uses merge-recursive *ONLY*\nwhen patch does not apply, so it is often the best of both\nworlds, as long as your changes do not involve renames. And\nthat is what the default rebase uses.\n"},{"id":"49887","messageId":"20070805133940.GA18835@filer.fsl.cs.sunysb.edu","threadId":"9368","inReplyTo":"20070805023130.GV20052@spearce.org","subject":"Re: Some ideas for StGIT","fromName":"Josef Sipek","fromEmail":"jsipek@fsl.cs.sunysb.edu","sentAt":"2007-08-05T13:39:40Z","receivedAt":"2007-08-05T13:39:40Z","isPatch":false,"sender":{"key":"jsipek@fsl.cs.sunysb.edu","avatar":null},"body":"On Sat, Aug 04, 2007 at 10:31:30PM -0400, Shawn O. Pearce wrote:\n...\n[rebase is complex but fun]\n\nGreat, but does git have something that could replace\n$QUILT_LIKE_APP refresh?\n\nSure, if you can take 2 commits and collapse them into one you could fake it\nby creating a dummy commit with the new changes, and then collapsing, but\nthat's nasty - and reflog might not like that much :)\n\nJosef 'Jeff' Sipek.\n\n-- \nI'm somewhere between geek and normal.\n\t\t- Linus Torvalds\n"},{"id":"49891","messageId":"Pine.LNX.4.64.0708051452280.14781@racer.site","threadId":"9368","inReplyTo":"20070805133940.GA18835@filer.fsl.cs.sunysb.edu","subject":"Re: Some ideas for StGIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-05T13:56:23Z","receivedAt":"2007-08-05T13:56:23Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 5 Aug 2007, Josef Sipek wrote:\n\n> On Sat, Aug 04, 2007 at 10:31:30PM -0400, Shawn O. Pearce wrote:\n> ...\n> [rebase is complex but fun]\n> \n> Great, but does git have something that could replace\n> $QUILT_LIKE_APP refresh?\n\nWhat does \"refresh\"? (I never used quilt, and probably never will, since \nrebase -i does what I need.)\n\n> Sure, if you can take 2 commits and collapse them into one you could \n> fake it by creating a dummy commit with the new changes, and then \n> collapsing, but that's nasty - and reflog might not like that much :)\n\nIIUC you want to edit/amend a patch in the middle of a series? Two ways \nto go about it:\n\n\t1) (preferred)\n\n\t\t* start rebase -i\n\t\t* mark the commit as \"edit\"\n\t\t* wait until rebase stops to let you edit it\n\t\t* edit, test, commit --amend\n\t\t* rebase --continue\n\n\t2) (not so preferred, but often convenient)\n\n\t\t* fix bug\n\t\t* commit with a dummy message\n\t\t* rebase -i\n\t\t* move commit just after the commit-to-edit\n\t\t* mark second as \"squash\"\n\t\t* when the editor comes up, just delete the second \n\t\t commit's message, and possibly adjust the first's\n\nHth,\nDscho\n"},{"id":"49893","messageId":"20070805140658.GA4570@filer.fsl.cs.sunysb.edu","threadId":"9368","inReplyTo":"Pine.LNX.4.64.0708051452280.14781@racer.site","subject":"Re: Some ideas for StGIT","fromName":"Josef Sipek","fromEmail":"jsipek@fsl.cs.sunysb.edu","sentAt":"2007-08-05T14:06:58Z","receivedAt":"2007-08-05T14:06:58Z","isPatch":false,"sender":{"key":"jsipek@fsl.cs.sunysb.edu","avatar":null},"body":"On Sun, Aug 05, 2007 at 02:56:23PM +0100, Johannes Schindelin wrote:\n> Hi,\n> \n> On Sun, 5 Aug 2007, Josef Sipek wrote:\n> \n> > On Sat, Aug 04, 2007 at 10:31:30PM -0400, Shawn O. Pearce wrote:\n> > ...\n> > [rebase is complex but fun]\n> > \n> > Great, but does git have something that could replace\n> > $QUILT_LIKE_APP refresh?\n> \n> What does \"refresh\"? (I never used quilt, and probably never will, since \n> rebase -i does what I need.)\n\nYou understood correctly...see below.\n\n> > Sure, if you can take 2 commits and collapse them into one you could \n> > fake it by creating a dummy commit with the new changes, and then \n> > collapsing, but that's nasty - and reflog might not like that much :)\n> \n> IIUC you want to edit/amend a patch in the middle of a series? Two ways \n> to go about it:\n> \n> \t1) (preferred)\n> \n> \t\t* start rebase -i\n> \t\t* mark the commit as \"edit\"\n> \t\t* wait until rebase stops to let you edit it\n> \t\t* edit, test, commit --amend\n> \t\t* rebase --continue\n\nEwww...that doesn't seem to scale (read: far too much to type) :) Here's a\nquilt/guilt/stgit equivalent:\n\n\t$APP push \n\nor (depending on where you are in the patch stack)\n\n\t$APP pop \n\n\t\n\n\t$APP refresh # this is the commit --amend part\n\nJosef 'Jeff' Sipek.\n\n-- \nThe reasonable man adapts himself to the world; the unreasonable one\npersists in trying to adapt the world to himself. Therefore all progress\ndepends on the unreasonable man.\n\t\t- George Bernard Shaw\n"},{"id":"49894","messageId":"Pine.LNX.4.64.0708051513310.14781@racer.site","threadId":"9368","inReplyTo":"20070805140658.GA4570@filer.fsl.cs.sunysb.edu","subject":"Re: Some ideas for StGIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-05T14:15:29Z","receivedAt":"2007-08-05T14:15:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 5 Aug 2007, Josef Sipek wrote:\n\n> On Sun, Aug 05, 2007 at 02:56:23PM +0100, Johannes Schindelin wrote:\n> > \n> > On Sun, 5 Aug 2007, Josef Sipek wrote:\n> > \n> > > Sure, if you can take 2 commits and collapse them into one you could \n> > > fake it by creating a dummy commit with the new changes, and then \n> > > collapsing, but that's nasty - and reflog might not like that much \n> > > :)\n> > \n> > IIUC you want to edit/amend a patch in the middle of a series? Two ways \n> > to go about it:\n> > \n> > \t1) (preferred)\n> > \n> > \t\t* start rebase -i\n> > \t\t* mark the commit as \"edit\"\n> > \t\t* wait until rebase stops to let you edit it\n> > \t\t* edit, test, commit --amend\n> > \t\t* rebase --continue\n> \n> Ewww...that doesn't seem to scale (read: far too much to type) :) Here's a\n> quilt/guilt/stgit equivalent:\n> \n> \t$APP push \n> \n> or (depending on where you are in the patch stack)\n> \n> \t$APP pop \n> \n> \t\n> \n> \t$APP refresh # this is the commit --amend part\n\nYeah. Sounds like you'd just need a \"--edit-this $commit\" flag to rebase \n-i.\n\nOut of curiousity, what happens if you say \"push\" several times, \n_without_ popping the patch? And what happens if you \"push\" several times \nwith the _same_ patchname?\n\nCiao,\nDscho\n"},{"id":"49900","messageId":"20070805145712.GB4570@filer.fsl.cs.sunysb.edu","threadId":"9368","inReplyTo":"Pine.LNX.4.64.0708051513310.14781@racer.site","subject":"Re: Some ideas for StGIT","fromName":"Josef Sipek","fromEmail":"jsipek@fsl.cs.sunysb.edu","sentAt":"2007-08-05T14:57:12Z","receivedAt":"2007-08-05T14:57:12Z","isPatch":false,"sender":{"key":"jsipek@fsl.cs.sunysb.edu","avatar":null},"body":"On Sun, Aug 05, 2007 at 03:15:29PM +0100, Johannes Schindelin wrote:\n> Hi,\n> \n> On Sun, 5 Aug 2007, Josef Sipek wrote:\n> \n> > On Sun, Aug 05, 2007 at 02:56:23PM +0100, Johannes Schindelin wrote:\n> > > \n> > > On Sun, 5 Aug 2007, Josef Sipek wrote:\n> > > \n> > > > Sure, if you can take 2 commits and collapse them into one you could \n> > > > fake it by creating a dummy commit with the new changes, and then \n> > > > collapsing, but that's nasty - and reflog might not like that much \n> > > > :)\n> > > \n> > > IIUC you want to edit/amend a patch in the middle of a series? Two ways \n> > > to go about it:\n> > > \n> > > \t1) (preferred)\n> > > \n> > > \t\t* start rebase -i\n> > > \t\t* mark the commit as \"edit\"\n> > > \t\t* wait until rebase stops to let you edit it\n> > > \t\t* edit, test, commit --amend\n> > > \t\t* rebase --continue\n> > \n> > Ewww...that doesn't seem to scale (read: far too much to type) :) Here's a\n> > quilt/guilt/stgit equivalent:\n> > \n> > \t$APP push \n> > \n> > or (depending on where you are in the patch stack)\n> > \n> > \t$APP pop \n> > \n> > \t\n> > \n> > \t$APP refresh # this is the commit --amend part\n> \n> Yeah. Sounds like you'd just need a \"--edit-this $commit\" flag to rebase \n> -i.\n\nStill, very inconvenient (IMO) when you are working _on_ lots of patches.\n\n> Out of curiousity, what happens if you say \"push\" several times, \n> _without_ popping the patch? And what happens if you \"push\" several times \n> with the _same_ patchname?\n\nIn addition to the patches, there's also ordering information for those\npatches (the series file) - in the simplest case it is a stack in the\ntraditinal Comp Sci meaning. IOW, if you have patches {foo,bar,baz} and you\nwant to push \"bar\", the patch \"foo\" will also get pushed. When you push a\npatch, the software makes note of the fact (status file in Guilt).\n\nIf you try to push the same patch twice, it'll tell you that the patch is\nalready applied. The Mercurial Book has a section about Mercurial Queues\n(Mercurial's implementation of something similar to Guilt/stgit) which\ndescribes the concepts rather well [1]. I think that figure 12.10 [2] really\nexplains the whole thing pretty well. Of course, there is always the quilt\ndoc (big PDF which has the whole history, etc., etc.).\n\nHrm, it just occured to me that the quilt-way of managing patches is the\nbasic concept of a turing machine - infinite tape which is seekable and you\ncan read/write to the \"current\" position (topmost applied patch). :)\n\nJosef 'Jeff' Sipek.\n\n[1] http://hgbook.red-bean.com/hgbookch12.html#x16-27200012.5\n[2] http://hgbook.red-bean.com/hgbookch12.html#x16-27600310\n\n-- \nComputer Science is no more about computers than astronomy is about\ntelescopes.\n\t\t- Edsger Dijkstra\n"},{"id":"49999","messageId":"b0943d9e0708060236x19674e4cjf04cec716ae6246c@mail.gmail.com","threadId":"9368","inReplyTo":"1186163410.26110.55.camel@dv","subject":"Re: Some ideas for StGIT","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-08-06T09:36:25Z","receivedAt":"2007-08-06T09:36:25Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Hi Pavel,\n\nAll the interesting discussion usually happen during my holidays :-).\n\nOn 03/08/2007, Pavel Roskin wrote:\n> I was recently disappointed to learn that one of the Linux drivers\n> (bcm43xx_mac80211, to be precise) switched from git to quilt. I asked\n> whether StGIT was considered, a discussion followed, and I think the key\n> points need to be shared with StGIT developers. I'll add some of my\n> ideas to the mix.\n\nThanks for the feedback.\n\n> The main point in favor of quilt is that it allows to edit the patches\n> with the text editor. One can pop all patches, edit them and push the\n> all back.\n\nIf this is the main feature they need, they probably don't need git at\nall and quilt would be enough. I was using quilt before starting StGIT\nbut the main problem I had with plain patches approach was the\nconflict solving.\n\nStGIT does a 'git-diff | git-apply' as a patch push optimization and\nwe could even cache the diff but the current algorithm is that if\ngit-apply fails, StGIT falls back to a three-way merge and even an\ninteractive user merge (via xxdiff for example). I find the three-way\nmerging (automatic or interactive) much more powerful than fuzzy patch\napplication.\n\nIf we would allow patch editing, the 'stg push' algorithms wouldn't\nknow when git-apply failed because the patch was edited or the base\nwas changed. Falling back to the three-way merge would lose the edited\npatch. If one doesn't need three-way merging, quilt is good enough.\n\nOther advantages of the three-way merging is the detection of full\npatches or hunks merged upstream (the former can also be achieved by\ntesting the reverse-application of the patches).\n\nI don't usually edit patches during development, I prefer to edit the\nsource files and review the diff. It happens many times to move hunks\nbetween patches but I usually towards the bottom patches in the stack\n(using stg export and emacs) and the three-way merging automatically\nremoves the merged hunks from top patches.\n\n> I don't suggest that StGIT gives up on the git-based storage, but this\n> mode of operation could be implemented in two ways.\n>\n> One is to have a command opposite to \"export\". It would read the files\n> that \"export\" produces, replacing the existing patches.\n\nAs Yann said, we already have 'stg import --replace'. I mainly use\nthis feature with series sent to me and when they need some editing to\napply cleanly. There is also 'stg import --ignore' to ignore the\npatches already applied (mainly when the importing fails in the middle\nof a series, there is no need to re-import the first patches).\n\n> Another approach would be to reexamine the patch after \"stg refresh -es\"\n> and to apply it instead of the original patch. If the patch doesn't\n> apply, the options would be to discard the edits or to re-launch the\n> editor.\n\nThat's an interesting idea but maybe we should have a separate command\nlike --edit-full to edit the full patch + log (part of the\nfunctionality already available in import).\n\n> Next issue is that it should be possible to create a patch in one\n> operation. StGIT follows quilt too closely here in requiring \"new\" and\n> \"refresh\", instead of utilizing the advantage of the workflow that\n> allows immediate editing of the sources without any commands.\n>\n> Basically, I want one command that:\n>\n> 1) shows user what was changed\n> 2) allows user to name the patch\n> 3) allows user to describe the patch\n> 4) allows user to exclude files from the patch\n> 5) doesn't require another command to put the changes to the patch\n>\n> I think the most natural approach would be to enhance \"stg new\". I see\n> \"stg new -s\" is supposed to show the changes, but it's currently broken.\n\nThanks for reporting this. I don't use the --showpatch options much\nand we don't have any tests (yet) for the interactive options.\n\n> Finally, it would be great to have TLS support in the mail command.\n> Mercurial has it, and looking at their mail.py, it doesn't seem to be\n> much work.\n\nIndeed, the SMTP Python objects already provide support for TLS via starttls().\n\n-- \nCatalin\n"},{"id":"50003","messageId":"b0943d9e0708060249h4a3f59bobfac8f9014aca82f@mail.gmail.com","threadId":"9368","inReplyTo":"20070803232351.GC30277@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Some ideas for StGIT","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-08-06T09:49:21Z","receivedAt":"2007-08-06T09:49:21Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 04/08/2007, Yann Dirson wrote:\n> On Fri, Aug 03, 2007 at 01:50:10PM -0400, Pavel Roskin wrote:\n> > I see\n> > \"stg new -s\" is supposed to show the changes, but it's currently broken.\n> > This is run in a clean StGIT repository with no patches:\n> >\n> > $ stg new -s foo\n>\n> Hm, I'm not sure what -s would be supposed to show here, since we're\n> asking for the creation of a patch, which currently always starts\n> empty.\n\nThe story for the 'new -s' option was that with StGIT (not possible\nwith Quilt), one can start modifying the local tree and only create a\npatch afterwards. The newly created patch is always empty, even if\nthere were local changes and showing them was useful for writing the\npatch description. One can use refresh for checking the changes in.\nIndeed, the 'new' command can be improved to have part of the\n'refresh' functionality, though I don't really like this duplication.\n\n> Especially confusing is that if there are already applied patches, the\n> diff shown is the one of the previous top patch\n\nAre you sure it doesn't only show the local changes (which you might\nwant to add in a new patch)?\n\n> - and if there is no\n> applied patches, we get the exception you noticed.\n\nThat's a bug, indeed.\n\n> I guess -s should be removed for 0.13.1.\n\nI'll still like to keep it for the rare cases when I use the diff to\nwrite the patch description.\n\n> I also tried with \"stg refresh -m ''\" to see if it caused the same\n> problem, but it appears to have another problem instead: it does not\n> refresh the patch description at all.\n>\n> My guess is that we should not allow empty patch description (and\n> maybe fill it with provided patchname).\n\nI think we should put some default patch description.\n\n-- \nCatalin\n"},{"id":"50004","messageId":"20070806095623.GA23349@diana.vm.bytemark.co.uk","threadId":"9368","inReplyTo":"b0943d9e0708060236x19674e4cjf04cec716ae6246c@mail.gmail.com","subject":"Re: Some ideas for StGIT","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-08-06T09:56:23Z","receivedAt":"2007-08-06T09:56:23Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-08-06 10:36:25 +0100, Catalin Marinas wrote:\n\n> On 03/08/2007, Pavel Roskin wrote:\n>\n> > Another approach would be to reexamine the patch after \"stg\n> > refresh -es\" and to apply it instead of the original patch. If the\n> > patch doesn't apply, the options would be to discard the edits or\n> > to re-launch the editor.\n>\n> That's an interesting idea but maybe we should have a separate\n> command like --edit-full to edit the full patch + log (part of the\n> functionality already available in import).\n\nI never really understood why commit message editing had to be part of\nthe \"refresh\" command. If it were a separate command and not tied to\nrefresh, we could allow editing the message (and author, committer,\ndate, ...) of any commit in the stack -- since the tree objects would\nbe unchanged, we could just reuse the same tree objects when rewriting\nthe commit objects on top of it.\n\nThat's obviously not going to work if we allow editing of the patch.\nBut patch editing isn't a good fit as a refresh switch either, since\nit's not at all related to replacing the tree of the current patch\nwith the working tree.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"50005","messageId":"b0943d9e0708060301q33b013efwc28d1c28d31ceb80@mail.gmail.com","threadId":"9368","inReplyTo":"20070804080801.GD30277@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Some ideas for StGIT","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-08-06T10:01:09Z","receivedAt":"2007-08-06T10:01:09Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 04/08/2007, Yann Dirson wrote:\n> FWIW, I have written a couple of scripts to help moving stuff around\n> between patches. Those are not yet integrated in stgit proper, and it\n> happens that the 0.13 tarball does not contain them, they are only\n> available from the git tree (better use my tree[1], since I updated them\n> recently).\n\nThat's probably because I haven't updated the MANIFEST.in file (I\ndon't look in the contrib directory much :-)).\n\n-- \nCatalin\n"},{"id":"50014","messageId":"1186404125.10627.30.camel@dv","threadId":"9368","inReplyTo":"20070806095623.GA23349@diana.vm.bytemark.co.uk","subject":"Re: Some ideas for StGIT","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2007-08-06T12:42:05Z","receivedAt":"2007-08-06T12:42:05Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Mon, 2007-08-06 at 11:56 +0200, Karl Hasselström wrote:\n\n> I never really understood why commit message editing had to be part of\n> the \"refresh\" command. If it were a separate command and not tied to\n> refresh, we could allow editing the message (and author, committer,\n> date, ...) of any commit in the stack -- since the tree objects would\n> be unchanged, we could just reuse the same tree objects when rewriting\n> the commit objects on top of it.\n> \n> That's obviously not going to work if we allow editing of the patch.\n> But patch editing isn't a good fit as a refresh switch either, since\n> it's not at all related to replacing the tree of the current patch\n> with the working tree.\n\nPurely from the code standpoint, yes, it should be a separate command.\nBut it may be practical to have both in one command, since I commonly\nneed to change the description after changing the code.\n\nWe need to think what would be convenient for the normal workflow.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"50018","messageId":"1186406768.10627.50.camel@dv","threadId":"9368","inReplyTo":"b0943d9e0708060249h4a3f59bobfac8f9014aca82f@mail.gmail.com","subject":"Re: Some ideas for StGIT","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2007-08-06T13:26:08Z","receivedAt":"2007-08-06T13:26:08Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Mon, 2007-08-06 at 10:49 +0100, Catalin Marinas wrote:\n\n> The story for the 'new -s' option was that with StGIT (not possible\n> with Quilt), one can start modifying the local tree and only create a\n> patch afterwards.\n\nAnd that's what I really like about StGIT. I like that I can edit code\nwithout worrying (too much) about the state of the repository.\n\n> The newly created patch is always empty, even if\n> there were local changes and showing them was useful for writing the\n> patch description. One can use refresh for checking the changes in.\n> Indeed, the 'new' command can be improved to have part of the\n> 'refresh' functionality, though I don't really like this duplication.\n\nIt should be fine as long as the code is reused IMHO.\n\n> > Especially confusing is that if there are already applied patches, the\n> > diff shown is the one of the previous top patch\n> \n> Are you sure it doesn't only show the local changes (which you might\n> want to add in a new patch)?\n\nI confirm this bug.\n\n> I think we should put some default patch description.\n\nI agree. Sometimes it's too early to write a description.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"50019","messageId":"20070806135204.GC23349@diana.vm.bytemark.co.uk","threadId":"9368","inReplyTo":"1186404125.10627.30.camel@dv","subject":"Re: Some ideas for StGIT","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-08-06T13:52:04Z","receivedAt":"2007-08-06T13:52:04Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-08-06 08:42:05 -0400, Pavel Roskin wrote:\n\n> On Mon, 2007-08-06 at 11:56 +0200, Karl Hasselström wrote:\n>\n> > I never really understood why commit message editing had to be\n> > part of the \"refresh\" command. If it were a separate command and\n> > not tied to refresh, we could allow editing the message (and\n> > author, committer, date, ...) of any commit in the stack -- since\n> > the tree objects would be unchanged, we could just reuse the same\n> > tree objects when rewriting the commit objects on top of it.\n>\n> Purely from the code standpoint, yes, it should be a separate\n> command. But it may be practical to have both in one command, since\n> I commonly need to change the description after changing the code.\n\nSure. I don't have any objection to making\n\n stg refresh -e\n\nbe equivalent to\n\n stg refresh && stg edit-patch-message \n\nWhat I'm objecting to is being forced to refresh when I just want to\nedit the message. (And, to a lesser degree, having to manually push\nand pop to make the patch topmost before I can edit its message.)\n\nObviously not annoyed enough to have written a patch for it yet,\nthough. :-)\n\n> We need to think what would be convenient for the normal workflow.\n\nOf course.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"50025","messageId":"20070806151920.GA22508@filer.fsl.cs.sunysb.edu","threadId":"9368","inReplyTo":"1186406768.10627.50.camel@dv","subject":"Re: Some ideas for StGIT","fromName":"Josef Sipek","fromEmail":"jsipek@fsl.cs.sunysb.edu","sentAt":"2007-08-06T15:19:21Z","receivedAt":"2007-08-06T15:19:21Z","isPatch":false,"sender":{"key":"jsipek@fsl.cs.sunysb.edu","avatar":null},"body":"\n\nOn Mon, Aug 06, 2007 at 09:26:08AM -0400, Pavel Roskin wrote:\n> On Mon, 2007-08-06 at 10:49 +0100, Catalin Marinas wrote:\n> \n> > The story for the 'new -s' option was that with StGIT (not possible\n> > with Quilt), one can start modifying the local tree and only create a\n> > patch afterwards.\n> \n> And that's what I really like about StGIT. I like that I can edit code\n> without worrying (too much) about the state of the repository.\n \nguilt-new -f \n\n> > The newly created patch is always empty, even if\n> > there were local changes and showing them was useful for writing the\n> > patch description. One can use refresh for checking the changes in.\n> > Indeed, the 'new' command can be improved to have part of the\n> > 'refresh' functionality, though I don't really like this duplication.\n> \n> It should be fine as long as the code is reused IMHO.\n\nAgreed.\n\n> > I think we should put some default patch description.\n> \n> I agree. Sometimes it's too early to write a description.\n \nIf Guilt doesn't find a description in the patch file during push, it uses\n\"patch $patchname\" as the commit message. This makes it enough of an\neye-sore that you notice before you submit the patches upstream :)\n\nJosef 'Jeff' Sipek.\n\n-- \nFailure is not an option,\nIt comes bundled with your Microsoft product.\n"},{"id":"50031","messageId":"1186420646.12895.3.camel@dv","threadId":"9368","inReplyTo":"b0943d9e0708060236x19674e4cjf04cec716ae6246c@mail.gmail.com","subject":"Re: Some ideas for StGIT","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2007-08-06T17:17:26Z","receivedAt":"2007-08-06T17:17:26Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Mon, 2007-08-06 at 10:36 +0100, Catalin Marinas wrote:\n\n> > The main point in favor of quilt is that it allows to edit the patches\n> > with the text editor. One can pop all patches, edit them and push the\n> > all back.\n> \n> If this is the main feature they need, they probably don't need git at\n> all and quilt would be enough. I was using quilt before starting StGIT\n> but the main problem I had with plain patches approach was the\n> conflict solving.\n\nOK, I understand it wasn't a good idea to ask for improvement on behalf\nof others.\n\n> StGIT does a 'git-diff | git-apply' as a patch push optimization and\n> we could even cache the diff but the current algorithm is that if\n> git-apply fails, StGIT falls back to a three-way merge and even an\n> interactive user merge (via xxdiff for example). I find the three-way\n> merging (automatic or interactive) much more powerful than fuzzy patch\n> application.\n\nI agree. I have no problem with what StGIT does internally.\n\n> If we would allow patch editing, the 'stg push' algorithms wouldn't\n> know when git-apply failed because the patch was edited or the base\n> was changed. Falling back to the three-way merge would lose the edited\n> patch. If one doesn't need three-way merging, quilt is good enough.\n\nI suggest that StGIT saves the original patch and then does interdiff\nbetween the old and the new patch. The original patch is applied first\njust as it's applied now, and then the difference is applied on top of\nthat.\n\nTemporary files should be kept in case of failure.\n\n> Other advantages of the three-way merging is the detection of full\n> patches or hunks merged upstream (the former can also be achieved by\n> testing the reverse-application of the patches).\n\nI'm fully with you here. Having git history can only be a good thing.\n\n> I don't usually edit patches during development, I prefer to edit the\n> source files and review the diff. It happens many times to move hunks\n> between patches but I usually towards the bottom patches in the stack\n> (using stg export and emacs) and the three-way merging automatically\n> removes the merged hunks from top patches.\n\nWhat I normally need to edit is the comments. Editing the code is\nrisky, although I may want to rename some badly named variable\nintroduced by the patch.\n\n> > I don't suggest that StGIT gives up on the git-based storage, but this\n> > mode of operation could be implemented in two ways.\n> >\n> > One is to have a command opposite to \"export\". It would read the files\n> > that \"export\" produces, replacing the existing patches.\n> \n> As Yann said, we already have 'stg import --replace'.\n\nThanks!\n\n> > Another approach would be to reexamine the patch after \"stg refresh -es\"\n> > and to apply it instead of the original patch. If the patch doesn't\n> > apply, the options would be to discard the edits or to re-launch the\n> > editor.\n> \n> That's an interesting idea but maybe we should have a separate command\n> like --edit-full to edit the full patch + log (part of the\n> functionality already available in import).\n\nI hate to be in a situation when I want to edit something but cannot,\nbecause I didn't run some command before. What I like about StGIT is\nthat it allows me to do things my way.\n\nI don't know if I want to change the patch before I see it.\n\n> > Finally, it would be great to have TLS support in the mail command.\n> > Mercurial has it, and looking at their mail.py, it doesn't seem to be\n> > much work.\n> \n> Indeed, the SMTP Python objects already provide support for TLS via starttls().\n\nAnd hg provides a great example.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"51372","messageId":"b0943d9e0708230709o6ae16d5dvcfeba2f344f57fa5@mail.gmail.com","threadId":"9368","inReplyTo":"20070806135204.GC23349@diana.vm.bytemark.co.uk","subject":"Re: Some ideas for StGIT","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-08-23T14:09:48Z","receivedAt":"2007-08-23T14:09:48Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"(cleaning up my inbox after holiday, so my replies might look random)\n\nOn 06/08/07, Karl Hasselström wrote:\n> On 2007-08-06 08:42:05 -0400, Pavel Roskin wrote:\n> > Purely from the code standpoint, yes, it should be a separate\n> > command. But it may be practical to have both in one command, since\n> > I commonly need to change the description after changing the code.\n>\n> Sure. I don't have any objection to making\n>\n> stg refresh -e\n>\n> be equivalent to\n>\n> stg refresh && stg edit-patch-message \n\nThe only objection is the long command name - 'stg edit []'\nwould be just fine. It would also be nice to do (with an additional\noption), the equivalent of export - edit - import in case one wants to\nalso modify the diff.\n\n> What I'm objecting to is being forced to refresh when I just want to\n> edit the message. (And, to a lesser degree, having to manually push\n> and pop to make the patch topmost before I can edit its message.)\n\nNot necessarily - 'stg refresh -e -p ' does the pop/push for\nyou and it even uses the fast-forwarding.\n\n-- \nCatalin\n"},{"id":"51373","messageId":"20070823143411.GA16051@diana.vm.bytemark.co.uk","threadId":"9368","inReplyTo":"b0943d9e0708230709o6ae16d5dvcfeba2f344f57fa5@mail.gmail.com","subject":"Re: Some ideas for StGIT","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-08-23T14:34:11Z","receivedAt":"2007-08-23T14:34:11Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-08-23 15:09:48 +0100, Catalin Marinas wrote:\n\n> On 06/08/07, Karl Hasselström wrote:\n>\n> > On 2007-08-06 08:42:05 -0400, Pavel Roskin wrote:\n> >\n> > > Purely from the code standpoint, yes, it should be a separate\n> > > command. But it may be practical to have both in one command,\n> > > since I commonly need to change the description after changing\n> > > the code.\n> >\n> > Sure. I don't have any objection to making\n> >\n> > stg refresh -e\n> >\n> > be equivalent to\n> >\n> > stg refresh && stg edit-patch-message \n>\n> The only objection is the long command name - 'stg edit []'\n> would be just fine.\n\nOh, I chose a ridiculously long name on purpose, to make it\nunambiguous while at the same time not implying that I had a good name\nalready thought out. :-)\n\n> It would also be nice to do (with an additional option), the\n> equivalent of export - edit - import in case one wants to also\n> modify the diff.\n\nYes. This is probably one of the most asked-for (and least\nimplemented) features of StGIT.\n\n> > What I'm objecting to is being forced to refresh when I just want\n> > to edit the message. (And, to a lesser degree, having to manually\n> > push and pop to make the patch topmost before I can edit its\n> > message.)\n>\n> Not necessarily - 'stg refresh -e -p ' does the pop/push for\n> you and it even uses the fast-forwarding.\n\nHmm, that's better. But it shouldn't be a refresh subcommand!\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"}]}