{"thread":{"id":"9872","subject":"Re: [StGit PATCH] It doesn't make sense to sink below an unapplied patch","startedAt":"2007-09-15T23:22:52Z","lastAt":"2007-09-17T09:49:28Z","messageCount":4,"participants":["Karl Hasselström","David Kågedal","Jon Smirl"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"53148","messageId":"20070915232252.GA25507@diana.vm.bytemark.co.uk","threadId":"9872","inReplyTo":"9e4733910709140918wbe94b5eu6ec326b25b0f3d42@mail.gmail.com","subject":"Re: [StGit PATCH] It doesn't make sense to sink below an unapplied patch","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-09-15T23:22:52Z","receivedAt":"2007-09-15T23:22:52Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-09-14 12:18:17 -0400, Jon Smirl wrote:\n\n> On 9/14/07, Karl Hasselström wrote:\n>\n> > $ stg pop p2 p3\n> > $ stg push p3 p2\n> >\n> > Does this cover what you had in mind?\n>\n> Sure this works. I'm just wondering if it is a good idea to have\n> separate reordering commands for patches that are applied vs\n> unapplied. The separate commands confused me.\n>\n> Would it be better to simply prohibit reordering of apply patches\n> and require that they be popped before they can be reordered? A\n> sink/float that causes merge errors must be a mess to sort out.\n\nIt's not a mess, actually -- it's implemented in terms of push and pop\nof single patches, so the theory is dead simple. (The push and pop\ncommands are also implemented in terms of push and pop of single\npatches.)\n\n> If you prohibit reordering of applied patches sink/float can be\n> eliminated.\n\nBut they're useful! Though as I said earlier, they're implemented in\nterms of push and pop, so they're technically redundant. But \"sink p5\n--to p2\" would be \"pop p3..p5 && push p5 p3 p4\", which is more typing\n(starting with applied patches p1, p2, p3, p4, p5).\n\n> Another way to handle this would be to eliminate the ability of\n> pop/push to reorder and extend sink/float to handle unapplied\n> patches.\n\nI think that I'd like the latter without the former -- that is,\nteaching sink/float how to handle unapplied patches, and leaving\npush/pop as is. That'll let you do what you tried to do in the first\nplace, and will leave us with a more redundant command set, but I\ndon't think that's bad.\n\nAnother idea that's been kicked around is to have a general reorder\ncommand, that spawns an editor and lets you move around (and delete)\npatch names until you're satisfied. (This too would be implemented in\nterms of push and pop of single patches.)\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"53218","messageId":"87veaab93v.fsf@morpheus.local","threadId":"9872","inReplyTo":"20070915232252.GA25507@diana.vm.bytemark.co.uk","subject":"Re: [StGit PATCH] It doesn't make sense to sink below an unapplied patch","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2007-09-16T21:20:36Z","receivedAt":"2007-09-16T21:20:36Z","isPatch":true,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"Karl Hasselström writes:\n\n> Another idea that's been kicked around is to have a general reorder\n> command, that spawns an editor and lets you move around (and delete)\n> patch names until you're satisfied. (This too would be implemented in\n> terms of push and pop of single patches.)\n\nThis of course sounds very much like \"git rebase -i\", but the\nsemantics would maybe not be identical.\n\nOne feature from rebase I'd like to see if this was implemented is the\n\"squash\" option to join two patches. But it would probably be called\n\"fold\" to keep with stgit terminology.\n\nAnother way of doing this editing is to do it interactively,\ninteracting with the patches directly using a UI, such as an Emacs\nediting mode, or a custom text or graphical UI. As you might guess,\nI've been thinking a little of an Emacs interface, but nothing has\nbeen written yet.\n\n-- \nDavid Kågedal\n"},{"id":"53223","messageId":"9e4733910709161441j43e69ee2j6c57489c4b0eafbb@mail.gmail.com","threadId":"9872","inReplyTo":"20070915232252.GA25507@diana.vm.bytemark.co.uk","subject":"Re: [StGit PATCH] It doesn't make sense to sink below an unapplied patch","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2007-09-16T21:41:27Z","receivedAt":"2007-09-16T21:41:27Z","isPatch":true,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 9/15/07, Karl Hasselström wrote:\n> On 2007-09-14 12:18:17 -0400, Jon Smirl wrote:\n> > Another way to handle this would be to eliminate the ability of\n> > pop/push to reorder and extend sink/float to handle unapplied\n> > patches.\n>\n> I think that I'd like the latter without the former -- that is,\n> teaching sink/float how to handle unapplied patches, and leaving\n> push/pop as is. That'll let you do what you tried to do in the first\n> place, and will leave us with a more redundant command set, but I\n> don't think that's bad.\n\nThe stack model may be too simplistic. My current patches involve four\ngroups, there is ordering in the group but the groups can be applied\nindependently. Patches could be marked as depending on another\npatch/group. You could then mark patches applied/unapplied and stg\nwould sort out the order. Allowing group names would make this easier.\n\nThe mm kernel has 1,500 patches. It must be a pain trying to keep\nthese in a linear order.\n\nThe git diff output format could be extended with\nDepends-on/Group-name lines. That would let Andrew import the\ndependencies.\n\n\n> Another idea that's been kicked around is to have a general reorder\n> command, that spawns an editor and lets you move around (and delete)\n> patch names until you're satisfied. (This too would be implemented in\n> terms of push and pop of single patches.)\n>\n> --\n> Karl Hasselström, kha@treskal.com\n> www.treskal.com/kalle\n>\n\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"53291","messageId":"20070917094928.GC8657@diana.vm.bytemark.co.uk","threadId":"9872","inReplyTo":"87veaab93v.fsf@morpheus.local","subject":"Re: [StGit PATCH] It doesn't make sense to sink below an unapplied patch","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-09-17T09:49:28Z","receivedAt":"2007-09-17T09:49:28Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-09-16 23:20:36 +0200, David Kågedal wrote:\n\n> Karl Hasselström writes:\n>\n> > Another idea that's been kicked around is to have a general\n> > reorder command, that spawns an editor and lets you move around\n> > (and delete) patch names until you're satisfied. (This too would\n> > be implemented in terms of push and pop of single patches.)\n>\n> This of course sounds very much like \"git rebase -i\", but the\n> semantics would maybe not be identical.\n\nFor one, the StGit version would have to update StGit's metadata. :-)\n\n> One feature from rebase I'd like to see if this was implemented is\n> the \"squash\" option to join two patches. But it would probably be\n> called \"fold\" to keep with stgit terminology.\n\nI actually started to write such a command this weekend, but I didn't\nhave time to finish it. I did however come to the conclusion that I'd\nwant to refactor the relationship between patches and commits first.\n(Which was why I was so pleasantly surprised that you spent part of\nthe weekend doing precisely that!)\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"}]}