{"thread":{"id":"9870","subject":"Re: Stg AssertionError in sink command","startedAt":"2007-09-15T22:37:21Z","lastAt":"2007-09-15T23:52:21Z","messageCount":2,"participants":["Catalin Marinas","Karl Hasselström"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"53145","messageId":"b0943d9e0709151537k51f2f8d5w5a9bbfef84f82747@mail.gmail.com","threadId":"9870","inReplyTo":"9e4733910709131308la9b3e44le70e1fac2b339189@mail.gmail.com","subject":"Re: Stg AssertionError in sink command","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-09-15T22:37:21Z","receivedAt":"2007-09-15T22:37:21Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 13/09/2007, Jon Smirl wrote:\n> Patch 008 was hidden and I used unhide to bring it back. But the\n> hide/unhide process moved it to the top of the stack. I need to sink\n> it back down to where it came from. Shouldn't hide/unhide preserve the\n> patch position in the stack?\n\nI now got the time to read this thread in more detail.\n\nThe initial implementation of hide/unhide was to preserve the patch\nposition in the stack. This behaviour was really confusing for people\nsince pushing a patch after the hidden one actually forced the pushing\nof the hidden patch, which isn't normally shown by 'series'. I decided\nafterwards to create a third category of patches - 'hidden' (the other\ntwo being applied and unapplied). This cleared the unpredictable\nbehaviour when pushing since hidden patches cannot be pushed.\n\nKarl's patch does the correct thing of raising an error if sinking\nbelow an unapplied patch.\n\nI implemented the hidden patches feature just to hide some patches I\nno longer need (various tests or early prototypes of some patches) but\nI still want to keep them around in case I have to look again.\n\nRegarding the reordering of the unapplied patches, at the moment you\ncan (but I *don't* recommend) edit .git/patches//unapplied.\nMaybe the 'float' and 'sink' functionality could be modified to also\nact on unapplied patches (with a --unapplied option). I don't think a\nseparate command would be needed as it duplicates a lot of\nfunctionality from the above.\n\n-- \nCatalin\n"},{"id":"53154","messageId":"20070915235221.GE25507@diana.vm.bytemark.co.uk","threadId":"9870","inReplyTo":"b0943d9e0709151537k51f2f8d5w5a9bbfef84f82747@mail.gmail.com","subject":"Re: Stg AssertionError in sink command","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-09-15T23:52:21Z","receivedAt":"2007-09-15T23:52:21Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-09-15 23:37:21 +0100, Catalin Marinas wrote:\n\n> The initial implementation of hide/unhide was to preserve the patch\n> position in the stack. This behaviour was really confusing for\n> people since pushing a patch after the hidden one actually forced\n> the pushing of the hidden patch, which isn't normally shown by\n> 'series'. I decided afterwards to create a third category of patches\n> - 'hidden' (the other two being applied and unapplied). This cleared\n> the unpredictable behaviour when pushing since hidden patches cannot\n> be pushed.\n\nI agree that the new semantics is way saner (though I'm still not\nentirely convinced that hiding patches is a good idea in the first\nplace). But the man pages should probably point out clearly that\nhidden patches must be unapplied.\n\n> Karl's patch does the correct thing of raising an error if sinking\n> below an unapplied patch.\n>\n> Regarding the reordering of the unapplied patches, at the moment you\n> can (but I *don't* recommend) edit .git/patches//unapplied.\n> Maybe the 'float' and 'sink' functionality could be modified to also\n> act on unapplied patches (with a --unapplied option). I don't think\n> a separate command would be needed as it duplicates a lot of\n> functionality from the above.\n\nWhy the extra option? Just do the right thing, since it's unambiguous\nwhat the right thing is.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"}]}