{"thread":{"id":"11038","subject":"stgit: lost all my patches again","startedAt":"2007-11-27T22:17:12Z","lastAt":"2007-11-30T06:35:50Z","messageCount":26,"participants":["Jon Smirl","Jakub Narebski","Junio C Hamano","Karl Hasselström","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"61129","messageId":"9e4733910711271417l32ed9a77p9915aa34a780665b@mail.gmail.com","threadId":"11038","inReplyTo":null,"subject":"stgit: lost all my patches again","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2007-11-27T22:17:12Z","receivedAt":"2007-11-27T22:17:12Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"My fingers are too trained in doing \"git rebase linus/master\" instead\nof \"stg rebase linus/master\". This has resulting in me losing my patch\nstack again. I updated stg to the current version and tried \"stg\nrepair\" put all my patches are still empty.\n\nWhat's the easiest way to recover?\n\nCan we add a check in \"git rebase\" so that it will refuse to run if\nstg is active?\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"61130","messageId":"fii5dv$qc4$1@ger.gmane.org","threadId":"11038","inReplyTo":"9e4733910711271417l32ed9a77p9915aa34a780665b@mail.gmail.com","subject":"Re: stgit: lost all my patches again","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-27T22:24:02Z","receivedAt":"2007-11-27T22:24:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jon Smirl wrote:\n\n> My fingers are too trained in doing \"git rebase linus/master\" instead\n> of \"stg rebase linus/master\". This has resulting in me losing my patch\n> stack again. I updated stg to the current version and tried \"stg\n> repair\" put all my patches are still empty.\n> \n> What's the easiest way to recover?\n\ngit reset --hard $(cat .git/patches//orig-base)\n\nor perhaps \"git reset --hard ORIG_HEAD\"; with new rebase working on\ndetached head \"git reset --hard @{1}\".\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"61132","messageId":"9e4733910711271512g790364e0ka4839b2be9fd4935@mail.gmail.com","threadId":"11038","inReplyTo":"9e4733910711271417l32ed9a77p9915aa34a780665b@mail.gmail.com","subject":"Re: stgit: lost all my patches again","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2007-11-27T23:12:49Z","receivedAt":"2007-11-27T23:12:49Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 11/27/07, Jon Smirl wrote:\n> My fingers are too trained in doing \"git rebase linus/master\" instead\n> of \"stg rebase linus/master\". This has resulting in me losing my patch\n> stack again. I updated stg to the current version and tried \"stg\n> repair\" put all my patches are still empty.\n>\n> What's the easiest way to recover?\n\nI recovered, which wasn't too bad since I had exported the stack about\nan hour earlier. I played around trying to recover the tree for a\nwhile and then gave up and whacked it. I used my export and then I\nextracted the last hours worth of changes from the old tree.\n\nAs Jakub pointed out to me \"git reset --hard $(cat\n.git/patches//orig-base)\" would have recovered from the rebase\ncommand. But I had already typed 'stg repair' which compounded the\nmess.\n\n> Can we add a check in \"git rebase\" so that it will refuse to run if\n> stg is active?\n\nThis is way too easy to do. One simple mistype of 'git' for 'stg' and\nyou're in a mess.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"61141","messageId":"7vr6ibb3x7.fsf@gitster.siamese.dyndns.org","threadId":"11038","inReplyTo":"9e4733910711271417l32ed9a77p9915aa34a780665b@mail.gmail.com","subject":"Re: stgit: lost all my patches again","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-28T00:37:56Z","receivedAt":"2007-11-28T00:37:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Jon Smirl\" writes:\n\n> Can we add a check in \"git rebase\" so that it will refuse to run if\n> stg is active?\n\nThe pre-rebase hook has been there since early Feb 2006.\n"},{"id":"61154","messageId":"9e4733910711271859w7b7dc141q93e3c9f67693a54@mail.gmail.com","threadId":"11038","inReplyTo":"7vr6ibb3x7.fsf@gitster.siamese.dyndns.org","subject":"Re: stgit: lost all my patches again","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2007-11-28T02:59:00Z","receivedAt":"2007-11-28T02:59:00Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 11/27/07, Junio C Hamano wrote:\n> \"Jon Smirl\" writes:\n>\n> > Can we add a check in \"git rebase\" so that it will refuse to run if\n> > stg is active?\n>\n> The pre-rebase hook has been there since early Feb 2006.\n\nKarl, Catalin, can stgit install a pre-rebase hook and disable 'git\nrebase' when stg is active on the branch? This would keep me from\ndestroying my patch stack when my fingers get ahead of me. Might be\ngood to disable anything else that can cause damage too.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"61176","messageId":"20071128063245.GA11163@diana.vm.bytemark.co.uk","threadId":"11038","inReplyTo":"9e4733910711271859w7b7dc141q93e3c9f67693a54@mail.gmail.com","subject":"Re: stgit: lost all my patches again","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-11-28T06:32:45Z","receivedAt":"2007-11-28T06:32:45Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-11-27 21:59:00 -0500, Jon Smirl wrote:\n\n> Karl, Catalin, can stgit install a pre-rebase hook and disable 'git\n> rebase' when stg is active on the branch? This would keep me from\n> destroying my patch stack when my fingers get ahead of me. Might be\n> good to disable anything else that can cause damage too.\n\nMmmm. We'd have to define \"damage\"; \"stg repair\" can take care of\nquite a lot of things nowadays. Committing new stuff on top of a patch\nseries is no problem, for example, and \"git reset --hard HEAD^ && stg\nrepair\" is equivalent to \"stg pop\". I can see how \"git rebase\" would\nstill be a nuisance, though.\n\nPatch? :-)\n\nPresumably, we'd want the hook to be a Python script, so as to\n\n * not make it more difficult to port StGit to Windows someday;\n\n * make it possible for the hook to call StGit functions; and\n\n * not force the project's contributors to learn more shell scripting\n than they have to. :-)\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"61148","messageId":"20071128093403.GB12977@diana.vm.bytemark.co.uk","threadId":"11038","inReplyTo":"9e4733910711271512g790364e0ka4839b2be9fd4935@mail.gmail.com","subject":"Re: stgit: lost all my patches again","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-11-28T09:34:03Z","receivedAt":"2007-11-28T09:34:03Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-11-27 18:12:49 -0500, Jon Smirl wrote:\n\n> As Jakub pointed out to me \"git reset --hard $(cat\n> .git/patches//orig-base)\" would have recovered from the\n> rebase command. But I had already typed 'stg repair' which\n> compounded the mess.\n\nUnless it has a bug, the only thing \"stg repair\" will do is\n\n * create some new applied patches out of commits reachable from HEAD\n\n * mark some applied patches as unapplied\n\n * mark some unapplied patches as applied\n\nin order to make sure that the applied patches are precisely those\nthat are reachable from HEAD, and that the sequence of applied patches\ndoesn't have \"holes\" in it (that is, commits that aren't patches).\n\nIn particular, it should not ever modify your existing patches, and it\nwill never move the branch head. Just resetting the branch head to\nwherever you want it to be (and then running repair again) should fix\nliterally all problems.\n\n> This is way too easy to do. One simple mistype of 'git' for 'stg'\n> and you're in a mess.\n\nYou're right, this is not user friendly. A pre-rebase hook sounds like\na reasonable idea.\n\nIt would also be convenient with a post-commit hook that turns new\ncommits into patches automatically. And gives \"git commit --amend\" the\nsemantics of \"stg refresh\".\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"61146","messageId":"20071128101718.GA13940@diana.vm.bytemark.co.uk","threadId":"11038","inReplyTo":"20071128093403.GB12977@diana.vm.bytemark.co.uk","subject":"StGit hooks","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-11-28T10:17:18Z","receivedAt":"2007-11-28T10:17:18Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-11-28 10:34:03 +0100, Karl Hasselström wrote:\n\n> It would also be convenient with a post-commit hook that turns new\n> commits into patches automatically. And gives \"git commit --amend\"\n> the semantics of \"stg refresh\".\n\nHmm, so what I'd want for this is a hook that gets called every time a\nbranch ref is updated (after the update), preferably with the ref name\nand its old and new values as arguments (but as long as I get the ref\nname, I guess I could just ask git for the sha1s?). Is there such a\nhook? I poked around a bit, but couldn't find any.\n\nFor extra points, I'd like to know what operation caused the ref\nupdate. I'd want to do different things depending on whether the user\ndid a \"commit\" or \"commit --amend\", for example. I could use a\nheuristic, but I'd rather not if there's a way to know for sure. (Hmm.\nIt looks like the reflog messages could be used here. Are they stable\nenough?)\n\nAlso, if StGit is to set up hooks automatically (commit hooks,\npre-rebase hooks, whatever), it'd be nice to not have to worry about\noverwriting any existing hooks the user might have. But git currently\nallows only one hook script per hook, right?\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"61153","messageId":"474D5482.5020609@op5.se","threadId":"11038","inReplyTo":"20071128101718.GA13940@diana.vm.bytemark.co.uk","subject":"Re: StGit hooks","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-28T11:44:02Z","receivedAt":"2007-11-28T11:44:02Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Karl Hasselström wrote:\n> \n> Also, if StGit is to set up hooks automatically (commit hooks,\n> pre-rebase hooks, whatever), it'd be nice to not have to worry about\n> overwriting any existing hooks the user might have. But git currently\n> allows only one hook script per hook, right?\n> \n\nYes, but you can obviously call any number of scripts and programs\nfrom within the hook that git executes.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"61161","messageId":"20071128121905.GA15953@diana.vm.bytemark.co.uk","threadId":"11038","inReplyTo":"474D5482.5020609@op5.se","subject":"Re: StGit hooks","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-11-28T12:19:05Z","receivedAt":"2007-11-28T12:19:05Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-11-28 12:44:02 +0100, Andreas Ericsson wrote:\n\n> Karl Hasselström wrote:\n>\n> > Also, if StGit is to set up hooks automatically (commit hooks,\n> > pre-rebase hooks, whatever), it'd be nice to not have to worry\n> > about overwriting any existing hooks the user might have. But git\n> > currently allows only one hook script per hook, right?\n>\n> Yes, but you can obviously call any number of scripts and programs\n> from within the hook that git executes.\n\nThat doesn't help here, however, since the user and not StGit \"owns\"\nthe \"top-level\" hook. StGit would have to rely on the user having\ninstalled a specific kind of multiplexer as a hook script (e.g. one\nthat executes everything under .git/hooks/$hook.d/). Or it would have\nto install it itself, and hope that moving any existing hook to the\nsubdirectory where the multiplexer looks for hooks doesn't break\nanything. Both solutions are problematic.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"61182","messageId":"474D69A7.6020404@op5.se","threadId":"11038","inReplyTo":"20071128121905.GA15953@diana.vm.bytemark.co.uk","subject":"Re: StGit hooks","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-28T13:14:15Z","receivedAt":"2007-11-28T13:14:15Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Karl Hasselström wrote:\n> On 2007-11-28 12:44:02 +0100, Andreas Ericsson wrote:\n> \n>> Karl Hasselström wrote:\n>>\n>>> Also, if StGit is to set up hooks automatically (commit hooks,\n>>> pre-rebase hooks, whatever), it'd be nice to not have to worry\n>>> about overwriting any existing hooks the user might have. But git\n>>> currently allows only one hook script per hook, right?\n>> Yes, but you can obviously call any number of scripts and programs\n>> from within the hook that git executes.\n> \n> That doesn't help here, however, since the user and not StGit \"owns\"\n> the \"top-level\" hook. StGit would have to rely on the user having\n> installed a specific kind of multiplexer as a hook script (e.g. one\n> that executes everything under .git/hooks/$hook.d/). Or it would have\n> to install it itself, and hope that moving any existing hook to the\n> subdirectory where the multiplexer looks for hooks doesn't break\n> anything. Both solutions are problematic.\n> \n\n\nThe user-defined hook can be kept in the hooks directory too. It just\nneeds to be named in such a way that git will never have a hook named\nlike that. For that reason, I think it would be easiest to just agree\nfor the git core to never call any hooks prefixed with \"stgit\" or\nsome such. I think the odds for it happening by chance are remote, to\nsay the least.\n\n---%<---%<---\n#!/bin/sh\n\ndo_stgit_things\n\nsh -c '\"$GIT_DIR/hooks/pre-stgit-$action-hook\" \"$@\"'\nexit $?\n---%<---%<---\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"61191","messageId":"20071128132605.GB15953@diana.vm.bytemark.co.uk","threadId":"11038","inReplyTo":"474D69A7.6020404@op5.se","subject":"Re: StGit hooks","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-11-28T13:26:05Z","receivedAt":"2007-11-28T13:26:05Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-11-28 14:14:15 +0100, Andreas Ericsson wrote:\n\n> Karl Hasselström wrote:\n>\n> > On 2007-11-28 12:44:02 +0100, Andreas Ericsson wrote:\n> >\n> > > Karl Hasselström wrote:\n> > >\n> > > > Also, if StGit is to set up hooks automatically (commit hooks,\n> > > > pre-rebase hooks, whatever), it'd be nice to not have to worry\n> > > > about overwriting any existing hooks the user might have. But\n> > > > git currently allows only one hook script per hook, right?\n> > >\n> > > Yes, but you can obviously call any number of scripts and\n> > > programs from within the hook that git executes.\n> >\n> > That doesn't help here, however, since the user and not StGit\n> > \"owns\" the \"top-level\" hook. StGit would have to rely on the user\n> > having installed a specific kind of multiplexer as a hook script\n> > (e.g. one that executes everything under .git/hooks/$hook.d/). Or\n> > it would have to install it itself, and hope that moving any\n> > existing hook to the subdirectory where the multiplexer looks for\n> > hooks doesn't break anything. Both solutions are problematic.\n>\n> The user-defined hook can be kept in the hooks directory too. It\n> just needs to be named in such a way that git will never have a hook\n> named like that. For that reason, I think it would be easiest to\n> just agree for the git core to never call any hooks prefixed with\n> \"stgit\" or some such. I think the odds for it happening by chance\n> are remote, to say the least.\n\nYou've lost me. :-/\n\nTake the pre-commit hook as an example. git will call\n\".git/hooks/pre-commit\" when interesting stuff happens. Now StGit\nwants to install its pre-commit hook in an existing repository, and\nfinds that there already is a file called \".git/hooks/pre-commit\".\nWhat should it do?\n\nIt could move \".git/hooks/pre-commit\" to\n\".git/hooks/pre-commit.d/user_hook\", install its own hook in\n\".git/hooks/pre-commit.d/stgit_hook\", and install a multiplexer at\n\".git/hooks/pre-commit\". But that makes some assumptions, e.g. that\nthe user's hook can handle being moved, and that the user is fine with\nthis.\n\nI don't see a good way around this other than having git mandate the\nmultiplexing scheme.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"61201","messageId":"474D7710.4090303@op5.se","threadId":"11038","inReplyTo":"20071128132605.GB15953@diana.vm.bytemark.co.uk","subject":"Re: StGit hooks","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-28T14:11:28Z","receivedAt":"2007-11-28T14:11:28Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Karl Hasselström wrote:\n> On 2007-11-28 14:14:15 +0100, Andreas Ericsson wrote:\n> \n>> Karl Hasselström wrote:\n>>\n>>> On 2007-11-28 12:44:02 +0100, Andreas Ericsson wrote:\n>>>\n>>>> Karl Hasselström wrote:\n>>>>\n>>>>> Also, if StGit is to set up hooks automatically (commit hooks,\n>>>>> pre-rebase hooks, whatever), it'd be nice to not have to worry\n>>>>> about overwriting any existing hooks the user might have. But\n>>>>> git currently allows only one hook script per hook, right?\n>>>> Yes, but you can obviously call any number of scripts and\n>>>> programs from within the hook that git executes.\n>>> That doesn't help here, however, since the user and not StGit\n>>> \"owns\" the \"top-level\" hook. StGit would have to rely on the user\n>>> having installed a specific kind of multiplexer as a hook script\n>>> (e.g. one that executes everything under .git/hooks/$hook.d/). Or\n>>> it would have to install it itself, and hope that moving any\n>>> existing hook to the subdirectory where the multiplexer looks for\n>>> hooks doesn't break anything. Both solutions are problematic.\n>> The user-defined hook can be kept in the hooks directory too. It\n>> just needs to be named in such a way that git will never have a hook\n>> named like that. For that reason, I think it would be easiest to\n>> just agree for the git core to never call any hooks prefixed with\n>> \"stgit\" or some such. I think the odds for it happening by chance\n>> are remote, to say the least.\n> \n> You've lost me. :-/\n> \n> Take the pre-commit hook as an example. git will call\n> \".git/hooks/pre-commit\" when interesting stuff happens. Now StGit\n> wants to install its pre-commit hook in an existing repository, and\n> finds that there already is a file called \".git/hooks/pre-commit\".\n> What should it do?\n> \n\nMove the existing hook to \".git/hooks/stgit-moved.pre-commit\". So\nlong as the hook doesn't care what its named (which would only matter\nin the insane case where the repository has a single hook with a lot\nof links going to it), this will work with relative paths that worked\nearlier.\n\n> It could move \".git/hooks/pre-commit\" to\n> \".git/hooks/pre-commit.d/user_hook\", install its own hook in\n> \".git/hooks/pre-commit.d/stgit_hook\", and install a multiplexer at\n> \".git/hooks/pre-commit\". But that makes some assumptions, e.g. that\n> the user's hook can handle being moved, and that the user is fine with\n> this.\n> \n> I don't see a good way around this other than having git mandate the\n> multiplexing scheme.\n> \n\nMultiplexing the execution of those hooks would be a very bad idea\nindeed, but that's a different issue.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"61212","messageId":"9e4733910711280653q119f2c2n173eaebdda6cd774@mail.gmail.com","threadId":"11038","inReplyTo":"474D7710.4090303@op5.se","subject":"Re: StGit hooks","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2007-11-28T14:53:55Z","receivedAt":"2007-11-28T14:53:55Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"I would expect 'stg init' to switch the branch to using the stgit\nhooks and only those hooks. Branches that were not inited would\ncontinue to use the user hooks. I don't have any user hooks, but this\nis what I would expect to happen.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"61213","messageId":"474D8205.8030401@op5.se","threadId":"11038","inReplyTo":"9e4733910711280653q119f2c2n173eaebdda6cd774@mail.gmail.com","subject":"Re: StGit hooks","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-28T14:58:13Z","receivedAt":"2007-11-28T14:58:13Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jon Smirl wrote:\n> I would expect 'stg init' to switch the branch to using the stgit\n> hooks and only those hooks. Branches that were not inited would\n> continue to use the user hooks. I don't have any user hooks, but this\n> is what I would expect to happen.\n> \n\nObviously the stgit-installed hook will have to check if the branch\nthe user is operating on is managed by stgit before it prevents git\nrebase (or whatever it's supposed to do).\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"61215","messageId":"9e4733910711280706j45fe9c17t928396eb8e1de8bf@mail.gmail.com","threadId":"11038","inReplyTo":"20071128093403.GB12977@diana.vm.bytemark.co.uk","subject":"Re: stgit: lost all my patches again","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2007-11-28T15:06:57Z","receivedAt":"2007-11-28T15:06:57Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 11/28/07, Karl Hasselström wrote:\n> On 2007-11-27 18:12:49 -0500, Jon Smirl wrote:\n>\n> > As Jakub pointed out to me \"git reset --hard $(cat\n> > .git/patches//orig-base)\" would have recovered from the\n> > rebase command. But I had already typed 'stg repair' which\n> > compounded the mess.\n>\n> Unless it has a bug, the only thing \"stg repair\" will do is\n>\n> * create some new applied patches out of commits reachable from HEAD\n>\n> * mark some applied patches as unapplied\n>\n> * mark some unapplied patches as applied\n\nI did 'stg repair' after doing 'git rebase'. After the repair half of\nmy patches were marked as being applied and half not. The ones that\nwere applied were all empty. They were probably empty because my\noriginal patches were still commited by stg in front of the rebase. I\ncouldn't figure out how to recover so I extracted the pre-rebase\ncommits manual, built a series file and started again on a new branch.\n\nWhen I applied the patches to a clean branch none of them had conflicts.\n\n> in order to make sure that the applied patches are precisely those\n> that are reachable from HEAD, and that the sequence of applied patches\n> doesn't have \"holes\" in it (that is, commits that aren't patches).\n>\n> In particular, it should not ever modify your existing patches, and it\n> will never move the branch head. Just resetting the branch head to\n> wherever you want it to be (and then running repair again) should fix\n> literally all problems.\n\nI did this:\nall pataches were applied\ngit rebase\nstg repair -- partial repair, some patches empty, half are pushed\nmoved HEAD back in front of rebase\nstg repair - it show all my patches as popped, but when I started\ndoing command it complain that some commits that stg needed were not\nthere.\n\nThe complaint was caused by the first repair. The first repair altered\nsome of the stg state to point at commits past the rebase. That why I\nwanted check point. At this point I could move the HEAD back without\nalso reverting the stgit state in .git/*\n\n\n>\n> > This is way too easy to do. One simple mistype of 'git' for 'stg'\n> > and you're in a mess.\n>\n> You're right, this is not user friendly. A pre-rebase hook sounds like\n> a reasonable idea.\n>\n> It would also be convenient with a post-commit hook that turns new\n> commits into patches automatically. And gives \"git commit --amend\" the\n> semantics of \"stg refresh\".\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":"61217","messageId":"20071128154059.GA19302@diana.vm.bytemark.co.uk","threadId":"11038","inReplyTo":"474D8205.8030401@op5.se","subject":"Re: StGit hooks","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-11-28T15:40:59Z","receivedAt":"2007-11-28T15:40:59Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-11-28 15:58:13 +0100, Andreas Ericsson wrote:\n\n> Jon Smirl wrote:\n>\n> > I would expect 'stg init' to switch the branch to using the stgit\n> > hooks and only those hooks. Branches that were not inited would\n> > continue to use the user hooks. I don't have any user hooks, but\n> > this is what I would expect to happen.\n>\n> Obviously the stgit-installed hook will have to check if the branch\n> the user is operating on is managed by stgit before it prevents git\n> rebase (or whatever it's supposed to do).\n\nYes. The point is, hooks are per repository, not per branch. So\nthere's no concept of \"replacing the hooks for just this one branch\".\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"61231","messageId":"20071128160410.GB19302@diana.vm.bytemark.co.uk","threadId":"11038","inReplyTo":"9e4733910711280706j45fe9c17t928396eb8e1de8bf@mail.gmail.com","subject":"Re: stgit: lost all my patches again","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-11-28T16:04:10Z","receivedAt":"2007-11-28T16:04:10Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-11-28 10:06:57 -0500, Jon Smirl wrote:\n\n> I did this:\n> all pataches were applied\n> git rebase\n\nAt this point, a simple \"git reset --hard HEAD@{1}\" should have fixed\nthe problem. Not much use knowing that now, I know, but still ... :-)\n\n> stg repair -- partial repair, some patches empty, half are pushed\n\nModulo any bugs, this should have adjusted the appliedness of your\npatches to match the new HEAD (patches are applied iff they are\nreachable from HEAD) and made patches of any non-patch commits sitting\nbetween a patch and HEAD. Nothing else. In particular, it doesn't\nchange your existing patches or change HEAD, so those empty patches\nwere empty even before the repair. (Modulo any bugs, of course, but\nthat kind of bug seems really unlikely.)\n\n> moved HEAD back in front of rebase\n> stg repair - it show all my patches as popped,\n\nThat sounds OK. You reset HEAD to a commit early enough in history\nthat no patches are reachable from it.\n\n> but when I started doing command it complain that some commits that\n> stg needed were not there.\n\nThat sounds seriously broken. What exactly was the complaint? Missing\ncommit objects?\n\n> The complaint was caused by the first repair. The first repair\n> altered some of the stg state to point at commits past the rebase.\n\nYes. It would have made patches out of some of the rebased commits, in\norder to give you a consistent state. For example, assume you started\nwith the following situation:\n\n(cN are commits, pN are commits that are also StGit patches)\n\n ...---c0---c1---p0---p1---p2---p3---p4:HEAD\n\nYou git-rebase, causing a situation like this:\n\n ...---c0---c1---p0---p1---p2---p3---p4\n \\\n c2---c3---c4---c5---c6---c7---c8:HEAD\n\n\"stg repair\" at this point will see that p2..p4 should be unapplied\nsince they aren't reachable from HEAD, and c2..c8 need to be made\npatches since they are on top of p1.\n\nGenerally, what you want to do is to git-reset to the commit you want\nHEAD to be, and _then_ run stg repair.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"61230","messageId":"9e4733910711280821s3872eff5m95073ca6b1b8a689@mail.gmail.com","threadId":"11038","inReplyTo":"20071128160410.GB19302@diana.vm.bytemark.co.uk","subject":"Re: stgit: lost all my patches again","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2007-11-28T16:21:05Z","receivedAt":"2007-11-28T16:21:05Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 11/28/07, Karl Hasselström wrote:\n> On 2007-11-28 10:06:57 -0500, Jon Smirl wrote:\n>\n> > I did this:\n> > all pataches were applied\n> > git rebase\n>\n> At this point, a simple \"git reset --hard HEAD@{1}\" should have fixed\n> the problem. Not much use knowing that now, I know, but still ... :-)\n>\n> > stg repair -- partial repair, some patches empty, half are pushed\n>\n> Modulo any bugs, this should have adjusted the appliedness of your\n> patches to match the new HEAD (patches are applied iff they are\n> reachable from HEAD) and made patches of any non-patch commits sitting\n> between a patch and HEAD. Nothing else. In particular, it doesn't\n> change your existing patches or change HEAD, so those empty patches\n> were empty even before the repair. (Modulo any bugs, of course, but\n> that kind of bug seems really unlikely.)\n\nI don't know exactly what is going one, but all of my patches are in\ncommits in front of the rebase. I believe when they were applied\nagain, git detected that the changes were already in the tree and that\nwhy the patches are empty. Normally stg would have popped all my\npatches before doing the rebase.\n\nI have messed the branch up doing manual recover, but the conditions\nare easy enough to recreate.\n\n\n>\n> > moved HEAD back in front of rebase\n> > stg repair - it show all my patches as popped,\n>\n> That sounds OK. You reset HEAD to a commit early enough in history\n> that no patches are reachable from it.\n>\n> > but when I started doing command it complain that some commits that\n> > stg needed were not there.\n>\n> That sounds seriously broken. What exactly was the complaint? Missing\n> commit objects?\n>\n> > The complaint was caused by the first repair. The first repair\n> > altered some of the stg state to point at commits past the rebase.\n>\n> Yes. It would have made patches out of some of the rebased commits, in\n> order to give you a consistent state. For example, assume you started\n> with the following situation:\n>\n> (cN are commits, pN are commits that are also StGit patches)\n>\n> ...---c0---c1---p0---p1---p2---p3---p4:HEAD\n>\n> You git-rebase, causing a situation like this:\n>\n> ...---c0---c1---p0---p1---p2---p3---p4\n> \\\n> c2---c3---c4---c5---c6---c7---c8:HEAD\n>\n> \"stg repair\" at this point will see that p2..p4 should be unapplied\n> since they aren't reachable from HEAD, and c2..c8 need to be made\n> patches since they are on top of p1.\n>\n> Generally, what you want to do is to git-reset to the commit you want\n> HEAD to be, and _then_ run stg repair.\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":"61239","messageId":"20071128164113.GA20749@diana.vm.bytemark.co.uk","threadId":"11038","inReplyTo":"9e4733910711280821s3872eff5m95073ca6b1b8a689@mail.gmail.com","subject":"Re: stgit: lost all my patches again","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-11-28T16:41:13Z","receivedAt":"2007-11-28T16:41:13Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-11-28 11:21:05 -0500, Jon Smirl wrote:\n\n> On 11/28/07, Karl Hasselström wrote:\n>\n> > On 2007-11-28 10:06:57 -0500, Jon Smirl wrote:\n> >\n> > > stg repair -- partial repair, some patches empty, half are pushed\n> >\n> > Modulo any bugs, this should have adjusted the appliedness of your\n> > patches to match the new HEAD (patches are applied iff they are\n> > reachable from HEAD) and made patches of any non-patch commits\n> > sitting between a patch and HEAD. Nothing else. In particular, it\n> > doesn't change your existing patches or change HEAD, so those\n> > empty patches were empty even before the repair. (Modulo any bugs,\n> > of course, but that kind of bug seems really unlikely.)\n>\n> I don't know exactly what is going one, but all of my patches are in\n> commits in front of the rebase. I believe when they were applied\n> again, git detected that the changes were already in the tree and\n> that why the patches are empty. Normally stg would have popped all\n> my patches before doing the rebase.\n\nAh, yes, if you \"stg push\" after the repair, that's what you can\nexpect to happen. And once you've done that, it gets a little messier\nto recover. (Basically, what you'd do is delete the messed-up patches,\ngit-reset to where you were before the git-rebase, and then \"stg\nuncommit\".)\n\n> I have messed the branch up doing manual recover, but the conditions\n> are easy enough to recreate.\n\nSo I guess \"stg repair\" is working as intended, and what needs\nchanging is its documentation: point out in greater detail that you\nshould\n\n 1. Figure out where you _want_ HEAD to be.\n\n 2. git-reset your way there.\n\n 3. Run stg repair if necessary. (And if you just reset back to where\n StGit thinks you are, you don't need to. But it's safe to run\n repair in that case too -- it'll just do nothing.)\n\nIn that order.\n\nThe only thing repair does is fix up StGit's metadata to match what\nHEAD is right now. If HEAD isn't what you want it to be, then you want\nto fix that first. In particular, to just go back to where you were\nthe last time StGit heard from you, do\n\n $ git reset --hard $(stg id $(stg top))\n\nWe need a proper manual to explain this in. :-)\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"61244","messageId":"9e4733910711280858j5d03b3acleac0ece7b0a67f66@mail.gmail.com","threadId":"11038","inReplyTo":"20071128164113.GA20749@diana.vm.bytemark.co.uk","subject":"Re: stgit: lost all my patches again","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2007-11-28T16:58:14Z","receivedAt":"2007-11-28T16:58:14Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 11/28/07, Karl Hasselström wrote:\n> On 2007-11-28 11:21:05 -0500, Jon Smirl wrote:\n>\n> > On 11/28/07, Karl Hasselström wrote:\n> >\n> > > On 2007-11-28 10:06:57 -0500, Jon Smirl wrote:\n> > >\n> > > > stg repair -- partial repair, some patches empty, half are pushed\n> > >\n> > > Modulo any bugs, this should have adjusted the appliedness of your\n> > > patches to match the new HEAD (patches are applied iff they are\n> > > reachable from HEAD) and made patches of any non-patch commits\n> > > sitting between a patch and HEAD. Nothing else. In particular, it\n> > > doesn't change your existing patches or change HEAD, so those\n> > > empty patches were empty even before the repair. (Modulo any bugs,\n> > > of course, but that kind of bug seems really unlikely.)\n> >\n> > I don't know exactly what is going one, but all of my patches are in\n> > commits in front of the rebase. I believe when they were applied\n> > again, git detected that the changes were already in the tree and\n> > that why the patches are empty. Normally stg would have popped all\n> > my patches before doing the rebase.\n>\n> Ah, yes, if you \"stg push\" after the repair, that's what you can\n> expect to happen. And once you've done that, it gets a little messier\n> to recover. (Basically, what you'd do is delete the messed-up patches,\n> git-reset to where you were before the git-rebase, and then \"stg\n> uncommit\".)\n>\n> > I have messed the branch up doing manual recover, but the conditions\n> > are easy enough to recreate.\n>\n> So I guess \"stg repair\" is working as intended, and what needs\n> changing is its documentation: point out in greater detail that you\n> should\n>\n\nAfter someone runs the wrong command their first instinct will be to\nrun stg repair. Can stg repair be made smart enough to not attempt a\nrepair if it is unable to do so and print a message referring people\nback to the manual on how to move the head back?\n\nWhen I ran stg repair after the wrong git rebase command, I compounded\nthe problem further.\n\n\n> 1. Figure out where you _want_ HEAD to be.\n>\n> 2. git-reset your way there.\n>\n> 3. Run stg repair if necessary. (And if you just reset back to where\n> StGit thinks you are, you don't need to. But it's safe to run\n> repair in that case too -- it'll just do nothing.)\n>\n> In that order.\n>\n> The only thing repair does is fix up StGit's metadata to match what\n> HEAD is right now. If HEAD isn't what you want it to be, then you want\n> to fix that first. In particular, to just go back to where you were\n> the last time StGit heard from you, do\n>\n> $ git reset --hard $(stg id $(stg top))\n>\n> We need a proper manual to explain this in. :-)\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":"61249","messageId":"474DA01C.8010901@op5.se","threadId":"11038","inReplyTo":"20071128154059.GA19302@diana.vm.bytemark.co.uk","subject":"Re: StGit hooks","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-28T17:06:36Z","receivedAt":"2007-11-28T17:06:36Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Karl Hasselström wrote:\n> On 2007-11-28 15:58:13 +0100, Andreas Ericsson wrote:\n> \n>> Jon Smirl wrote:\n>>\n>>> I would expect 'stg init' to switch the branch to using the stgit\n>>> hooks and only those hooks. Branches that were not inited would\n>>> continue to use the user hooks. I don't have any user hooks, but\n>>> this is what I would expect to happen.\n>> Obviously the stgit-installed hook will have to check if the branch\n>> the user is operating on is managed by stgit before it prevents git\n>> rebase (or whatever it's supposed to do).\n> \n> Yes. The point is, hooks are per repository, not per branch. So\n> there's no concept of \"replacing the hooks for just this one branch\".\n> \n\nTrue, but there are ways of figuring out which branch you're on, using\nthe arguments passed to the hook.\n\nThe rebase hook (which is where this discussion started) gets the\nbranches passed to \"git rebase\" as arguments. Figuring out if either\nof those branches are actually under stgit control shouldn't be overly\ntricky for one so familiar with stgit as yourself.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"61252","messageId":"20071128171917.GA21310@diana.vm.bytemark.co.uk","threadId":"11038","inReplyTo":"9e4733910711280858j5d03b3acleac0ece7b0a67f66@mail.gmail.com","subject":"Re: stgit: lost all my patches again","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-11-28T17:19:17Z","receivedAt":"2007-11-28T17:19:17Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-11-28 11:58:14 -0500, Jon Smirl wrote:\n\n> After someone runs the wrong command their first instinct will be to\n> run stg repair. Can stg repair be made smart enough to not attempt a\n> repair if it is unable to do so and print a message referring people\n> back to the manual on how to move the head back?\n\nWell, the thing is, it's never unable to repair.\n\nHowever, I could add another repair mode: reset the branch head to the\nlatest point in the reflog where it was consistent with StGit's\nmetadata.\n\nrepair would have two flags to select the original or this new repair\nmode, and if the user doesn't give either flag, repair points out that\nshe has two choices, and what they mean:\n\n \"If you want to undo the last 3 git commands\n\n pull : Fast forward\n commit (amend): fix\n reset --hard kha/experimental: updating HEAD\n\n call stg repair --undo. If you want StGit to adjust to the new\n situation, call stg repair --assimilate.\"\n\n> When I ran stg repair after the wrong git rebase command, I\n> compounded the problem further.\n\nNot that much. It was the push following the repair that killed you.\nThe repair alone is totally benign; doing\n\n $ stg repair && git reset --hard foobar && stg repair\n\ngives the same result as just\n\n $ git reset --hard foobar && stg repair\n\nexcept for creating a few new patches that you can safely delete.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"61253","messageId":"20071128172152.GB21310@diana.vm.bytemark.co.uk","threadId":"11038","inReplyTo":"474DA01C.8010901@op5.se","subject":"Re: StGit hooks","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-11-28T17:21:52Z","receivedAt":"2007-11-28T17:21:52Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-11-28 18:06:36 +0100, Andreas Ericsson wrote:\n\n> True, but there are ways of figuring out which branch you're on,\n> using the arguments passed to the hook.\n>\n> The rebase hook (which is where this discussion started) gets the\n> branches passed to \"git rebase\" as arguments. Figuring out if either\n> of those branches are actually under stgit control shouldn't be\n> overly tricky for one so familiar with stgit as yourself.\n\nNo, that part is trivial. The hard part is not messing up the user's\nexisting hook scripts.\n\nIf I do go ahead and do this, I have a feeling I'll be beefing up\ngit's hook dispatch mechanism first -- if I can get it past Junio,\nobviously. :-)\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"61276","messageId":"7vfxyq5fr7.fsf@gitster.siamese.dyndns.org","threadId":"11038","inReplyTo":"20071128172152.GB21310@diana.vm.bytemark.co.uk","subject":"Re: StGit hooks","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-28T19:31:08Z","receivedAt":"2007-11-28T19:31:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karl Hasselström writes:\n\n> On 2007-11-28 18:06:36 +0100, Andreas Ericsson wrote:\n>\n>> True, but there are ways of figuring out which branch you're on,\n>> using the arguments passed to the hook.\n>>\n>> The rebase hook (which is where this discussion started) gets the\n>> branches passed to \"git rebase\" as arguments. Figuring out if either\n>> of those branches are actually under stgit control shouldn't be\n>> overly tricky for one so familiar with stgit as yourself.\n>\n> No, that part is trivial. The hard part is not messing up the user's\n> existing hook scripts.\n>\n> If I do go ahead and do this, I have a feeling I'll be beefing up\n> git's hook dispatch mechanism first -- if I can get it past Junio,\n> obviously. :-)\n\nI do not see a fundamental problem in a scheme like this:\n\n * when running a hook $foo, if .git/hooks/$foo.d/. does not exist, we\n operate as we have always done.\n\n * if .git/hooks/$foo.d/ exists, we readdir(3) it and run the hooks found\n in the order their names sort bytewise (similar to /etc/rc$n.d/).\n\n - when the purpose of the $foo hook is to return a bool to refuse an\n operation, stop at the first failure;\n\n - when the purpose of the $foo hook is to cause effect, run them all\n in series.\n\n * When .git/hooks/$foo.d/ exists, there will always be \"050-simple\" in\n that directory. It checks if .git/hooks/$foo exists and sources it\n if it does. A custom hook that wants to run before or after it can\n be named NNN-mine in .git/hooks/$foo.d/, where NNN sorts earlier or\n later than 050 to define the execution order.\n\nWe probably would want to reserve a special exit code for the hooks run\nfor their effects so that they can signal \"I do not want you to run the\nremainder\".\n"},{"id":"61480","messageId":"20071130063516.27500.85249.stgit@yoghurt","threadId":"11038","inReplyTo":"20071128164113.GA20749@diana.vm.bytemark.co.uk","subject":"[StGit PATCH] Make \"stg repair\" help text more helpful","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-11-30T06:35:50Z","receivedAt":"2007-11-30T06:35:50Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"Specifically, point out that if messing up the branch with git\ncommands was a mistake, the user should run \"git reset\", not \"stg\nrepair\".\n\nSigned-off-by: Karl Hasselström \n\n---\n\nIs this an improvement?\n\n stgit/commands/common.py | 4 +--\n stgit/commands/repair.py | 63 ++++++++++++++++++++++++++++------------------\n 2 files changed, 41 insertions(+), 26 deletions(-)\n\n\ndiff --git a/stgit/commands/common.py b/stgit/commands/common.py\nindex 6318cdd..bf804e6 100644\n--- a/stgit/commands/common.py\n+++ b/stgit/commands/common.py\n@@ -114,8 +114,8 @@ def check_head_top_equal(crt_series):\n if not crt_series.head_top_equal():\n raise CmdException(\n \"\"\"HEAD and top are not the same. This can happen if you\n- modify a branch with git. The \"repair\" command can\n- fix this situation.\"\"\")\n+ modify a branch with git. \"stg repair --help\" explains\n+ more about what to do next.\"\"\")\n \n def check_conflicts():\n if os.path.exists(os.path.join(basedir.get(), 'conflicts')):\ndiff --git a/stgit/commands/repair.py b/stgit/commands/repair.py\nindex c36db07..aa34792 100644\n--- a/stgit/commands/repair.py\n+++ b/stgit/commands/repair.py\n@@ -26,32 +26,47 @@ from stgit.out import *\n from stgit.run import *\n from stgit import stack, git\n \n-help = 'StGit-ify any git commits made on top of your StGit stack'\n+help = 'Fix StGit metadata if branch was modified with git commands'\n usage = \"\"\"%prog [options]\n \n-\"repair\" will repair three kinds of inconsistencies in your StGit\n-stack, all of them caused by using plain git commands on the branch:\n-\n- 1. If you have made regular git commits on top of your stack of\n- StGit patches, \"repair\" converts them to StGit patches,\n- preserving their contents.\n-\n- 2. Merge commits cannot become patches; if you have committed a\n- merge on top of your stack, \"repair\" will simply mark all\n- patches below the merge unapplied, since they are no longer\n- reachable. If this is not what you want, use \"git reset\" to get\n- rid of the merge and run \"repair\" again.\n-\n- 3. The applied patches are supposed to be precisely those that are\n- reachable from the branch head. If you have used e.g. \"git reset\"\n- to move the head, some applied patches may no longer be\n- reachable, and some unapplied patches may have become reachable.\n- \"repair\" will correct the appliedness of such patches.\n-\n-Note that these are \"inconsistencies\", not \"errors\"; furthermore,\n-\"repair\" will repair them reliably. As long as you are satisfied\n-with the way \"repair\" handles them, you have no reason to avoid\n-causing them in the first place if that is convenient for you.\"\"\"\n+If you modify an StGit stack (branch) with some git commands -- such\n+as commit, pull, merge, and rebase -- you will leave the StGit\n+metadata in an inconsistent state. In that situation, you have two\n+options:\n+\n+ 1. Use \"git reset\" or similar to undo the effect of the git\n+ command(s).\n+\n+ 2. Use \"stg repair\". This will fix up the StGit metadata to\n+ accomodate the modifications to the branch. Specifically, it will\n+ do the following:\n+\n+ * If you have made regular git commits on top of your stack of\n+ StGit patches, \"stg repair\" makes new StGit patches out of\n+ them, preserving their contents.\n+\n+ * However, merge commits cannot become patches; if you have\n+ committed a merge on top of your stack, \"repair\" will simply\n+ mark all patches below the merge unapplied, since they are no\n+ longer reachable. If this is not what you want, use \"git\n+ reset\" to get rid of the merge and run \"stg repair\" again.\n+\n+ * The applied patches are supposed to be precisely those that\n+ are reachable from the branch head. If you have used e.g.\n+ \"git reset\" to move the head, some applied patches may no\n+ longer be reachable, and some unapplied patches may have\n+ become reachable. \"stg repair\" will correct the appliedness\n+ of such patches.\n+\n+ \"stg repair\" will fix these inconsistencies reliably, so as long\n+ as you like what it does, you have no reason to avoid causing\n+ them in the first place. For example, you might find it\n+ convenient to make commits with a graphical tool and then have\n+ \"stg repair\" make proper patches of the commits.\n+\n+NOTE: If using git commands on the stack was a mistake, running \"stg\n+repair\" is _not_ what you want. In that case, what you want is option\n+(1) above.\"\"\"\n \n directory = DirectoryGotoToplevel()\n options = []\n"}]}