{"thread":{"id":"11039","subject":"Rollback of git commands","startedAt":"2007-11-27T23:23:35Z","lastAt":"2007-11-29T08:42:19Z","messageCount":31,"participants":["Jon Smirl","Junio C Hamano","Karl Hasselström","David Symonds","Sean","Geert Bosch","Nicolas Pitre","Jeff King","Ingo Molnar","Sergei Organov","Daniel Barkalow","Steven Grimm","Theodore Tso"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"61135","messageId":"9e4733910711271523p3be94010jac9c79e6b95f010d@mail.gmail.com","threadId":"11039","inReplyTo":null,"subject":"Rollback of git commands","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2007-11-27T23:23:35Z","receivedAt":"2007-11-27T23:23:35Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"Could a rollback log be implemented in git? It would make things way\neasier when you screw something up.You'd only roll back things that\nimpacted the object store, not things like checkout.\n\nstg is also starting to store significant state in the .git directory.\nIt may be better to move this state into a git object. That would\nallow the state history to be tracked and rollback be implemented.\n\nThe same logic can be applied to moving all tracking information in\nthe .git directory into objects. You then just need to track a single\nSHA1 pointing to the .git config info in the object db.\n\nRollback in the object store is simple, just move the SHA1 in the\nconfig files back to where it was before the action was done. What we\nare missing is a way to rollback the config files.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"61142","messageId":"7vmyszb39s.fsf@gitster.siamese.dyndns.org","threadId":"11039","inReplyTo":"9e4733910711271523p3be94010jac9c79e6b95f010d@mail.gmail.com","subject":"Re: Rollback of git commands","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-28T00:51:59Z","receivedAt":"2007-11-28T00:51:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Jon Smirl\" writes:\n\n> Could a rollback log be implemented in git? It would make things way\n> easier when you screw something up. You'd only roll back things that\n> impacted the object store, not things like checkout.\n\nThe object store is append only, and if you disregard SHA-1 collisions,\nI do not think there is much you can gain from being able to roll back\nonly object store.\n\nFor example, you would want to be able to roll back where your 'master'\nbranch was pointing at before you started that botched operation. That\nis not in the object store at all (we have reflogs for that).\n\nAnother example, you might have done quite an elaborate interactive add\nto stage only some changes to a path, but then accidentally said \"git\nadd\" that path to stage the whole thing. You may say \"oops, that state\nwas only in the index and now it is lost.\" The blob that records the\nstaged content _DOES_ exist in the object store in such a case so it is\nnot lost --- there is nothing to roll back. What you lost is a pointer\ninto the object store (we do not have anything like reflog for\nindividual index entry --- not that I would suggest adding one).\n\nCreating a blob that records all of .git/config, output from\nfor-each-ref, output from \"symbolic-ref HEAD\" and output from ls-files\n-s every time you run _any_ git operation, and restore the state when\nyou want to, would conceptually work, as you suggest, but I am not sure\nhow practical it would be, performancewise, spacewise, and\nsemanticswise.\n"},{"id":"61145","messageId":"9e4733910711271733r6f280618pbb14095aebba3309@mail.gmail.com","threadId":"11039","inReplyTo":"7vmyszb39s.fsf@gitster.siamese.dyndns.org","subject":"Re: Rollback of git commands","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2007-11-28T01:33:27Z","receivedAt":"2007-11-28T01:33:27Z","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> > Could a rollback log be implemented in git? It would make things way\n> > easier when you screw something up. You'd only roll back things that\n> > impacted the object store, not things like checkout.\n>\n> The object store is append only, and if you disregard SHA-1 collisions,\n> I do not think there is much you can gain from being able to roll back\n> only object store.\n>\n> For example, you would want to be able to roll back where your 'master'\n> branch was pointing at before you started that botched operation. That\n> is not in the object store at all (we have reflogs for that).\n>\n> Another example, you might have done quite an elaborate interactive add\n> to stage only some changes to a path, but then accidentally said \"git\n> add\" that path to stage the whole thing. You may say \"oops, that state\n> was only in the index and now it is lost.\" The blob that records the\n> staged content _DOES_ exist in the object store in such a case so it is\n> not lost --- there is nothing to roll back. What you lost is a pointer\n> into the object store (we do not have anything like reflog for\n> individual index entry --- not that I would suggest adding one).\n>\n> Creating a blob that records all of .git/config, output from\n> for-each-ref, output from \"symbolic-ref HEAD\" and output from ls-files\n> -s every time you run _any_ git operation, and restore the state when\n> you want to, would conceptually work, as you suggest, but I am not sure\n> how practical it would be, performancewise, spacewise, and\n> semanticswise.\n\nI'm only looking for a command that would rollback the effect of\nchanges to the object store (you don't have to remove the objects).\nLosing complex staging would be ok since it can be recreated.\n\nLet's take my recent problem as an example. I typed 'git rebase\nlinus/master' instead of 'stg rebase linus/master'. Then I typed 'stg\nrepair'. The repair failed and left me in a mess. Both of these are\neasy to rollback except for the fact that stg has stored a bunch of\nstate in .git/*.\n\nAfter doing the commands I located my last commit before the rebase\nand edited master back to it. But my system was still messed up since\nmoving master got me out of sync with the state stg stored in .git/*.\nThe 'stg repair' command had changed the stored state.\n\nInstead lets store the contents of .git/* (minus the data itself) as\nobjects. Then commit a new object after each command. Now rollback can\nbe accomplished by walking back this chain off commits. Rollback would\nwipe out any staging, and effectively reset the working tree to match\nthe point rolled back to. I don't think we need to capture the entire\nstate of 'ls-file -s' to achieve this.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"61151","messageId":"9e4733910711271749q1b96bfe9i60e43619c89234b9@mail.gmail.com","threadId":"11039","inReplyTo":"9e4733910711271733r6f280618pbb14095aebba3309@mail.gmail.com","subject":"Re: Rollback of git commands","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2007-11-28T01:49:20Z","receivedAt":"2007-11-28T01:49:20Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"Rollback is too strong of name for this. Checkpoints would be better.\nThe idea is to record the total system state at convenient moments and\nthen allow moving back to the checkpointed state. The object store\nsupports this, but the rest of the state in .git/* isn't being\nrecorded.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"61152","messageId":"ee77f5c20711271757h724d5fcep38f3c2354c54f20b@mail.gmail.com","threadId":"11039","inReplyTo":"9e4733910711271749q1b96bfe9i60e43619c89234b9@mail.gmail.com","subject":"Re: Rollback of git commands","fromName":"David Symonds","fromEmail":"dsymonds@gmail.com","sentAt":"2007-11-28T01:57:42Z","receivedAt":"2007-11-28T01:57:42Z","isPatch":false,"sender":{"key":"dsymonds@gmail.com","avatar":"https://gravatar.com/avatar/b22f5051cbfc11836e36cf7a690e6cde4e225d835e13295ff98d15c7a9ee3c0f?d=mp&s=160"},"body":"On Nov 28, 2007 12:49 PM, Jon Smirl wrote:\n> Rollback is too strong of name for this. Checkpoints would be better.\n> The idea is to record the total system state at convenient moments and\n> then allow moving back to the checkpointed state. The object store\n> supports this, but the rest of the state in .git/* isn't being\n> recorded.\n\nrsync -a .git /somewhere/safe\n\nI fear that what you ask becomes a chicken-and-egg scenario: where/how\nis this checkpointing information going to be stored? If it's tightly\nintegrated with Git, what happens when you want to roll-back a\ncheckpoint-restore?\n\n\nDave.\n"},{"id":"61159","messageId":"BAYC1-PASMTP02DBA3FB25E09FE45F0BF2AE770@CEZ.ICE","threadId":"11039","inReplyTo":"9e4733910711271733r6f280618pbb14095aebba3309@mail.gmail.com","subject":"Re: Rollback of git commands","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2007-11-28T03:55:05Z","receivedAt":"2007-11-28T03:55:05Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, November 27, 2007 8:33 pm, Jon Smirl said:\n\nHi Jon,\n\n> I'm only looking for a command that would rollback the effect of\n> changes to the object store (you don't have to remove the objects).\n> Losing complex staging would be ok since it can be recreated.\n>\n> Let's take my recent problem as an example. I typed 'git rebase\n> linus/master' instead of 'stg rebase linus/master'. Then I typed 'stg\n> repair'. The repair failed and left me in a mess. Both of these are\n> easy to rollback except for the fact that stg has stored a bunch of\n> state in .git/*.\n>\n> After doing the commands I located my last commit before the rebase\n> and edited master back to it. But my system was still messed up since\n> moving master got me out of sync with the state stg stored in .git/*.\n> The 'stg repair' command had changed the stored state.\n\n From your description is seems that Git proper was able to handle the\nsituation just fine. It sounds instead like you're describing a problem\nwith Stg where it became confused without a way to restore _its_ meta\ndata. There's not much Git itself can do to help in this situation\nunless Stg stores all of its meta-data as standard Git objects, rather\nthan just using the .git directory.\n\nSean\n"},{"id":"61162","messageId":"3AAC5548-A9AC-4236-B1F7-5CFDE11B52C4@adacore.com","threadId":"11039","inReplyTo":"9e4733910711271749q1b96bfe9i60e43619c89234b9@mail.gmail.com","subject":"Re: Rollback of git commands","fromName":"Geert Bosch","fromEmail":"bosch@adacore.com","sentAt":"2007-11-28T04:07:29Z","receivedAt":"2007-11-28T04:07:29Z","isPatch":false,"sender":{"key":"bosch@adacore.com","avatar":null},"body":"On Nov 27, 2007, at 20:49, Jon Smirl wrote:\n> Rollback is too strong of name for this. Checkpoints would be better.\n> The idea is to record the total system state at convenient moments and\n> then allow moving back to the checkpointed state. The object store\n> supports this, but the rest of the state in .git/* isn't being\n> recorded.\n\nI have always wondered why refs and tags are not\nin the regular object store. In a way, there\nshould be just one root pointer (SHA1) pointing\nto a tree with refs, etc.\n\nAs for the problem of \"lots of loose objects\", each\ncommand could write a single pack file. By directly\nwriting deltas instead of complete new tree objects,\nstorage requirements should be modest. Also, just\nwriting a single new pack file is very efficient\nfor I/O purposes.\n\nTo prevent too many pack files, a merge policy\ncould allow a new pack to include (and thus obsolete)\na number of similarly sized or smaller packs.\nAfter the new file has been successfully written, the\nold files are no longer necessary and can be\nmoved to a \"trashes\" area to be expired.\n\n -Geert\n"},{"id":"61164","messageId":"9e4733910711272037r2ce3ed01y31ec8531f5803efe@mail.gmail.com","threadId":"11039","inReplyTo":"BAYC1-PASMTP02DBA3FB25E09FE45F0BF2AE770@CEZ.ICE","subject":"Re: Rollback of git commands","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2007-11-28T04:37:13Z","receivedAt":"2007-11-28T04:37:13Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 11/27/07, Sean wrote:\n> On Tue, November 27, 2007 8:33 pm, Jon Smirl said:\n>\n> Hi Jon,\n>\n> > I'm only looking for a command that would rollback the effect of\n> > changes to the object store (you don't have to remove the objects).\n> > Losing complex staging would be ok since it can be recreated.\n> >\n> > Let's take my recent problem as an example. I typed 'git rebase\n> > linus/master' instead of 'stg rebase linus/master'. Then I typed 'stg\n> > repair'. The repair failed and left me in a mess. Both of these are\n> > easy to rollback except for the fact that stg has stored a bunch of\n> > state in .git/*.\n> >\n> > After doing the commands I located my last commit before the rebase\n> > and edited master back to it. But my system was still messed up since\n> > moving master got me out of sync with the state stg stored in .git/*.\n> > The 'stg repair' command had changed the stored state.\n>\n> From your description is seems that Git proper was able to handle the\n> situation just fine. It sounds instead like you're describing a problem\n> with Stg where it became confused without a way to restore _its_ meta\n> data. There's not much Git itself can do to help in this situation\n> unless Stg stores all of its meta-data as standard Git objects, rather\n> than just using the .git directory.\n\nPatch management is an important part of the work flow. I would hope\nthat git implements patch management as a core feature in future\nversions. stgit/guilt/quilt are valuable since they blazed the trail\nand figured out what commands are useful. As time passes these\nfeatures can become more highly integrated into core git.\n\nOf course you've never screwed up a repository using git commands,\nright? I've messed up plenty. A good way to mess up a repo is to get\nthe data in .git/* out of sync with what is in the repo. I'm getting\ngood enough with git that I can fix most mess up with a few edits, but\nit took me two years to get to that point. Rolling back to a check\npoint is way easier. User error and a command failing are both equally\nvalid ways to mess up a repo.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"61166","messageId":"BAYC1-PASMTP101A96ADE42981D2708652AE770@CEZ.ICE","threadId":"11039","inReplyTo":"9e4733910711272037r2ce3ed01y31ec8531f5803efe@mail.gmail.com","subject":"Re: Rollback of git commands","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2007-11-28T04:40:42Z","receivedAt":"2007-11-28T04:40:42Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, November 27, 2007 11:37 pm, Jon Smirl said:\n\n> Patch management is an important part of the work flow. I would hope\n> that git implements patch management as a core feature in future\n> versions. stgit/guilt/quilt are valuable since they blazed the trail\n> and figured out what commands are useful. As time passes these\n> features can become more highly integrated into core git.\n\nThink this is a separate topic from where we started though.\n\n> Of course you've never screwed up a repository using git commands,\n> right? I've messed up plenty. A good way to mess up a repo is to get\n> the data in .git/* out of sync with what is in the repo. I'm getting\n> good enough with git that I can fix most mess up with a few edits, but\n> it took me two years to get to that point. Rolling back to a check\n> point is way easier. User error and a command failing are both equally\n> valid ways to mess up a repo.\n\nWhat are you looking for that reflogs don't already handle?\n\nCheers,\nSean\n"},{"id":"61168","messageId":"9e4733910711272053t211afd06ocae6731a2844d93f@mail.gmail.com","threadId":"11039","inReplyTo":"BAYC1-PASMTP101A96ADE42981D2708652AE770@CEZ.ICE","subject":"Re: Rollback of git commands","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2007-11-28T04:53:55Z","receivedAt":"2007-11-28T04:53:55Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 11/27/07, Sean wrote:\n> On Tue, November 27, 2007 11:37 pm, Jon Smirl said:\n>\n> > Patch management is an important part of the work flow. I would hope\n> > that git implements patch management as a core feature in future\n> > versions. stgit/guilt/quilt are valuable since they blazed the trail\n> > and figured out what commands are useful. As time passes these\n> > features can become more highly integrated into core git.\n>\n> Think this is a separate topic from where we started though.\n>\n> > Of course you've never screwed up a repository using git commands,\n> > right? I've messed up plenty. A good way to mess up a repo is to get\n> > the data in .git/* out of sync with what is in the repo. I'm getting\n> > good enough with git that I can fix most mess up with a few edits, but\n> > it took me two years to get to that point. Rolling back to a check\n> > point is way easier. User error and a command failing are both equally\n> > valid ways to mess up a repo.\n>\n> What are you looking for that reflogs don't already handle?\n\nA UI that doesn't need a year of using git before you know what to do with it.\nDelta tracking of changes made in .git/* that aren't currently being tracked.\nreflogs is a piece of the complete solution.\n\nA higher level of integration for stgit would probably make it more\nbullet proof.\n\n>\n> Cheers,\n> Sean\n>\n>\n\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"61170","messageId":"7vmysz9dch.fsf@gitster.siamese.dyndns.org","threadId":"11039","inReplyTo":"BAYC1-PASMTP02DBA3FB25E09FE45F0BF2AE770@CEZ.ICE","subject":"Re: Rollback of git commands","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-28T04:57:18Z","receivedAt":"2007-11-28T04:57:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Sean\" writes:\n\n>> After doing the commands I located my last commit before the rebase\n>> and edited master back to it. But my system was still messed up since\n>> moving master got me out of sync with the state stg stored in .git/*.\n>> The 'stg repair' command had changed the stored state.\n>\n> From your description is seems that Git proper was able to handle the\n> situation just fine. It sounds instead like you're describing a problem\n> with Stg where it became confused without a way to restore _its_ meta\n> data. There's not much Git itself can do to help in this situation\n> unless Stg stores all of its meta-data as standard Git objects, rather\n> than just using the .git directory.\n\nEssentially, he does not want to use \"git rebase\" and have a way to\ndisable the command on a branch that stg is actively munging. And that\nis something git proper can help with the user, which is why I earlier\nreferred him to pre-rebase hook.\n\nAs you suggested, however, git proper should not know the internals of\nPorcelains, so I'd rather not to have that logic deep in git-rebase\nitself. But the pre-rebase hook shoud be the appropriate place for the\nuser to actually populate with stg specific logic (\"is stg set to\nactively munge this branch\") and activate it for his repository.\n"},{"id":"61147","messageId":"20071128092234.GA12977@diana.vm.bytemark.co.uk","threadId":"11039","inReplyTo":"9e4733910711271733r6f280618pbb14095aebba3309@mail.gmail.com","subject":"Re: Rollback of git commands","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-11-28T09:22:34Z","receivedAt":"2007-11-28T09:22:34Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-11-27 20:33:27 -0500, Jon Smirl wrote:\n\n> Let's take my recent problem as an example. I typed 'git rebase\n> linus/master' instead of 'stg rebase linus/master'. Then I typed\n> 'stg repair'. The repair failed and left me in a mess. Both of these\n> are easy to rollback except for the fact that stg has stored a bunch\n> of state in .git/*.\n>\n> After doing the commands I located my last commit before the rebase\n> and edited master back to it. But my system was still messed up\n> since moving master got me out of sync with the state stg stored in\n> .git/*. The 'stg repair' command had changed the stored state.\n\nHow exactly did repair mess up? Did it crash, produce a broken result,\nan unreasonable but technically valid result, or just not the result\nyou wanted?\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"61211","messageId":"alpine.LFD.0.99999.0711280951150.9605@xanadu.home","threadId":"11039","inReplyTo":"9e4733910711272037r2ce3ed01y31ec8531f5803efe@mail.gmail.com","subject":"Re: Rollback of git commands","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-28T14:53:29Z","receivedAt":"2007-11-28T14:53:29Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 27 Nov 2007, Jon Smirl wrote:\n\n> Of course you've never screwed up a repository using git commands,\n> right? I've messed up plenty. A good way to mess up a repo is to get\n> the data in .git/* out of sync with what is in the repo. I'm getting\n> good enough with git that I can fix most mess up with a few edits, but\n> it took me two years to get to that point. Rolling back to a check\n> point is way easier. User error and a command failing are both equally\n> valid ways to mess up a repo.\n\nThe reflog contains all your check points, for every modifications you \nmake, even the stupid ones. You should look at it.\n\n\nNicolas\n"},{"id":"61216","messageId":"9e4733910711280713n6b439866m55bea4824efd959@mail.gmail.com","threadId":"11039","inReplyTo":"20071128092234.GA12977@diana.vm.bytemark.co.uk","subject":"Re: Rollback of git commands","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2007-11-28T15:13:13Z","receivedAt":"2007-11-28T15:13:13Z","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 20:33:27 -0500, Jon Smirl wrote:\n>\n> > Let's take my recent problem as an example. I typed 'git rebase\n> > linus/master' instead of 'stg rebase linus/master'. Then I typed\n> > 'stg repair'. The repair failed and left me in a mess. Both of these\n> > are easy to rollback except for the fact that stg has stored a bunch\n> > of state in .git/*.\n> >\n> > After doing the commands I located my last commit before the rebase\n> > and edited master back to it. But my system was still messed up\n> > since moving master got me out of sync with the state stg stored in\n> > .git/*. The 'stg repair' command had changed the stored state.\n>\n> How exactly did repair mess up? Did it crash, produce a broken result,\n> an unreasonable but technically valid result, or just not the result\n> you wanted?\n\nall my patches applied\ngit rebase\ncursing.... I immediately knew what I had done\nupdate stg and install it\nstg repair\nfour of my 15 patches tried to apply, I received messages that there\nwere all empty\nmost stg commands won't work, they complain that the commit references\nin the stg .git/* state are not correct.\n\nI then proceed to manually attempt repair.\n\n\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":"61226","messageId":"9e4733910711280758x38ca3cdau4e62bfe8776e5c0d@mail.gmail.com","threadId":"11039","inReplyTo":"alpine.LFD.0.99999.0711280951150.9605@xanadu.home","subject":"Re: Rollback of git commands","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2007-11-28T15:58:14Z","receivedAt":"2007-11-28T15:58:14Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 11/28/07, Nicolas Pitre wrote:\n> On Tue, 27 Nov 2007, Jon Smirl wrote:\n>\n> > Of course you've never screwed up a repository using git commands,\n> > right? I've messed up plenty. A good way to mess up a repo is to get\n> > the data in .git/* out of sync with what is in the repo. I'm getting\n> > good enough with git that I can fix most mess up with a few edits, but\n> > it took me two years to get to that point. Rolling back to a check\n> > point is way easier. User error and a command failing are both equally\n> > valid ways to mess up a repo.\n>\n> The reflog contains all your check points, for every modifications you\n> make, even the stupid ones. You should look at it.\n\nThe state contained in the other config files in .git/* is not getting\ncheck pointed. I can use reflog to move my branch heads around. But\ndoing that does not undo the changes to the state recorded in .git/*.\nAfter the error I encountered I moved my branch head back, but the\nstate stgit had stored in .git/* was out of sync with where the branch\nhad been moved to.\n\n\n>\n>\n> Nicolas\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"61228","messageId":"20071128162002.GB20308@coredump.intra.peff.net","threadId":"11039","inReplyTo":"3AAC5548-A9AC-4236-B1F7-5CFDE11B52C4@adacore.com","subject":"Re: Rollback of git commands","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-28T16:20:02Z","receivedAt":"2007-11-28T16:20:02Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 27, 2007 at 11:07:29PM -0500, Geert Bosch wrote:\n\n> I have always wondered why refs and tags are not\n> in the regular object store. In a way, there\n> should be just one root pointer (SHA1) pointing\n> to a tree with refs, etc.\n\nAssuming that they also retain the \"having an object implies having all\nof the objects it points to\" property, then it makes it hard to talk\nabout subsets or single refs. If I fetch from you and you communicate\nyour repo state as some hash, then I am stuck getting _all_ of your\nrefs to complete this property.\n\n-Peff\n"},{"id":"61233","messageId":"9e4733910711280823q5fa14120scb6371a1465efca5@mail.gmail.com","threadId":"11039","inReplyTo":"20071128162002.GB20308@coredump.intra.peff.net","subject":"Re: Rollback of git commands","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2007-11-28T16:23:30Z","receivedAt":"2007-11-28T16:23:30Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 11/28/07, Jeff King wrote:\n> On Tue, Nov 27, 2007 at 11:07:29PM -0500, Geert Bosch wrote:\n>\n> > I have always wondered why refs and tags are not\n> > in the regular object store. In a way, there\n> > should be just one root pointer (SHA1) pointing\n> > to a tree with refs, etc.\n>\n> Assuming that they also retain the \"having an object implies having all\n> of the objects it points to\" property, then it makes it hard to talk\n> about subsets or single refs. If I fetch from you and you communicate\n> your repo state as some hash, then I am stuck getting _all_ of your\n> refs to complete this property.\n\npush/pull would still work at the branch level. The local state\ntracking objects wouldn't be exchanged.\n\n>\n> -Peff\n>\n\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"61235","messageId":"alpine.LFD.0.99999.0711281125320.9605@xanadu.home","threadId":"11039","inReplyTo":"9e4733910711280758x38ca3cdau4e62bfe8776e5c0d@mail.gmail.com","subject":"Re: Rollback of git commands","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-28T16:26:45Z","receivedAt":"2007-11-28T16:26:45Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 28 Nov 2007, Jon Smirl wrote:\n\n> On 11/28/07, Nicolas Pitre wrote:\n> > On Tue, 27 Nov 2007, Jon Smirl wrote:\n> >\n> > > Of course you've never screwed up a repository using git commands,\n> > > right? I've messed up plenty. A good way to mess up a repo is to get\n> > > the data in .git/* out of sync with what is in the repo. I'm getting\n> > > good enough with git that I can fix most mess up with a few edits, but\n> > > it took me two years to get to that point. Rolling back to a check\n> > > point is way easier. User error and a command failing are both equally\n> > > valid ways to mess up a repo.\n> >\n> > The reflog contains all your check points, for every modifications you\n> > make, even the stupid ones. You should look at it.\n> \n> The state contained in the other config files in .git/* is not getting\n> check pointed. I can use reflog to move my branch heads around. But\n> doing that does not undo the changes to the state recorded in .git/*.\n> After the error I encountered I moved my branch head back, but the\n> state stgit had stored in .git/* was out of sync with where the branch\n> had been moved to.\n\nIt's up to stgit to version control its state then. It may even use a \nreflog for it. All the machinery is there already.\n\n\nNicolas\n"},{"id":"61236","messageId":"20071128162832.GA890@coredump.intra.peff.net","threadId":"11039","inReplyTo":"9e4733910711280823q5fa14120scb6371a1465efca5@mail.gmail.com","subject":"Re: Rollback of git commands","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-28T16:28:32Z","receivedAt":"2007-11-28T16:28:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 28, 2007 at 11:23:30AM -0500, Jon Smirl wrote:\n\n> > Assuming that they also retain the \"having an object implies having all\n> > of the objects it points to\" property, then it makes it hard to talk\n> > about subsets or single refs. If I fetch from you and you communicate\n> > your repo state as some hash, then I am stuck getting _all_ of your\n> > refs to complete this property.\n> \n> push/pull would still work at the branch level. The local state\n> tracking objects wouldn't be exchanged.\n\nFair enough.\n\nMy spider sense still tingles about this, and I have the feeling that\nyou might run into weird merge problems when two refs are updated\nsimultaneously. I guess that shouldn't happen since you will write out\nthe complete \"here are the refs\" after every operation, leaving no room\nfor simultaneous updates, but I haven't given it enough thought to be\nsure there aren't funny corner cases.\n\n-Peff\n"},{"id":"61238","messageId":"9e4733910711280837o43003e93p470bb403e6bdd3bb@mail.gmail.com","threadId":"11039","inReplyTo":"alpine.LFD.0.99999.0711281125320.9605@xanadu.home","subject":"Re: Rollback of git commands","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2007-11-28T16:37:38Z","receivedAt":"2007-11-28T16:37:38Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 11/28/07, Nicolas Pitre wrote:\n> On Wed, 28 Nov 2007, Jon Smirl wrote:\n>\n> > On 11/28/07, Nicolas Pitre wrote:\n> > > On Tue, 27 Nov 2007, Jon Smirl wrote:\n> > >\n> > > > Of course you've never screwed up a repository using git commands,\n> > > > right? I've messed up plenty. A good way to mess up a repo is to get\n> > > > the data in .git/* out of sync with what is in the repo. I'm getting\n> > > > good enough with git that I can fix most mess up with a few edits, but\n> > > > it took me two years to get to that point. Rolling back to a check\n> > > > point is way easier. User error and a command failing are both equally\n> > > > valid ways to mess up a repo.\n> > >\n> > > The reflog contains all your check points, for every modifications you\n> > > make, even the stupid ones. You should look at it.\n> >\n> > The state contained in the other config files in .git/* is not getting\n> > check pointed. I can use reflog to move my branch heads around. But\n> > doing that does not undo the changes to the state recorded in .git/*.\n> > After the error I encountered I moved my branch head back, but the\n> > state stgit had stored in .git/* was out of sync with where the branch\n> > had been moved to.\n>\n> It's up to stgit to version control its state then. It may even use a\n> reflog for it. All the machinery is there already.\n\nGit has state in .git/* too, shouldn't it be version controlling it\ntoo? If git was version controlling the state in .git/* you'd have\ncheckpoints with the ability to roll back.\n\n\n>\n>\n> Nicolas\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"61240","messageId":"alpine.LFD.0.99999.0711281141150.9605@xanadu.home","threadId":"11039","inReplyTo":"9e4733910711280837o43003e93p470bb403e6bdd3bb@mail.gmail.com","subject":"Re: Rollback of git commands","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-28T16:46:48Z","receivedAt":"2007-11-28T16:46:48Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 28 Nov 2007, Jon Smirl wrote:\n\n> On 11/28/07, Nicolas Pitre wrote:\n> > On Wed, 28 Nov 2007, Jon Smirl wrote:\n> >\n> > > On 11/28/07, Nicolas Pitre wrote:\n> > > > On Tue, 27 Nov 2007, Jon Smirl wrote:\n> > > >\n> > > > > Of course you've never screwed up a repository using git commands,\n> > > > > right? I've messed up plenty. A good way to mess up a repo is to get\n> > > > > the data in .git/* out of sync with what is in the repo. I'm getting\n> > > > > good enough with git that I can fix most mess up with a few edits, but\n> > > > > it took me two years to get to that point. Rolling back to a check\n> > > > > point is way easier. User error and a command failing are both equally\n> > > > > valid ways to mess up a repo.\n> > > >\n> > > > The reflog contains all your check points, for every modifications you\n> > > > make, even the stupid ones. You should look at it.\n> > >\n> > > The state contained in the other config files in .git/* is not getting\n> > > check pointed. I can use reflog to move my branch heads around. But\n> > > doing that does not undo the changes to the state recorded in .git/*.\n> > > After the error I encountered I moved my branch head back, but the\n> > > state stgit had stored in .git/* was out of sync with where the branch\n> > > had been moved to.\n> >\n> > It's up to stgit to version control its state then. It may even use a\n> > reflog for it. All the machinery is there already.\n> \n> Git has state in .git/* too, shouldn't it be version controlling it\n> too? If git was version controlling the state in .git/* you'd have\n> checkpoints with the ability to roll back.\n\nWell, the .git directory contains data to identify what is actually \nversion controlled. If you start versioning the data used to implement \nthe versioning, don't you get into endless recursion here?\n\n\nNicolas\n\n\n\n\n> \n> \n> >\n> >\n> > Nicolas\n> > -\n> > To unsubscribe from this list: send the line \"unsubscribe git\" in\n> > the body of a message to majordomo@vger.kernel.org\n> > More majordomo info at http://vger.kernel.org/majordomo-info.html\n> >\n> \n> \n> -- \n> Jon Smirl\n> jonsmirl@gmail.com\n> \n\n\nNicolas\n"},{"id":"61241","messageId":"20071128165033.GA31218@elte.hu","threadId":"11039","inReplyTo":"ee77f5c20711271757h724d5fcep38f3c2354c54f20b@mail.gmail.com","subject":"Re: Rollback of git commands","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2007-11-28T16:50:33Z","receivedAt":"2007-11-28T16:50:33Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* David Symonds wrote:\n\n> On Nov 28, 2007 12:49 PM, Jon Smirl wrote:\n> > Rollback is too strong of name for this. Checkpoints would be better.\n> > The idea is to record the total system state at convenient moments and\n> > then allow moving back to the checkpointed state. The object store\n> > supports this, but the rest of the state in .git/* isn't being\n> > recorded.\n> \n> rsync -a .git /somewhere/safe\n> \n> I fear that what you ask becomes a chicken-and-egg scenario: where/how \n> is this checkpointing information going to be stored? If it's tightly \n> integrated with Git, what happens when you want to roll-back a \n> checkpoint-restore?\n\nwell, it would/could be the normal undo/redo semantics of editors: you \ncan undo-redo in a linear history fashion, in an unlimited way, but the \nmoment you modify any past point of history then the redo future is \noverriden. (but the 'past' up to that point is still recorded and \navailable)\n\nand this could all be driven via .git/logs - as long as all other \nmetadata is imported into the object store and the root of this git tree \nwould be represented in a single file. The logs are append-only as well, \nthe loss of them means the loss of undo/redo information, nothing else. \nFiguring out the linear history from the logs would be computationally \nexpensive, but that's not a big issue as 'undo/redo' would be a rare \noperation anyway.\n\nBut i guess i must be missing some obvious complication?\n\n\tIngo\n"},{"id":"61246","messageId":"9e4733910711280903w26e9821ah17db9ad468dea460@mail.gmail.com","threadId":"11039","inReplyTo":"alpine.LFD.0.99999.0711281141150.9605@xanadu.home","subject":"Re: Rollback of git commands","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2007-11-28T17:03:28Z","receivedAt":"2007-11-28T17:03:28Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 11/28/07, Nicolas Pitre wrote:\n> On Wed, 28 Nov 2007, Jon Smirl wrote:\n>\n> > On 11/28/07, Nicolas Pitre wrote:\n> > > On Wed, 28 Nov 2007, Jon Smirl wrote:\n> > >\n> > > > On 11/28/07, Nicolas Pitre wrote:\n> > > > > On Tue, 27 Nov 2007, Jon Smirl wrote:\n> > > > >\n> > > > > > Of course you've never screwed up a repository using git commands,\n> > > > > > right? I've messed up plenty. A good way to mess up a repo is to get\n> > > > > > the data in .git/* out of sync with what is in the repo. I'm getting\n> > > > > > good enough with git that I can fix most mess up with a few edits, but\n> > > > > > it took me two years to get to that point. Rolling back to a check\n> > > > > > point is way easier. User error and a command failing are both equally\n> > > > > > valid ways to mess up a repo.\n> > > > >\n> > > > > The reflog contains all your check points, for every modifications you\n> > > > > make, even the stupid ones. You should look at it.\n> > > >\n> > > > The state contained in the other config files in .git/* is not getting\n> > > > check pointed. I can use reflog to move my branch heads around. But\n> > > > doing that does not undo the changes to the state recorded in .git/*.\n> > > > After the error I encountered I moved my branch head back, but the\n> > > > state stgit had stored in .git/* was out of sync with where the branch\n> > > > had been moved to.\n> > >\n> > > It's up to stgit to version control its state then. It may even use a\n> > > reflog for it. All the machinery is there already.\n> >\n> > Git has state in .git/* too, shouldn't it be version controlling it\n> > too? If git was version controlling the state in .git/* you'd have\n> > checkpoints with the ability to roll back.\n>\n> Well, the .git directory contains data to identify what is actually\n> version controlled. If you start versioning the data used to implement\n> the versioning, don't you get into endless recursion here?\n\nYou would end up with a single non-version controlled sha pointer that\nwould need to be stored externally. That pointer would be the\nbeginning of the rollback log. It's just a normal commit chain.\n\nIn a totally version controlled system. .git/* would only contain\nobjects and the one pointer to the current state of the system.\n\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"61262","messageId":"87lk8imcxv.fsf@osv.gnss.ru","threadId":"11039","inReplyTo":"20071128165033.GA31218@elte.hu","subject":"Re: Rollback of git commands","fromName":"Sergei Organov","fromEmail":"osv@javad.com","sentAt":"2007-11-28T18:39:56Z","receivedAt":"2007-11-28T18:39:56Z","isPatch":false,"sender":{"key":"osv@javad.com","avatar":null},"body":"Ingo Molnar writes:\n\n> * David Symonds wrote:\n>\n>> On Nov 28, 2007 12:49 PM, Jon Smirl wrote:\n>> > Rollback is too strong of name for this. Checkpoints would be better.\n>> > The idea is to record the total system state at convenient moments and\n>> > then allow moving back to the checkpointed state. The object store\n>> > supports this, but the rest of the state in .git/* isn't being\n>> > recorded.\n>> \n>> rsync -a .git /somewhere/safe\n>> \n>> I fear that what you ask becomes a chicken-and-egg scenario: where/how \n>> is this checkpointing information going to be stored? If it's tightly \n>> integrated with Git, what happens when you want to roll-back a \n>> checkpoint-restore?\n>\n> well, it would/could be the normal undo/redo semantics of editors: you \n> can undo-redo in a linear history fashion, in an unlimited way, but the \n> moment you modify any past point of history then the redo future is \n> overriden. (but the 'past' up to that point is still recorded and \n> available)\n\nOr it could be Emacs-like: 'undo' is just another operation that is a\nsubject for further undo's ;) Then there is no need for 'redo', and no\nneed to override either the future or the past. Besides this obvious\ntechnical superiority will help to maintain git's reputation of being\nhard to grok ;)\n\n-- \nSergei.\n"},{"id":"61267","messageId":"alpine.LFD.0.99999.0711281349180.9605@xanadu.home","threadId":"11039","inReplyTo":"87lk8imcxv.fsf@osv.gnss.ru","subject":"Re: Rollback of git commands","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-28T18:52:12Z","receivedAt":"2007-11-28T18:52:12Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 28 Nov 2007, Sergei Organov wrote:\n\n> Ingo Molnar writes:\n> \n> > well, it would/could be the normal undo/redo semantics of editors: you \n> > can undo-redo in a linear history fashion, in an unlimited way, but the \n> > moment you modify any past point of history then the redo future is \n> > overriden. (but the 'past' up to that point is still recorded and \n> > available)\n> \n> Or it could be Emacs-like: 'undo' is just another operation that is a\n> subject for further undo's ;) Then there is no need for 'redo', and no\n> need to override either the future or the past.\n\nThe reflog does just that in fact, when it records your 'git reset' \noperations.\n\n> Besides this obvious technical superiority will help to maintain git's \n> reputation of being hard to grok ;)\n\nSure! ;)\n\n\nNicolas\n"},{"id":"61292","messageId":"Pine.LNX.4.64.0711281600320.5349@iabervon.org","threadId":"11039","inReplyTo":"9e4733910711280713n6b439866m55bea4824efd959@mail.gmail.com","subject":"Re: Rollback of git commands","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-11-28T21:47:22Z","receivedAt":"2007-11-28T21:47:22Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 28 Nov 2007, Jon Smirl wrote:\n\n> all my patches applied\n> git rebase\n> cursing.... I immediately knew what I had done\n> update stg and install it\n> stg repair\n> four of my 15 patches tried to apply, I received messages that there\n> were all empty\n> most stg commands won't work, they complain that the commit references\n> in the stg .git/* state are not correct.\n> \n> I then proceed to manually attempt repair.\n\nThis sounds like the content of the applied patches got pulled into the \nnon-stgit history of the branch it's working on, sort of like a stg commit \nexcept that stgit didn't know you'd done it. Then cleaning everything up \nfrom stgit's perspective caused all of those patches to become empty, \nsince they were already applied in the base.\n\nI think fundamental issue you're having is that stgit is implementing the \nfunctionality of quilt using git's engine, not providing a version control \nsystem for patch series, which is what you really want. I've actually been \nworking on a design for a git builtin for the idea that the patch series \nis your work product, and you want to version control that (additionally, \nyou want to use git's engine to help with working on the series and \nrepresent it).\n\nOut of curiousity, are you using stgit as an integrator (with your work \nbeing keeping a collection of patches produced separately up-to-date) or \nas a patch developer (with your work being producing a state containing a \nsingle large new feature while maintaining this change as a series of \nself-contained patches)? I've been thinking primarily about the integrator \ntask, in part because I've found it easy enough to do the developer task \nwithout anything other than current git. (That is, \"git rebase -i\" seems \nto work fine for making changes to a single logical patch series, all of \nwhose patches are prepared locally and aren't independantly named in some \nparticular fashion; the things that aren't handled are \"I need to replace \nthe pull of netdev.git with a new pull of netdev.git\" or \"I need to \nreplace '[PATCH] fix-the-frobnozzle-gadget' with \n'[PATCH v2] fix-the-frobnozzle-gadget'.)\n\nThe developer assist I'd actually like to see is: \"I've got a single \ncommit on top of a series of commits on top of an upstream commit; I want \nto distribute the changes made in the final commit to points in the series \nwhere the code that gets replaced (or context that gets inserted into) in \nthe final commit gets introduced, with interactive stuff for sticking \nother hunks into particular commits or into new commits at some point in \nthe series.\" That is, I want to do my revision of a patch series on the \nfinal commit of the series, and then have these changes distributed to the \nappropriate points, rather than doing work on intermediate states (unless \nwhat I'm fixing is stub code that gets replaced again in a later patch).\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"61296","messageId":"795F24E6-9145-4007-95EB-DB63D9F6295A@midwinter.com","threadId":"11039","inReplyTo":"Pine.LNX.4.64.0711281600320.5349@iabervon.org","subject":"Re: Rollback of git commands","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-11-28T21:58:59Z","receivedAt":"2007-11-28T21:58:59Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"On Nov 28, 2007, at 1:47 PM, Daniel Barkalow wrote:\n> (That is, \"git rebase -i\" seems\n> to work fine for making changes to a single logical patch series, \n> all of\n> whose patches are prepared locally and aren't independantly named in \n> some\n> particular fashion; the things that aren't handled are \"I need to \n> replace\n> the pull of netdev.git with a new pull of netdev.git\" or \"I need to\n> replace '[PATCH] fix-the-frobnozzle-gadget' with\n> '[PATCH v2] fix-the-frobnozzle-gadget'.)\n\nI use rebase -i for that last case and it works fine -- I mark the \nappropriate commit as \"edit\" in the patch list and the rebase stops \nthere, at which point I can update the patch in any way I see fit: \ntweak it a bit, replace it with a different change entirely, change \nthe commit message, etc. What's missing from rebase -i in that \nrespect? I guess it's not as easy to script for automated patch \nreplacement.\n\n-Steve\n"},{"id":"61312","messageId":"Pine.LNX.4.64.0711281702140.5349@iabervon.org","threadId":"11039","inReplyTo":"795F24E6-9145-4007-95EB-DB63D9F6295A@midwinter.com","subject":"Re: Rollback of git commands","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-11-28T22:48:50Z","receivedAt":"2007-11-28T22:48:50Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 28 Nov 2007, Steven Grimm wrote:\n\n> On Nov 28, 2007, at 1:47 PM, Daniel Barkalow wrote:\n> >(That is, \"git rebase -i\" seems\n> >to work fine for making changes to a single logical patch series, all of\n> >whose patches are prepared locally and aren't independantly named in some\n> >particular fashion; the things that aren't handled are \"I need to replace\n> >the pull of netdev.git with a new pull of netdev.git\" or \"I need to\n> >replace '[PATCH] fix-the-frobnozzle-gadget' with\n> >'[PATCH v2] fix-the-frobnozzle-gadget'.)\n> \n> I use rebase -i for that last case and it works fine -- I mark the appropriate\n> commit as \"edit\" in the patch list and the rebase stops there, at which point\n> I can update the patch in any way I see fit: tweak it a bit, replace it with a\n> different change entirely, change the commit message, etc. What's missing from\n> rebase -i in that respect? I guess it's not as easy to script for automated\n> patch replacement.\n\nJust that you have to find the patch yourself and replace it; if you're \ndoing this a lot, you'll want to say \"here's a new version of \nfix-the-frobnozzle-gadget, do the right thing\". Also, for series items \nthat are pulling some remote tree, you want it to remember the info, so \nyou can just say \"pull git-netdev\" and have it fetch the latest from the \nappropriate remote and replace the merge commit with a new merge commit.\n\nI think that people in this role using quilt do it by: \"quilt pop -a; \nreplace the patch file without looking at the series file; quilt push \n-a\"; in the (hopefully) common case, you don't have to worry about any of \nthe details, which is why the task remains tractable.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"61327","messageId":"9e4733910711281542r5b1e5dd9o68ff8565f9000453@mail.gmail.com","threadId":"11039","inReplyTo":"Pine.LNX.4.64.0711281600320.5349@iabervon.org","subject":"Re: Rollback of git commands","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2007-11-28T23:42:56Z","receivedAt":"2007-11-28T23:42:56Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 11/28/07, Daniel Barkalow wrote:\n> On Wed, 28 Nov 2007, Jon Smirl wrote:\n>\n> > all my patches applied\n> > git rebase\n> > cursing.... I immediately knew what I had done\n> > update stg and install it\n> > stg repair\n> > four of my 15 patches tried to apply, I received messages that there\n> > were all empty\n> > most stg commands won't work, they complain that the commit references\n> > in the stg .git/* state are not correct.\n> >\n> > I then proceed to manually attempt repair.\n>\n> This sounds like the content of the applied patches got pulled into the\n> non-stgit history of the branch it's working on, sort of like a stg commit\n> except that stgit didn't know you'd done it. Then cleaning everything up\n> from stgit's perspective caused all of those patches to become empty,\n> since they were already applied in the base.\n>\n> I think fundamental issue you're having is that stgit is implementing the\n> functionality of quilt using git's engine, not providing a version control\n> system for patch series, which is what you really want. I've actually been\n> working on a design for a git builtin for the idea that the patch series\n> is your work product, and you want to version control that (additionally,\n> you want to use git's engine to help with working on the series and\n> represent it).\n>\n> Out of curiousity, are you using stgit as an integrator (with your work\n> being keeping a collection of patches produced separately up-to-date) or\n> as a patch developer (with your work being producing a state containing a\n> single large new feature while maintaining this change as a series of\n> self-contained patches)? I've been thinking primarily about the integrator\n> task, in part because I've found it easy enough to do the developer task\n> without anything other than current git. (That is, \"git rebase -i\" seems\n> to work fine for making changes to a single logical patch series, all of\n> whose patches are prepared locally and aren't independantly named in some\n> particular fashion; the things that aren't handled are \"I need to replace\n> the pull of netdev.git with a new pull of netdev.git\" or \"I need to\n> replace '[PATCH] fix-the-frobnozzle-gadget' with\n> '[PATCH v2] fix-the-frobnozzle-gadget'.)\n\nI'm a patch developer. You need to change the patches continuously to\ntrack feedback on the lkml type lists. You also have to rebase in\norder to keep tracking head. Other people often work on the same\nthings and this triggers merges against the pending patches.\n\nAnother class of problem is that I can write code a lot faster than I\ncan get it into the kernel. Currently I have 14 pending PPC patches\nthat I'm maintaining while I try and get a core change into the i2c\nsubsystem. All of the other patches depend on the core i2c patch.\n\nOf course the version of the i2c patch that finally gets accepted will\nprobably cause me to have to rework the whole patch stack again.\n\nstgit is what you need for this work flow. It lets me easily rebase or\nedit specific patches. It also lets me easily maintain private debug\npatches that I can apply as needed.\n\nI'd just like for stgit to become a core part of git so that is can be\nmade more bullet proof. I'm losing my patch stack every couple of\nweeks. It's normally a \"user error\" but it is way to easy to make\nthese user errors.\n\n\n>\n> The developer assist I'd actually like to see is: \"I've got a single\n> commit on top of a series of commits on top of an upstream commit; I want\n> to distribute the changes made in the final commit to points in the series\n> where the code that gets replaced (or context that gets inserted into) in\n> the final commit gets introduced, with interactive stuff for sticking\n> other hunks into particular commits or into new commits at some point in\n> the series.\" That is, I want to do my revision of a patch series on the\n> final commit of the series, and then have these changes distributed to the\n> appropriate points, rather than doing work on intermediate states (unless\n> what I'm fixing is stub code that gets replaced again in a later patch).\n>\n> -Daniel\n> *This .sig left intentionally blank*\n>\n\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"61383","messageId":"20071129082821.GC22397@thunk.org","threadId":"11039","inReplyTo":"9e4733910711281542r5b1e5dd9o68ff8565f9000453@mail.gmail.com","subject":"Re: Rollback of git commands","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-11-29T08:28:21Z","receivedAt":"2007-11-29T08:28:21Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Wed, Nov 28, 2007 at 06:42:56PM -0500, Jon Smirl wrote:\n> I'm a patch developer. You need to change the patches continuously to\n> track feedback on the lkml type lists. You also have to rebase in\n> order to keep tracking head. Other people often work on the same\n> things and this triggers merges against the pending patches.\n\nYeah, I use guilt for projects where I have a patch queue that takes a\nwhile to merge into the mainline, due to quality control or review\nguidelines that still need to be met. Basically the kernel has a\ndifferent workflow than git, where each project or developer has a\nseparate patch queue that is maintained inside git (possibly with\nguilt or stgit as helpers) or quilt, instead of a centrally managed pu\nbranch. This is I suspect mainly a scaling issue; it's hard to keep a\ncentrally maintained pu branch because anytime someone wants to make a\nchange to one of their topic branches, they have to go through the\ncentral maintainer. The closest analogue to the pu branch is Andrew\nMorton's akpm, and he gets grumpy when there are merge conflicts\nbetween the various branches and patch queues that he pulls from in\norder to make the -mm tree for integration testing.\n\n> I'd just like for stgit to become a core part of git so that is can be\n> made more bullet proof. I'm losing my patch stack every couple of\n> weeks. It's normally a \"user error\" but it is way to easy to make\n> these user errors.\n\nI haven't tried using stgit in quite a while mainly because I was\nfinding it too easy to lose my patch queue. It was happening to me\n*way* to often, and while it sounds like it's gotten better due to\nadding more sanity checks --- and when I tried it last, \"stg repair\"\ndidn't exist --- it sounds like it is still possible for someone who\ntypo's a command to get themselves into trouble. I'm sure it's not an\nissue for the stgit developers because they know which commands to\navoid, but if something isn't 100% bulletproof --- I get nervous.\n\nSo my solution to this problem is I use guilt. I *like* the fact that\nthe primary storage mechanism is actual flat ASCII patch files, since\nas a result I've never lost a patch stack --- ASCII patch files are\nmuch more robust. My way of rebasing a set of patches is very simple;\nI just do \"guilt pop -a; git merge master; guilt push -a\" --- and if\nthere are any conflicts, then I do a \"guilt push -f\", fix up the\nconflicts, follow it with a \"guilt refresh\", and then resume pushing\nthe rest of my patches sing \"guilt push -a\". It just works; no muss,\nno fuss, no dirty dishes.\n\nAnother thing this allows me to do is that it is possible to put the\nguilt patch stack itself under git control. This allows me to go\nbackwards in time and see what the patch stack looked like n days or n\nweeks ago. A comment in the patch header indicates what version of\nthe kernel the patch stack was meant against.\n\nFor example for ext4 development the guilt patch stack is themselves\nstored using git on repo.or.cz, with multiple people having access to\npush updates to the patch queue. Before I start hacking the ext4,\nI'll do run the command \"(cd .git/patches/ext4dev; git pull\") to check\nfor new updates in the ext4 patch queue, and if it has changed, I'll\ndo a \"guilt pop -a; guilt push -a\" to refresh the working directory\nand ext4dev branch in my Linux git tree. When I'm done making\nchanges, by using commands such as \"guilt pop\", \"guilt refresh\",\n\"guilt pop\", et. al., I'll commit changes in the .git/patches/ext4dev\ntree, and then push them back to repo.or.cz. \n\nWe also have a system where an automated build/test server checks\nevery few hours if the patch queue on repo.or.cz has changed, and if\nso, it pulls the patch queue, and then builds and tests the patch\nqueue on a wide variety of hardware architectures (i386, x86_64, ia64,\nppc64, s390, etc.) and sends an e-mail pack to the developers list\ntelling us which test hardware platforms passed, and which platforms\nfail. Actually, we do two such tests --- one up to the \"stable\" point\nin the patch series, which represents the next set of patches we plan\nto push to Linus during the next merge window, and one for the entire\npatch queue (stable plus unstable patches that need more work).\n\nIt works quite well for us --- and while there are some advanced\nfeature that stgit has which guilt doesn't, the feeling of safety of\nknowing that the ASCII patch files won't get lost, and the ability to\ndo things such as shared patch queue maintenance and ability to keep\nthe patch queue under SCM are enough of a win that at least for my\npurposes guilt is the better choice.\n\n> stgit is what you need for this work flow. It lets me easily rebase or\n> edit specific patches. It also lets me easily maintain private debug\n> patches that I can apply as needed.\n\nAs mentioned above, I use guilt for major patch queues. For smaller\nsets of patches, such as private debug patches, I just use a separate\ngit branch for those, and keep them up-to-date by using \"git rebase\"\nand \"git rebase -i\". Then when I want to enable some debug patch,\nI'll just do a \"git merge\" in a scratch branch.\n\n\t\t\t\t\t\t\t- Ted\n"},{"id":"61381","messageId":"20071129084219.GA2257@diana.vm.bytemark.co.uk","threadId":"11039","inReplyTo":"alpine.LFD.0.99999.0711281125320.9605@xanadu.home","subject":"Re: Rollback of git commands","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-11-29T08:42:19Z","receivedAt":"2007-11-29T08:42:19Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-11-28 11:26:45 -0500, Nicolas Pitre wrote:\n\n> On Wed, 28 Nov 2007, Jon Smirl wrote:\n>\n> > The state contained in the other config files in .git/* is not\n> > getting check pointed. I can use reflog to move my branch heads\n> > around. But doing that does not undo the changes to the state\n> > recorded in .git/*. After the error I encountered I moved my\n> > branch head back, but the state stgit had stored in .git/* was out\n> > of sync with where the branch had been moved to.\n>\n> It's up to stgit to version control its state then. It may even use\n> a reflog for it. All the machinery is there already.\n\nI agree -- this is StGit's job.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"}]}