{"thread":{"id":"8068","subject":"Merging commits together into a super-commit","startedAt":"2007-05-10T10:51:01Z","lastAt":"2007-05-14T19:28:10Z","messageCount":35,"participants":["Alex Bennee","Raimund Bauer","Johannes Schindelin","Johannes Sixt","Linus Torvalds","Carl Worth","J. Bruce Fields","Petr Baudis","Robin Rosenberg","Karl Hasselström","Jan Hudec","Yann Dirson","Jakub Narebski","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"41730","messageId":"1178794261.5806.98.camel@murta.transitives.com","threadId":"8068","inReplyTo":null,"subject":"Merging commits together into a super-commit","fromName":"Alex Bennee","fromEmail":"kernel-hacker@bennee.com","sentAt":"2007-05-10T10:51:01Z","receivedAt":"2007-05-10T10:51:01Z","isPatch":false,"sender":{"key":"kernel-hacker@bennee.com","avatar":null},"body":"Hi,\n\nI really love the fact I can micro-commit changes when I'm developing.\nHowever at some point the combination of changes I have made can be\nconsidered a single body of work. This is especially true when you start\ndoing things like re-basing on code that has moved around a lot. You\ndon't want to be correcting a whole bunch of merge failures for every\ncommit in your current tree.\n\nSo far the only was I can see to do this is a:\n\ngit-diff master..HEAD > my.patch\n\nAnd then re-applying your patch in stages, manually doing the commits.\n\nAm I missing something?\n\nI'm thinking something like git-cherrypick taking multiple commits and\ncreate a new super commit on a new tree. i.e.:\n\ngit-cherrypick -m \"Valgrind fixes\" 12345.. 12678.. 565757..\n\nMerging the existing commit comments would be nice too.\n\n-- \nAlex, homepage: http://www.bennee.com/~alex/\nAll God's children are not beautiful. Most of God's children are, in\nfact, barely presentable. -- Fran Lebowitz, \"Metropolitan Life\"\n"},{"id":"41731","messageId":"000e01c792f5$0861abd0$0b0aa8c0@abf.local","threadId":"8068","inReplyTo":"1178794261.5806.98.camel@murta.transitives.com","subject":"RE: Merging commits together into a super-commit","fromName":"Raimund Bauer","fromEmail":"ray@softwarelandschaft.com","sentAt":"2007-05-10T11:19:08Z","receivedAt":"2007-05-10T11:19:08Z","isPatch":false,"sender":{"key":"ray@softwarelandschaft.com","avatar":null},"body":"> Hi,\n> \n> I really love the fact I can micro-commit changes when I'm \n> developing. However at some point the combination of changes \n> I have made can be considered a single body of work. This is \n> especially true when you start doing things like re-basing on \n> code that has moved around a lot. You don't want to be \n> correcting a whole bunch of merge failures for every commit \n> in your current tree.\n> \n> So far the only was I can see to do this is a:\n> \n> git-diff master..HEAD > my.patch\n> \n> And then re-applying your patch in stages, manually doing the commits.\n> \n> Am I missing something?\n\ngit merge --squash ?\n\n-- \nbest regards\n\n  Ray\n"},{"id":"41733","messageId":"1178796748.5806.102.camel@murta.transitives.com","threadId":"8068","inReplyTo":"000e01c792f5$0861abd0$0b0aa8c0@abf.local","subject":"RE: Merging commits together into a super-commit","fromName":"Alex Bennee","fromEmail":"kernel-hacker@bennee.com","sentAt":"2007-05-10T11:32:28Z","receivedAt":"2007-05-10T11:32:28Z","isPatch":false,"sender":{"key":"kernel-hacker@bennee.com","avatar":null},"body":"On Thu, 2007-05-10 at 13:19 +0200, Raimund Bauer wrote:\n> > Hi,\n>  <snip> \n> You don't want to be \n> > correcting a whole bunch of merge failures for every commit \n> > in your current tree.\n> > \n> > So far the only was I can see to do this is a:\n> > \n> > git-diff master..HEAD > my.patch\n> > \n> > And then re-applying your patch in stages, manually doing the commits.\n> > \n> > Am I missing something?\n> \n> git merge --squash ?\n\nHmm, that would do although it only works on whole trees, you can't\nspecify a range of commits. So you would have to cherrypick groups of\nchanges onto other branches and then merge them together with a couple\nof --squashes\n\nHowever thanks for pointing that one out :-)\n\n-- \nAlex, homepage: http://www.bennee.com/~alex/\nA pretty woman can do anything; an ugly woman must do everything.\n"},{"id":"41736","messageId":"4643049C.3D5F30D8@eudaptics.com","threadId":"8068","inReplyTo":"1178794261.5806.98.camel@murta.transitives.com","subject":"Re: Merging commits together into a super-commit","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-05-10T11:40:12Z","receivedAt":"2007-05-10T11:40:12Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Alex Bennee wrote:\n> I really love the fact I can micro-commit changes when I'm developing.\n> However at some point the combination of changes I have made can be\n> considered a single body of work. This is especially true when you start\n> doing things like re-basing on code that has moved around a lot. You\n> don't want to be correcting a whole bunch of merge failures for every\n> commit in your current tree.\n> \n> So far the only was I can see to do this is a:\n> \n> git-diff master..HEAD > my.patch\n> \n> And then re-applying your patch in stages, manually doing the commits.\n> \n> Am I missing something?\n> \n> I'm thinking something like git-cherrypick taking multiple commits and\n> create a new super commit on a new tree. i.e.:\n> \n> git-cherrypick -m \"Valgrind fixes\" 12345.. 12678.. 565757..\n> \n> Merging the existing commit comments would be nice too.\n\nHere we go:\n\n- cherry-pick them before commit\n\n  $ git cherry-pick -n x\n  $ git cherry-pick -n y\n  $ git cherry-pick -n z\n  $ git commit -m \"$(for c in x y z; do git show --stat $c; done)\" -e\n\n- merge in a single commit\n\n  $ git merge --squash foo\n\nYou didn't really think that git couldn't do that, did you? ;)\n\n-- Hannes\n"},{"id":"41735","messageId":"Pine.LNX.4.64.0705101342060.4167@racer.site","threadId":"8068","inReplyTo":"1178796748.5806.102.camel@murta.transitives.com","subject":"RE: Merging commits together into a super-commit","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-10T11:43:46Z","receivedAt":"2007-05-10T11:43:46Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 10 May 2007, Alex Bennee wrote:\n\n> On Thu, 2007-05-10 at 13:19 +0200, Raimund Bauer wrote:\n> > > Hi,\n> >  <snip> \n> > You don't want to be \n> > > correcting a whole bunch of merge failures for every commit \n> > > in your current tree.\n> > > \n> > > So far the only was I can see to do this is a:\n> > > \n> > > git-diff master..HEAD > my.patch\n> > > \n> > > And then re-applying your patch in stages, manually doing the commits.\n> > > \n> > > Am I missing something?\n> > \n> > git merge --squash ?\n> \n> Hmm, that would do although it only works on whole trees, you can't\n> specify a range of commits. So you would have to cherrypick groups of\n> changes onto other branches and then merge them together with a couple\n> of --squashes\n\nSince specifying several commit ranges can always lead to merge conflicts, \nit makes no sense to _not_ accumulate the patches in a separate branch.\n\nCiao,\nDscho\n"},{"id":"41748","messageId":"alpine.LFD.0.98.0705100857450.3986@woody.linux-foundation.org","threadId":"8068","inReplyTo":"4643049C.3D5F30D8@eudaptics.com","subject":"Re: Merging commits together into a super-commit","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-05-10T16:01:15Z","receivedAt":"2007-05-10T16:01:15Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 10 May 2007, Johannes Sixt wrote:\n>\n> - cherry-pick them before commit\n> \n>   $ git cherry-pick -n x\n>   $ git cherry-pick -n y\n>   $ git cherry-pick -n z\n\nI've done this (actually, mostly with \"revert\", but cherry-pick and revert \nare literally the same things).\n\nHowever:\n\n>   $ git commit -m \"$(for c in x y z; do git show --stat $c; done)\" -e\n\nI'm too lazy to do this part, so I always do it by hand.\n\n> You didn't really think that git couldn't do that, did you? ;)\n\nClearly git can, but equally clearly it really *would* be pretty nice if \nyou could just do\n\n\tgit cherry-pick x y z\n\nand create one commit and have the message already somewhat done for you \n(and \"git revert\" doing the same).\n\nSo if somebody does that, I'll certainly applaud..\n\n\t\tLinus\n"},{"id":"41753","messageId":"87wszg39cp.wl%cworth@cworth.org","threadId":"8068","inReplyTo":"alpine.LFD.0.98.0705100857450.3986@woody.linux-foundation.org","subject":"Re: Merging commits together into a super-commit","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-05-10T16:57:10Z","receivedAt":"2007-05-10T16:57:10Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 10 May 2007 09:01:15 -0700 (PDT), Linus Torvalds wrote:\n> Clearly git can, but equally clearly it really *would* be pretty nice if\n> you could just do\n>\n> \tgit cherry-pick x y z\n>\n> and create one commit and have the message already somewhat done for you\n> (and \"git revert\" doing the same).\n\nPerhaps with a --squash option. I've already been wanting a\ncherry-pick that accepts a range, but that makes separate commits.\n\nYes, I know there's some git-rebase thing that will do it, but I can\nnever remember the right syntax for that without studying the\ndocumentation[*]. What I find myself wanting to type is just:\n\n\tgit cherry-pick A..B\n\nBut there is the whole problem of how to deal with any conflict that\nappears during the process.\n\n-Carl\n\n[*] I do use one form of rebase without ever needing to consult the\ndocumentation, but it's in the opposite \"direction\", if you will, from\nthe cherry-pick-a-range operation. I use it when I want to rebase a\nset of commits from my current branch to some other branch, such as:\n\n\tgit rebase origin\n\nNot surprisingly, what's common about both of the operations above is\nthat they are really only accepting a single argument, (a range in one\ncase, and a branch-name in the other). That's what makes for an\neasy-to-use command. Things that require multiple branch names in a\nparticular order, or extra options, (see \"git rebase --onto newbase\nupstream branch\"), need someone smarter than me to drive them.\n\nAnother problem is that using the optional final [<branch>] argument\nto git-rebase makes it change the current branch, (which no other\ngit-rebase operation does), and that's another thing I find very\nconfusing.\n\nI'm sure the most complex form of git-rebase solves some precise\nproblem that someone has, (and maybe even gets used regularly). But\nit's got enough complications that I just ignore it, (and would\ninstead really prefer being able to just cherry-pick a whole range).\n\n"},{"id":"41755","messageId":"20070510171457.GK13719@fieldses.org","threadId":"8068","inReplyTo":"87wszg39cp.wl%cworth@cworth.org","subject":"Re: Merging commits together into a super-commit","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-05-10T17:14:57Z","receivedAt":"2007-05-10T17:14:57Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, May 10, 2007 at 09:57:10AM -0700, Carl Worth wrote:\n> I'm sure the most complex form of git-rebase solves some precise\n> problem that someone has, (and maybe even gets used regularly). But\n> it's got enough complications that I just ignore it, (and would\n> instead really prefer being able to just cherry-pick a whole range).\n\nI use it all the time to fix up old commits with\n\n\tgit checkout sha1-of-bad-commit\n\t...edit, test,...\n\tgit commit -a ---amend\n\tgit rebase --onto HEAD sha1-of-bad-commit original-branch\n\nBut though it usually does what I want, I'm in total agreement about the\nconfusing syntax and branch-switching behavior....\n\n--b.\n"},{"id":"41760","messageId":"87vef0350y.wl%cworth@cworth.org","threadId":"8068","inReplyTo":"20070510171457.GK13719@fieldses.org","subject":"Re: Merging commits together into a super-commit","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-05-10T18:30:37Z","receivedAt":"2007-05-10T18:30:37Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 10 May 2007 13:14:57 -0400, \"J. Bruce Fields\" wrote:\n> I use it all the time to fix up old commits with\n>\n> \tgit checkout sha1-of-bad-commit\n> \t...edit, test,...\n> \tgit commit -a ---amend\n> \tgit rebase --onto HEAD sha1-of-bad-commit original-branch\n\nExcellent. Thanks for the description.\n\nFixing up some broken (unpublished) commit in the past is a useful\nthing to support[*]. Of course, \"commit --amend\" takes care of this for\nthe case where it's the most recent commit. For an older commit, here\nis exactly what I'd like to do, (showing that my suggestion of\ncherry-pick with a range would cover exactly this scenario):\n\n\tgit tag tainted\t\t# Could be \"git branch tainted\" just as well\n\n\tgit reset --hard bad-commit\n\t...edit, test...\n\tgit commit --amend\n\tgit cherry-pick bad-commit..tainted\n\n\tgit tag -d tainted\n\nSo, compared to the rebase usage, this does add two commands for\nbookkeeping the original state and cleaning it up. But the syntax for\nthe cherry-pick part is quite a bit simpler than the original rebase\nat least.\n\nAlso, \"reset --hard\" isn't actually what I want in this case. I'd like\nthis recipe to use something that would move the current branch to\nsome other point, but in a safe way, (that is, not destroy any\nuncommitted changes that might exist at the beginning). I don't have\nany proposal for what that would be.\n\n-Carl\n\n[*] I've also experimented with using other \"non-core git\" ways of\naddressing this same problem. Here are a couple that I haven't found\nsatisfactory for this particular use case:\n\nstg - This probably works great if you're using it as a primary\n      interface. But trying to use it as a quick one-off when\n      generally using core git does not work well at all. Instead of\n      the two \"git tag\" commands in my recipe above, an stg recipe\n      would involve a lot of additional bookkeeping with stg init, stg\n      uncommit [N times for fixing a commit N steps back in the\n      history], stg goto, stg push, etc.\n\ncg-admin-rewritehist - This is a powerful tool, but its interface\n      isn't geared toward interactively fixing things up, (instead\n      requiring a filter to be executed at all steps). So, while it's\n      great for changing history, (as its name suggests), such as\n      performing a sed operation on the commit messages, or\n      eliminating a file, it doesn't help much with the \"fix up one\n      broken commit in the past\".\n\n      It is worth noting that quite unlike rebase,\n      cg-admin-rewritehist can deal quite nicely with history that\n      involves branching and merging.\n\n"},{"id":"41761","messageId":"20070510192106.GB4489@pasky.or.cz","threadId":"8068","inReplyTo":"87vef0350y.wl%cworth@cworth.org","subject":"Re: Merging commits together into a super-commit","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-10T19:21:06Z","receivedAt":"2007-05-10T19:21:06Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, May 10, 2007 at 08:30:37PM CEST, Carl Worth wrote:\n> stg - This probably works great if you're using it as a primary\n>       interface. But trying to use it as a quick one-off when\n>       generally using core git does not work well at all. Instead of\n>       the two \"git tag\" commands in my recipe above, an stg recipe\n>       would involve a lot of additional bookkeeping with stg init, stg\n>       uncommit [N times for fixing a commit N steps back in the\n>       history], stg goto, stg push, etc.\n\nI think you are underestimating stg here. You can stg init just once per\nbranch (ever), I think. Then,\n\n\tstg uncommit -n N\n\tstg pop -n N-1\n\t..hack..\n\tstg refresh\n\tstg push -a\n\nIt seems to be a bit shorter than the sequence you've presented above,\nand overally working with volatile commits using StGIT feels much more\nnatural to me - and I haven't even ever used quilt seriously! (I have\nspecial antipathy to the git reset UI, too.)\n\nFew days ago Santi Bejar has sent me a bundle with some updates to the\nGit homepage (thanks again a lot!). Since I didn't want some of the\npatches and wanted to tweak others, what I eventually did was pretty\nmuch this: I fast-forwarded my master to his bundle's head, then\nuncommitted the patches, popped them all and repeated the sequence\n\n\tstg push\n\t..review..\n\t\tstg refresh\n\t\tstg commit\n\t..or..\n\t\tstg delete `stg top`\n\nfor each patch.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"41762","messageId":"20070510192212.GP13719@fieldses.org","threadId":"8068","inReplyTo":"87vef0350y.wl%cworth@cworth.org","subject":"Re: Merging commits together into a super-commit","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-05-10T19:22:12Z","receivedAt":"2007-05-10T19:22:12Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, May 10, 2007 at 11:30:37AM -0700, Carl Worth wrote:\n> So, compared to the rebase usage, this does add two commands for\n> bookkeeping the original state and cleaning it up. But the syntax for\n> the cherry-pick part is quite a bit simpler than the original rebase\n> at least.\n\nYeah, something like that would be great.  I think I've seen others\nsuggest similar syntax before, so it's probably just a question of one\nof us who want this finding time to write the patches.\n\n> Also, \"reset --hard\" isn't actually what I want in this case. I'd like\n> this recipe to use something that would move the current branch to\n> some other point, but in a safe way, (that is, not destroy any\n> uncommitted changes that might exist at the beginning). I don't have\n> any proposal for what that would be.\n\nThe tag creation and cleanup could get to be annoying too.  You could\nscrounge through the reflog instead of using a temporary tag, but\ndepending on the amount of --amend'ing and cherry-picking you do the\nreflog entry may end up in a different place each time, so it's probably\nhard to make this automatic.\n\n> stg - This probably works great if you're using it as a primary\n>       interface. But trying to use it as a quick one-off when\n>       generally using core git does not work well at all. Instead of\n>       the two \"git tag\" commands in my recipe above, an stg recipe\n>       would involve a lot of additional bookkeeping with stg init, stg\n>       uncommit [N times for fixing a commit N steps back in the\n>       history], stg goto, stg push, etc.\n\nI also didn't like having to come up with another name for each\npatch--I'd rather just run git-log or gitk and cut-n-paste the sha1.\n\nFor kernel work I started out working with multiple (sym- or\nhard-linked) trees, then used akpm's patch scripts, then stgit.  I think\nI'm happiest just using plain git.\n\nThe one thing I've never been good at is keeping the history of the\npatch series itself.\n\n--b.\n"},{"id":"41765","messageId":"20070510194742.GC4489@pasky.or.cz","threadId":"8068","inReplyTo":"20070510192212.GP13719@fieldses.org","subject":"Re: Merging commits together into a super-commit","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-10T19:47:42Z","receivedAt":"2007-05-10T19:47:42Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, May 10, 2007 at 09:22:12PM CEST, J. Bruce Fields wrote:\n> On Thu, May 10, 2007 at 11:30:37AM -0700, Carl Worth wrote:\n> > stg - This probably works great if you're using it as a primary\n> >       interface. But trying to use it as a quick one-off when\n> >       generally using core git does not work well at all. Instead of\n> >       the two \"git tag\" commands in my recipe above, an stg recipe\n> >       would involve a lot of additional bookkeeping with stg init, stg\n> >       uncommit [N times for fixing a commit N steps back in the\n> >       history], stg goto, stg push, etc.\n> \n> I also didn't like having to come up with another name for each\n> patch--I'd rather just run git-log or gitk and cut-n-paste the sha1.\n\nActually, you don't have to - if you don't specify the patch names,\nstgit will make them up itself using the subject of the commit message\nas a base.\n\nAnd by the way, I absolutely love that - when viewing the stack, it's\nvery useful to see what commits you still have to go etc. - stg series\nis concise yet fully descriptive. I'm pondering about whether something\nlike this couldn't be incorporated into other git UIs somehow as well.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"41766","messageId":"87tzuk31fu.wl%cworth@cworth.org","threadId":"8068","inReplyTo":"20070510192106.GB4489@pasky.or.cz","subject":"Re: Merging commits together into a super-commit","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-05-10T19:48:05Z","receivedAt":"2007-05-10T19:48:05Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 10 May 2007 21:21:06 +0200, Petr Baudis wrote:\n> I think you are underestimating stg here.\n\nYes, maybe I didn't learn to use it well enough.\n\n> You can stg init just once per branch (ever), I think.\n\nI don't have details now, but I know I ran into some difficulty when\nleaving the extra stg state around. It seems that it added stuff that\nresulted in some reference of mine becoming ambiguous, (\"refspec <foo>\nmatches more than one\" perhaps?). What I do remember is that I couldn't\nget one of my standard git push commands to work until I deleted all\nof .git/refs/bases and .git/refs/patches and then things started to\nwork again.\n\n> \tstg uncommit -n N\n> \tstg pop -n N-1\n> \t..hack..\n> \tstg refresh\n> \tstg push -a\n>\n> It seems to be a bit shorter than the sequence you've presented above,\n> and overally working with volatile commits using StGIT feels much more\n> natural to me - and I haven't even ever used quilt seriously! (I have\n> special antipathy to the git reset UI, too.)\n\nThe -n option is something I hadn't noticed, and that helps, (except\nthat what I've got to start with is a git revision name, not a\nnumber).\n\nBut there are still some places where an experienced git user runs\ninto some awkward situations trying to use stg. For example, \"stg\nrefresh\" is basically always doing the equivalent of \"commit -a\" so\nthere's annoyingly no way to refresh only some of the modified state\ninto the commit.\n\nAlso, if I want to edit a commit message while under the influence of\nstg, how do I do that? If I do \"git commit --amend\" will I seriously\nconfuse stg, (I'm guessing I would, but I don't know).\n\nIt's that kind of uncertainty that makes me uncomfortable to mix git\nand stg. And personally, I couldn't get excited about using it alone,\n(for example, in addition to the commit message with headline, stg\nmakes me invent yet _another_ name for every commit---yuck). Not to\nmention I'm already quite comfortable with git alone, and all the\nflexibility it provides.\n\nPlus, all the stuff that stg provides to allow it to be used\nstandalone ends up just being noise to the git user that just wants to\ndo some stack-based manipulation of an unpublished branch, for\nexample.\n\nSo, I'd really like to see something more integrated into git itself\nthat provides some of the missing functionality.\n\n-Carl\n"},{"id":"41767","messageId":"20070510195152.GS13719@fieldses.org","threadId":"8068","inReplyTo":"20070510194742.GC4489@pasky.or.cz","subject":"Re: Merging commits together into a super-commit","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-05-10T19:51:52Z","receivedAt":"2007-05-10T19:51:52Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, May 10, 2007 at 09:47:42PM +0200, Petr Baudis wrote:\n> Actually, you don't have to - if you don't specify the patch names,\n> stgit will make them up itself using the subject of the commit message\n> as a base.\n\nYou still have to on new patches, right?\n\n> And by the way, I absolutely love that - when viewing the stack, it's\n> very useful to see what commits you still have to go etc. - stg series\n> is concise yet fully descriptive.\n\nSure.\n\nI mainly find myself using gitk origin.. for that now.  My main problem\nthere is just that it's slow.  (And File->Update) seems possibly even\nslower than just killing and restarting it.--b.\n"},{"id":"41770","messageId":"20070510200253.GD4489@pasky.or.cz","threadId":"8068","inReplyTo":"87tzuk31fu.wl%cworth@cworth.org","subject":"Using StGIT for tweaking already-committed stuff","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-10T20:02:53Z","receivedAt":"2007-05-10T20:02:53Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, May 10, 2007 at 09:48:05PM CEST, Carl Worth wrote:\n> On Thu, 10 May 2007 21:21:06 +0200, Petr Baudis wrote:\n> > \tstg uncommit -n N\n> > \tstg pop -n N-1\n> > \t..hack..\n> > \tstg refresh\n> > \tstg push -a\n> >\n> > It seems to be a bit shorter than the sequence you've presented above,\n> > and overally working with volatile commits using StGIT feels much more\n> > natural to me - and I haven't even ever used quilt seriously! (I have\n> > special antipathy to the git reset UI, too.)\n> \n> The -n option is something I hadn't noticed, and that helps, (except\n> that what I've got to start with is a git revision name, not a\n> number).\n\nHmm, yes, I've been thinking myself that it would be quite nice if I\ncould just tell uncommit git revname right away.\n\n> But there are still some places where an experienced git user runs\n> into some awkward situations trying to use stg. For example, \"stg\n> refresh\" is basically always doing the equivalent of \"commit -a\" so\n> there's annoyingly no way to refresh only some of the modified state\n> into the commit.\n\nYes, I fear that StGIT hides the index in a similar way that Cogito\ndoes. It seems like user index usage is undergoing kind of renaissance\nthese days in Git community (at least it seems to me this way, maybe\nit's always been this way), it would probably make sense to allow making\nuse of index in StGIT as well.\n\n> Also, if I want to edit a commit message while under the influence of\n> stg, how do I do that? If I do \"git commit --amend\" will I seriously\n> confuse stg, (I'm guessing I would, but I don't know).\n\nI have no idea, but there's stg refresh -e.\n\n> It's that kind of uncertainty that makes me uncomfortable to mix git\n> and stg. And personally, I couldn't get excited about using it alone,\n> (for example, in addition to the commit message with headline, stg\n> makes me invent yet _another_ name for every commit---yuck). Not to\n> mention I'm already quite comfortable with git alone, and all the\n> flexibility it provides.\n\nI wouldn't normally use it for projects I have commit access to myself,\nbut for maintaining own patches for an \"external\" project, I just find\nit much more comfortable than using git. But then again, if this part of\ngit UI improved as much as some of the other parts in the last half a\nyear...\n\nAnd yes, it would be cool if stg new could guess patch name from the\nsubject line in a similar manner that stg uncommit does.\n\n> Plus, all the stuff that stg provides to allow it to be used\n> standalone ends up just being noise to the git user that just wants to\n> do some stack-based manipulation of an unpublished branch, for\n> example.\n\nI'm sorry, I couldn't parse this. :-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"41772","messageId":"200705102229.29221.robin.rosenberg.lists@dewire.com","threadId":"8068","inReplyTo":"87tzuk31fu.wl%cworth@cworth.org","subject":"Re: Merging commits together into a super-commit","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-05-10T20:29:28Z","receivedAt":"2007-05-10T20:29:28Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"torsdag 10 maj 2007 skrev Carl Worth:\n> But there are still some places where an experienced git user runs\n> into some awkward situations trying to use stg. For example, \"stg\n> refresh\" is basically always doing the equivalent of \"commit -a\" so\n> there's annoyingly no way to refresh only some of the modified state\n> into the commit.\n\nList the files to refresh and you get what you want.\n\n\tstg refresh file1 file2...\n\n> Also, if I want to edit a commit message while under the influence of\n> stg, how do I do that? If I do \"git commit --amend\" will I seriously\n> confuse stg, (I'm guessing I would, but I don't know).\n\n\tstg refresh -e\n\n[...]\n> Plus, all the stuff that stg provides to allow it to be used\n> standalone ends up just being noise to the git user that just wants to\n> do some stack-based manipulation of an unpublished branch, for\n> example.\n>\n> So, I'd really like to see something more integrated into git itself\n> that provides some of the missing functionality.\n\nI agree mixing stgit and git is not really comfy until you learn it and still\nI mess things up somtimes. Also rebase seems quite a bit faster than stgit, but I\nhave not intuitive understanding for rebase so I get scared everytime. Having\na gui that lets me mark commits and \"drag\" them to the new location would\nbe nice.\n\n-- robin\n"},{"id":"41776","messageId":"87sla42xc4.wl%cworth@cworth.org","threadId":"8068","inReplyTo":"20070510200253.GD4489@pasky.or.cz","subject":"Re: Using StGIT for tweaking already-committed stuff","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-05-10T21:16:43Z","receivedAt":"2007-05-10T21:16:43Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 10 May 2007 22:02:53 +0200, Petr Baudis wrote:\n>\n> I'm sorry, I couldn't parse this. :-)\n>\n\nI'll try again.\n\nI like the git user interface. I like it a lot. (It's got a couple of\ntiny things that I would do differently if I could start over, but\nmore importantly it has a lot of big things that I wouldn't have even\nthought of if I had started from scratch.)\n\nBut with respect to the current topic, there are a couple of features\nthat the git interface is missing compared to something like stg:\n\n1. Amend a commit that's somewhere besides the tip of a branch,\n   (rebuilding every commit that follows)\n\n2. Re-ordering commits that exist on a branch, (again, rebuilding\n   every commit that follows).\n\nAnd what I was trying to say in my confusing paragraph, is that if I\nlook to stg to add one or both pieces of this functionality, then it\ncomes with a lot of baggage. For example, \"stg --help\" lists about 38\nsub-commands. And some of those are wholly unnecessary if already\nusing git, (4 repository commands 6 working-copy commands, for\nexample). While others exist only to allow a notion of \"git commits\"\nvs. \"stg commits\" and translating back and forth between them,\n(assimilate and uncommit for example).\n\nNow, that's not a critique of stg itself. As you say, it can work\nreally well if you use it in a standalone fashion to track some\nproject.\n\nI'd just love to see something more minimal, and incorporated into git\nitself, to address the missing functionality. Right now, \"cherry-pick\nA..B\" is all I have to suggest. But maybe later there could be some\nsort of push/pop addition as well, (except that obviously the name\n\"push\" isn't available as a sub-command).\n\n-Carl\n"},{"id":"41788","messageId":"20070510222347.GB12366@diana.vm.bytemark.co.uk","threadId":"8068","inReplyTo":"20070510200253.GD4489@pasky.or.cz","subject":"Re: Using StGIT for tweaking already-committed stuff","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-10T22:23:47Z","receivedAt":"2007-05-10T22:23:47Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-10 22:02:53 +0200, Petr Baudis wrote:\n\n> On Thu, May 10, 2007 at 09:48:05PM CEST, Carl Worth wrote:\n>\n> > The -n option is something I hadn't noticed, and that helps,\n> > (except that what I've got to start with is a git revision name,\n> > not a number).\n>\n> Hmm, yes, I've been thinking myself that it would be quite nice if I\n> could just tell uncommit git revname right away.\n\nIt shouldn't be hard to do. Instead of uncommitting a fixed number of\ncommits, loop until you reach a specified commit.\n\n> > But there are still some places where an experienced git user runs\n> > into some awkward situations trying to use stg. For example, \"stg\n> > refresh\" is basically always doing the equivalent of \"commit -a\"\n> > so there's annoyingly no way to refresh only some of the modified\n> > state into the commit.\n>\n> Yes, I fear that StGIT hides the index in a similar way that Cogito\n> does. It seems like user index usage is undergoing kind of\n> renaissance these days in Git community (at least it seems to me\n> this way, maybe it's always been this way), it would probably make\n> sense to allow making use of index in StGIT as well.\n\nI agree. It's bad UI for StGIT to behave different from git, given\nthat easy interoperation is a goal.\n\n> > Also, if I want to edit a commit message while under the influence\n> > of stg, how do I do that? If I do \"git commit --amend\" will I\n> > seriously confuse stg, (I'm guessing I would, but I don't know).\n>\n> I have no idea, but there's stg refresh -e.\n\nYes, you would confuse it; the patch ref would still point to the old\ncommit object, but that would no longer be an ancestor of HEAD. StGIT\ndoesn't know how to recover from this, so you'd have to do it by hand,\nwhich is annoying.\n\nI'm working on making StGIT more robust against this kind of damage,\nbut I'm not quite done yet.\n\n> And yes, it would be cool if stg new could guess patch name from the\n> subject line in a similar manner that stg uncommit does.\n\nGood idea. This would be embarrassingly easy to do.\n\nBut you can kind of do it today. Just commit with git (my favorite\nhere is the emacs modes) and \"stg assimilate\"!\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"41812","messageId":"20070511054807.GA13880@efreet.light.src","threadId":"8068","inReplyTo":"87sla42xc4.wl%cworth@cworth.org","subject":"Integrate StGIT into Git? (Was: Re: Using StGIT for tweaking already-committed stuff)","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-05-11T05:48:07Z","receivedAt":"2007-05-11T05:48:07Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"Hello Folks,\n\nOn Thu, May 10, 2007 at 14:16:43 -0700, Carl Worth wrote:\n> I'll try again.\n> \n> I like the git user interface. I like it a lot. (It's got a couple of\n> tiny things that I would do differently if I could start over, but\n> more importantly it has a lot of big things that I wouldn't have even\n> thought of if I had started from scratch.)\n> \n> But with respect to the current topic, there are a couple of features\n> that the git interface is missing compared to something like stg:\n> \n> 1. Amend a commit that's somewhere besides the tip of a branch,\n>    (rebuilding every commit that follows)\n> \n> 2. Re-ordering commits that exist on a branch, (again, rebuilding\n>    every commit that follows).\n\nI would actually propose to (gradually) add stg functionality into git. If it\nwas done in stgit-compatible fashion, it would allow using stgit for the bits\nstill not ported to git and switching back and forth according to user's\ntaste.\n\nMany commands from stgit either already have git equivalent or do just\na little work beyond what the git command already does, so they could be\neasily integrated.\n\n> [...]\n> I'd just love to see something more minimal, and incorporated into git\n> itself, to address the missing functionality. Right now, \"cherry-pick\n> A..B\" is all I have to suggest. But maybe later there could be some\n> sort of push/pop addition as well, (except that obviously the name\n> \"push\" isn't available as a sub-command).\n\nI think that many of them would be actually pretty simple.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec <bulb@ucw.cz>\n"},{"id":"41858","messageId":"20070511204016.GH19253@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"8068","inReplyTo":"20070510222347.GB12366@diana.vm.bytemark.co.uk","subject":"Re: Using StGIT for tweaking already-committed stuff","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-05-11T20:40:17Z","receivedAt":"2007-05-11T20:40:17Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Fri, May 11, 2007 at 12:23:47AM +0200, Karl Hasselström wrote:\n> On 2007-05-10 22:02:53 +0200, Petr Baudis wrote:\n> > Yes, I fear that StGIT hides the index in a similar way that Cogito\n> > does. It seems like user index usage is undergoing kind of\n> > renaissance these days in Git community (at least it seems to me\n> > this way, maybe it's always been this way), it would probably make\n> > sense to allow making use of index in StGIT as well.\n> \n> I agree. It's bad UI for StGIT to behave different from git, given\n> that easy interoperation is a goal.\n\nWell, that's an idea that already appeared in some discussions - I\ncan't speak for Catalin, but I too think it could be a good thing.\n\nEg, if we're going to use the patchlogs a bit more (and I wish so), it\nwill be much less cluttered by using the index to select what to\ncommit with several git-add's, than when using several stg-refresh's.\n\nAs noted elsewhere, there are some commands that are a bit superfluous\n(add, rm, and the branch-switching feature directly come to mind).  It\nis especially annoying, eg when \"stg rm\" behaves differently than \"git\nrm\", by not removing the real file.  I have tried recently to avoid\nusing \"git add\" and \"stg rm\", and I am quite pleased with that :)\n\n\n> > And yes, it would be cool if stg new could guess patch name from the\n> > subject line in a similar manner that stg uncommit does.\n> \n> Good idea. This would be embarrassingly easy to do.\n> \n> But you can kind of do it today. Just commit with git (my favorite\n> here is the emacs modes) and \"stg assimilate\"!\n\nWell, that's arguably a non-orthodox way of doing things, I like the\nidea your \"stg new\" patch much better :)\n\nBest regards,\n-- \nYann.\n"},{"id":"41869","messageId":"20070511224325.GA13310@diana.vm.bytemark.co.uk","threadId":"8068","inReplyTo":"20070511204016.GH19253@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Using StGIT for tweaking already-committed stuff","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-11T22:43:25Z","receivedAt":"2007-05-11T22:43:25Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-11 22:40:17 +0200, Yann Dirson wrote:\n\n> On Fri, May 11, 2007 at 12:23:47AM +0200, Karl Hasselström wrote:\n>\n> > But you can kind of do it today. Just commit with git (my favorite\n> > here is the emacs modes) and \"stg assimilate\"!\n>\n> Well, that's arguably a non-orthodox way of doing things, I like the\n> idea your \"stg new\" patch much better :)\n\nIt's only unothodox if you expect git and stgit to not always mix so\nwell. But if we have the ambition that they should interoperate as\nnear to seamlessly as we can make them, this kind of workflow becomes\nvery natural.\n\nIt shouldn't be necessary with a manual \"assimilate\" step. If stgit\nfinds that there are unadorned git commits on top of the patch stack,\nit should do the assimilation automatically. With that in place, \"stg\nnew\" and \"stg refresh\" would be nearly superfluous, since git-commit\nwith and without --amend does the same thing -- the only thing they\nwon't do is give the user the option of manually choosing the patch\nname.\n\nI believe this sort of integration is the way to go. It'll be\nbeneficial for git users who want to occasionally use some stgit to\nrebase their patch series, since they'll not have to learn more than\ntwo or three new commands in addition to the git they already know.\nHeavy stgit users will benefit from having the much larger git\ncommunity maintaining a large subset of the porcelain they use,\ninstead of having to duplicate the effort and always lag behind.\n\nThis is no binary choice, of course. One could certainly imagine a\ncompromise where stgit becomes much easier to mix with git than today,\nbut still retains the current command set.\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"41897","messageId":"20070512071023.GD16903@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"8068","inReplyTo":"20070511224325.GA13310@diana.vm.bytemark.co.uk","subject":"Re: Using StGIT for tweaking already-committed stuff","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-05-12T07:10:23Z","receivedAt":"2007-05-12T07:10:23Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Sat, May 12, 2007 at 12:43:25AM +0200, Karl Hasselström wrote:\n> It's only unothodox if you expect git and stgit to not always mix so\n> well. But if we have the ambition that they should interoperate as\n> near to seamlessly as we can make them, this kind of workflow becomes\n> very natural.\n\nIt is great that this is possible, but I'm not sure I'll ever see it\nas \"very natural\" :)\n\n> It shouldn't be necessary with a manual \"assimilate\" step. If stgit\n> finds that there are unadorned git commits on top of the patch stack,\n> it should do the assimilation automatically. With that in place, \"stg\n> new\" and \"stg refresh\" would be nearly superfluous, since git-commit\n> with and without --amend does the same thing -- the only thing they\n> won't do is give the user the option of manually choosing the patch\n> name.\n\nHm.  I'm not that convinced :)\n\nEg, imagine a merge commit somewhere in the stack.  What would stgit\ndo with that ?\n\n> I believe this sort of integration is the way to go. It'll be\n> beneficial for git users who want to occasionally use some stgit to\n> rebase their patch series, since they'll not have to learn more than\n> two or three new commands in addition to the git they already know.\n> Heavy stgit users will benefit from having the much larger git\n> community maintaining a large subset of the porcelain they use,\n> instead of having to duplicate the effort and always lag behind.\n> \n> This is no binary choice, of course. One could certainly imagine a\n> compromise where stgit becomes much easier to mix with git than today,\n> but still retains the current command set.\n\nI quite like the idea of makeing it easier to mix them, and removing\nthe real duplicates from stgit, but I think that we should be careful\nnot to remove power from stgit while doing this.\n\nBest regards,\n-- \nYann.\n"},{"id":"41905","messageId":"20070512095312.GK19253@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"8068","inReplyTo":"87wszg39cp.wl%cworth@cworth.org","subject":"Transactions for git (and stgit) ?","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-05-12T09:53:12Z","receivedAt":"2007-05-12T09:53:12Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Thu, May 10, 2007 at 09:57:10AM -0700, Carl Worth wrote:\n> What I find myself wanting to type is just:\n> \n> \tgit cherry-pick A..B\n> \n> But there is the whole problem of how to deal with any conflict that\n> appears during the process.\n\nIndeed this is a problem we also have in StGIT, when pushing multiple\npatches after rebasing.  Currently we have to deal with the conflict\nand forge a new command-line to finish the job, which is quite awkward.\n\nIn this respect, the --continue/--skip/--abort set of flags that\ngit-rebase has are really useful.\n\nIn fact, I have plans to deal with such behaviours with stgit\ntransactions: in this case, we have the need of user interaction in\nthe middle of a transaction, and the rebase flags mentionned above are\njust a way for the user of continuing or aborting the transaction.\n\nHowever, currently I'm not sure that git-rebase would be very robust\nif the user would mess with HEAD before issuing one of these commands.\nMaybe git would also benefit from a generic transaction mechanism of\nsome sort, so \"cherry-pick A..B\" and possibly others can behave in a\nconsistent way with rebase ?\n\nIt could even be more sensible to implement transactions at the git\nlevel rather than at the stgit one...\n\nBest regards,\n-- \nYann.\n"},{"id":"41907","messageId":"20070512104919.GA22735@diana.vm.bytemark.co.uk","threadId":"8068","inReplyTo":"20070512095312.GK19253@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Transactions for git (and stgit) ?","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-12T10:49:19Z","receivedAt":"2007-05-12T10:49:19Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-12 11:53:12 +0200, Yann Dirson wrote:\n\n> It could even be more sensible to implement transactions at the git\n> level rather than at the stgit one...\n\nYes, please. (Unless a convincing technical argument pops up against\nit, of course.) Any stgit invariant that isn't based on a git\ninvariant is one more thing that can break when git and stgit commands\nare mixed.\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"41911","messageId":"20070512110955.GB22735@diana.vm.bytemark.co.uk","threadId":"8068","inReplyTo":"20070512071023.GD16903@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Using StGIT for tweaking already-committed stuff","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-12T11:09:55Z","receivedAt":"2007-05-12T11:09:55Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-12 09:10:23 +0200, Yann Dirson wrote:\n\n> On Sat, May 12, 2007 at 12:43:25AM +0200, Karl Hasselström wrote:\n>\n> > It shouldn't be necessary with a manual \"assimilate\" step. If\n> > stgit finds that there are unadorned git commits on top of the\n> > patch stack, it should do the assimilation automatically. With\n> > that in place, \"stg new\" and \"stg refresh\" would be nearly\n> > superfluous, since git-commit with and without --amend does the\n> > same thing -- the only thing they won't do is give the user the\n> > option of manually choosing the patch name.\n>\n> Hm. I'm not that convinced :)\n>\n> Eg, imagine a merge commit somewhere in the stack. What would stgit\n> do with that ?\n\nThere are two cases:\n\n  1. The merge commit is below the bottommost patch. This is perfectly\n     OK, and nothing special has to be done. The only restriction is\n     that we can't uncommit past the merge.\n\n  2. The merge commit is above the topmost patch. (There may or may\n     not also be other not-yet-stgitified commits above the topmost\n     patch, below or above the merge commit.) In this case, stgit\n     should not auto-assimilate the commits on top of the stack (since\n     it can't be done for the merge commit), and a number of stgit\n     commands (push, pop, new, ...) should refuse to work until the\n     user has either reset the branch so that the merge disappears, or\n     done \"stg commit\" on all the patches below the merge.\n\nNote that these are the only cases: stgit should (and does) enforce\nthe invariant that the applied patches form a consecutive series of\ncommits, without \"holes\". This is why \"stg new\" would be forbidden in\ncase (2).\n\nThe point is not that you should commit merges on top of your patches,\nof course. The point is that if you do, stgit should handle it\ngracefully. Right now you can commit all your patches and do a merge,\nbut if you try to do it the other way around, stgit will break down on\nyou -- but there's no real reason why it should.\n\n> I quite like the idea of makeing it easier to mix them, and removing\n> the real duplicates from stgit, but I think that we should be\n> careful not to remove power from stgit while doing this.\n\nI agree.\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"41916","messageId":"20070512113430.GL19253@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"8068","inReplyTo":"87tzuk31fu.wl%cworth@cworth.org","subject":"Re: Merging commits together into a super-commit","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-05-12T11:34:30Z","receivedAt":"2007-05-12T11:34:30Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Thu, May 10, 2007 at 12:48:05PM -0700, Carl Worth wrote:\n> On Thu, 10 May 2007 21:21:06 +0200, Petr Baudis wrote:\n> > I think you are underestimating stg here.\n> \n> Yes, maybe I didn't learn to use it well enough.\n> \n> > You can stg init just once per branch (ever), I think.\n> \n> I don't have details now, but I know I ran into some difficulty when\n> leaving the extra stg state around.\n\nI really think we should have a \"stg uninit\" command.  Note that\ncurrently \"stg branch --delete\" on master will just do that instead of\nreally deleting the branch, but that is a known bug (#8732 on gna).\n\n> It seems that it added stuff that\n> resulted in some reference of mine becoming ambiguous, (\"refspec <foo>\n> matches more than one\" perhaps?). What I do remember is that I couldn't\n> get one of my standard git push commands to work until I deleted all\n> of .git/refs/bases and .git/refs/patches and then things started to\n> work again.\n\nI remember quite some time ago that cg-push exhibited this behaviour.\nHowever, nowadays I frequently push stgit stacks with git-push without\na problem.\n\n> > \tstg uncommit -n N\n> > \tstg pop -n N-1\n> > \t..hack..\n> > \tstg refresh\n> > \tstg push -a\n> >\n> > It seems to be a bit shorter than the sequence you've presented above,\n> > and overally working with volatile commits using StGIT feels much more\n> > natural to me - and I haven't even ever used quilt seriously! (I have\n> > special antipathy to the git reset UI, too.)\n> \n> The -n option is something I hadn't noticed, and that helps, (except\n> that what I've got to start with is a git revision name, not a\n> number).\n\nWhile \"uncommit to named commit\" that Karl implemented helps here, and\nthat \"stg goto <patchname>\" may be a viable alternative to \"pop -n\",\nyou may also want to try:\n\n\tstg uncommit -t <commit>\n\t..hack..\n\tstg refresh -p <patchname>\n\nThere are still some rough edges with \"refresh -p\", though[*], but\nwhen it works I love this comfort :)\n\nBest regards,\n-- \nYann.\n\n[*] most notably, it does not work yet if any patch above the one you\nwant to modify changes the same file)\n"},{"id":"41920","messageId":"f24gv6$otc$1@sea.gmane.org","threadId":"8068","inReplyTo":"20070512113430.GL19253@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Merging commits together into a super-commit","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-12T13:59:24Z","receivedAt":"2007-05-12T13:59:24Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Yann Dirson wrote:\n\n> On Thu, May 10, 2007 at 12:48:05PM -0700, Carl Worth wrote:\n>> On Thu, 10 May 2007 21:21:06 +0200, Petr Baudis wrote:\n>> > I think you are underestimating stg here.\n>> \n>> Yes, maybe I didn't learn to use it well enough.\n>> \n>> > You can stg init just once per branch (ever), I think.\n>> \n>> I don't have details now, but I know I ran into some difficulty when\n>> leaving the extra stg state around.\n> \n> I really think we should have a \"stg uninit\" command.  Note that\n> currently \"stg branch --delete\" on master will just do that instead of\n> really deleting the branch, but that is a known bug (#8732 on gna).\n\nIt would be also nice to have command to remove applied patches.\nSometimes I'd muck up StGIT stack by rebasing in git. Applied patches\nare in repository, but I'm interested in preserving unapplied ones.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"41923","messageId":"20070512140228.GB28039@diana.vm.bytemark.co.uk","threadId":"8068","inReplyTo":"20070512113430.GL19253@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Merging commits together into a super-commit","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-12T14:02:28Z","receivedAt":"2007-05-12T14:02:28Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-12 13:34:30 +0200, Yann Dirson wrote:\n\n> I really think we should have a \"stg uninit\" command. Note that\n> currently \"stg branch --delete\" on master will just do that instead\n> of really deleting the branch, but that is a known bug (#8732 on\n> gna).\n\nWhat we should do is delete all stgit metadata when the last patch\ngoes away.\n\nAnd we shouldn't have \"stg init\", either. Initing should be done\nautomatically when needed.\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"41926","messageId":"20070512144145.GF16903@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"8068","inReplyTo":"20070512140228.GB28039@diana.vm.bytemark.co.uk","subject":"Re: Merging commits together into a super-commit","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-05-12T14:41:45Z","receivedAt":"2007-05-12T14:41:45Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Sat, May 12, 2007 at 04:02:28PM +0200, Karl Hasselström wrote:\n> On 2007-05-12 13:34:30 +0200, Yann Dirson wrote:\n> \n> > I really think we should have a \"stg uninit\" command. Note that\n> > currently \"stg branch --delete\" on master will just do that instead\n> > of really deleting the branch, but that is a known bug (#8732 on\n> > gna).\n> \n> What we should do is delete all stgit metadata when the last patch\n> goes away.\n\nThis supposes there is no valuable branch-level metadata.  Currently\nwe have the description - something which could arguably be moved to\nthe git level as well.  Otherwise that sounds reasonable to me.\n\n> And we shouldn't have \"stg init\", either. Initing should be done\n> automatically when needed.\n\nGood idea as well, that would make stg more accessible to the average\nplain-git user.\n\nBest regards,\n-- \nYann.\n"},{"id":"41939","messageId":"20070512170304.GC28039@diana.vm.bytemark.co.uk","threadId":"8068","inReplyTo":"20070512144145.GF16903@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Merging commits together into a super-commit","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-12T17:03:04Z","receivedAt":"2007-05-12T17:03:04Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-12 16:41:45 +0200, Yann Dirson wrote:\n\n> On Sat, May 12, 2007 at 04:02:28PM +0200, Karl Hasselström wrote:\n>\n> > What we should do is delete all stgit metadata when the last patch\n> > goes away.\n>\n> This supposes there is no valuable branch-level metadata. Currently\n> we have the description - something which could arguably be moved to\n> the git level as well. Otherwise that sounds reasonable to me.\n\nI left the branch description out of the discussion on purpose, since\nit's not that interesting -- if there is a description, we can simply\ndelete everything except that. And I wholeheartedly agree that the\nbranch description doesn't belong in stgit; it's orthogonal to the\nbusiness of managing a patch stack.\n\n> > And we shouldn't have \"stg init\", either. Initing should be done\n> > automatically when needed.\n>\n> Good idea as well, that would make stg more accessible to the\n> average plain-git user.\n\nYes, that's my secret evil master plan.\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"41945","messageId":"20070512183443.GM19253@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"8068","inReplyTo":"20070512104919.GA22735@diana.vm.bytemark.co.uk","subject":"Re: Transactions for git (and stgit) ?","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-05-12T18:34:43Z","receivedAt":"2007-05-12T18:34:43Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Sat, May 12, 2007 at 12:49:19PM +0200, Karl Hasselström wrote:\n> On 2007-05-12 11:53:12 +0200, Yann Dirson wrote:\n> \n> > It could even be more sensible to implement transactions at the git\n> > level rather than at the stgit one...\n> \n> Yes, please. (Unless a convincing technical argument pops up against\n> it, of course.) Any stgit invariant that isn't based on a git\n> invariant is one more thing that can break when git and stgit commands\n> are mixed.\n\nFor reference, I have written down some design ideas in january[1].\nThey were written with StGIT in mind, we'll have to see if it\ntransposes easily to plain git.\n\nI fear it will not be that easy, at least with this design :)\n\nOTOH, implementing transactions in StGIT could provide a first\nexperience on this particular field, that may later be transposed to\ngit core - not unlike cogito did for other features.  There is the\nrisk, however, of seeing a different (hopefully better) design for the\nfeature in git afterwards, and this in turn is likely to make life\nharder for StGIT...\n\n[1] http://marc.info/?t=116803935800001&r=1&w=2\n\nBest regards,\n-- \nYann.\n"},{"id":"41952","messageId":"7vy7jtyh8q.fsf@assigned-by-dhcp.cox.net","threadId":"8068","inReplyTo":"20070512144145.GF16903@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Merging commits together into a super-commit","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-12T19:27:49Z","receivedAt":"2007-05-12T19:27:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Yann Dirson <ydirson@altern.org> writes:\n\n> On Sat, May 12, 2007 at 04:02:28PM +0200, Karl Hasselström wrote:\n>> ...\n>> What we should do is delete all stgit metadata when the last patch\n>> goes away.\n>\n> This supposes there is no valuable branch-level metadata.  Currently\n> we have the description - something which could arguably be moved to\n> the git level as well.  Otherwise that sounds reasonable to me.\n\nWill it be something like\n\n\t[branch \"master\"]\n        \tdescription = \"My primary development line\"\n\nif so I think that is a reasonable thing to do, from git-core's\npoint of view.  Obviously, gitk, tig, gitweb and friends can use\nthis, too.\n\nAre there other per-branch information StGIT wants to keep on an\nactive branch that might benefit the core as well?\n\n>> And we shouldn't have \"stg init\", either. Initing should be done\n>> automatically when needed.\n>\n> Good idea as well, that would make stg more accessible to the average\n> plain-git user.\n\nYes, I wished for this often myself.\n"},{"id":"42041","messageId":"20070513184327.GA14078@diana.vm.bytemark.co.uk","threadId":"8068","inReplyTo":"7vy7jtyh8q.fsf@assigned-by-dhcp.cox.net","subject":"Re: Merging commits together into a super-commit","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-13T18:43:27Z","receivedAt":"2007-05-13T18:43:27Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-12 12:27:49 -0700, Junio C Hamano wrote:\n\n> Yann Dirson <ydirson@altern.org> writes:\n>\n> > This supposes there is no valuable branch-level metadata.\n> > Currently we have the description - something which could arguably\n> > be moved to the git level as well. Otherwise that sounds\n> > reasonable to me.\n>\n> Will it be something like\n>\n>       [branch \"master\"]\n>               description = \"My primary development line\"\n\nYes, exactly. It's just a simple per-branch description string, just\nlike in your suggestion.\n\n> if so I think that is a reasonable thing to do, from git-core's\n> point of view. Obviously, gitk, tig, gitweb and friends can use\n> this, too.\n\nAbsolutely.\n\n> Are there other per-branch information StGIT wants to keep on an\n> active branch that might benefit the core as well?\n\nNo, I'm pretty sure there isn't.\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"42050","messageId":"20070513193507.GN19253@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"8068","inReplyTo":"7vy7jtyh8q.fsf@assigned-by-dhcp.cox.net","subject":"Re: Merging commits together into a super-commit","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-05-13T19:35:08Z","receivedAt":"2007-05-13T19:35:08Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Sat, May 12, 2007 at 12:27:49PM -0700, Junio C Hamano wrote:\n> Are there other per-branch information StGIT wants to keep on an\n> active branch that might benefit the core as well?\n\nMaybe the \"protected\" attribute, to forbid commands to touch to the\nstack ?  Not sure, however, since the semantics would probably be a\nbit different in git (eg. just forbid update-ref) and in StGIT (also\nprotects unapplied patches).\n\nBest regards,\n-- \nYann\n"},{"id":"42162","messageId":"20070514192528.26543.75736.stgit@yoghurt","threadId":"8068","inReplyTo":"7vy7jtyh8q.fsf@assigned-by-dhcp.cox.net","subject":"[StGIT PATCH] Store branch description in the config file","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-14T19:28:10Z","receivedAt":"2007-05-14T19:28:10Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"Instead of storing the branch description in an StGIT-specific file,\nstore it in the git config file, where tools other than StGIT can read\nand write it.\n\nSigned-off-by: Karl Hasselström <kha@treskal.com>\n---\n\nOn 2007-05-12 12:27:49 -0700, Junio C Hamano wrote:\n\n> Will it be something like\n>\n>       [branch \"master\"]\n>               description = \"My primary development line\"\n\nThis was easier to do than I'd thought. I don't get quotes around the\ndescription, though; do I have to insert them manually? And what\npurpose do they serve?\n\n stgit/stack.py |   19 ++++++++++++++-----\n 1 files changed, 14 insertions(+), 5 deletions(-)\n\ndiff --git a/stgit/stack.py b/stgit/stack.py\nindex c105b21..7048af7 100644\n--- a/stgit/stack.py\n+++ b/stgit/stack.py\n@@ -451,7 +451,6 @@ class Series(StgitObject):\n                                        self.__name)\n \n         self.__hidden_file = os.path.join(self._dir(), 'hidden')\n-        self.__descr_file = os.path.join(self._dir(), 'description')\n \n         # where this series keeps its patches\n         self.__patch_dir = os.path.join(self._dir(), 'patches')\n@@ -550,11 +549,23 @@ class Series(StgitObject):\n         if os.path.isfile(protect_file):\n             os.remove(protect_file)\n \n+    def __branch_descr(self):\n+        return 'branch.%s.description' % self.get_branch()\n+\n     def get_description(self):\n-        return self._get_field('description') or ''\n+        # Fall back to the .git/patches/<branch>/description file if\n+        # the config variable is unset.\n+        return (config.get(self.__branch_descr())\n+                or self._get_field('description') or '')\n \n     def set_description(self, line):\n-        self._set_field('description', line)\n+        if line:\n+            config.set(self.__branch_descr(), line)\n+        else:\n+            config.unset(self.__branch_descr())\n+        # Delete the old .git/patches/<branch>/description file if it\n+        # exists.\n+        self._set_field('description', None)\n \n     def get_parent_remote(self):\n         value = config.get('branch.%s.remote' % self.__name)\n@@ -787,8 +798,6 @@ class Series(StgitObject):\n             # (move functionality to StgitObject ?)\n             if os.path.exists(self.__hidden_file):\n                 os.remove(self.__hidden_file)\n-            if os.path.exists(self.__descr_file):\n-                os.remove(self.__descr_file)\n             if os.path.exists(self._dir()+'/orig-base'):\n                 os.remove(self._dir()+'/orig-base')\n \n"}]}