{"thread":{"id":"10464","subject":"stgit restrictions on patch names","startedAt":"2007-10-25T19:48:08Z","lastAt":"2007-10-29T16:14:34Z","messageCount":3,"participants":["Yann Dirson","Karl Hasselström","Catalin Marinas"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"57227","messageId":"20071025194808.GV26436@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"10464","inReplyTo":null,"subject":"stgit restrictions on patch names","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-10-25T19:48:08Z","receivedAt":"2007-10-25T19:48:08Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"Looks like stgit is now more picky on patch names than in used to be:\n\n$ stg branch --clone v2.0.6-debian\nChecking for changes in the working directory ... done\nCloning current branch to \"v2.0.6-debian\" ...\n  No log for 01_springelectrical\nstg branch: Invalid patch name: \"10_g++4.0_build_failures\"\n$\n\n\n=> the result of the cloning operation is a partial clone.  Do we want to:\n\n- implement a mechanism for checking beforehand that the operation\nwill not fail ?  Seems awkward to duplicate checks already found\nelsewhere.\n\n- wait for proper transactions so we can rollback on error ?\n\n- on clone error, delete the newly-created stack ?  I'd vote for this\none, until the previous one gets done.\n\n\n=> is there any particular reason why we would refuse \"+\" ?\n"},{"id":"57261","messageId":"20071026072924.GA11286@diana.vm.bytemark.co.uk","threadId":"10464","inReplyTo":"20071025194808.GV26436@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: stgit restrictions on patch names","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-10-26T07:29:24Z","receivedAt":"2007-10-26T07:29:24Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-10-25 21:48:08 +0200, Yann Dirson wrote:\n\n> Do we want to:\n>\n> - implement a mechanism for checking beforehand that the operation\n> will not fail? Seems awkward to duplicate checks already found\n> elsewhere.\n\nDuplication is bad. Calling the same verification function more times\nthan necessary is still bad, but maybe not so bad that it wouldn't be\nOK.\n\n> - wait for proper transactions so we can rollback on error ?\n\nYes, this is what we should aim for. I'm working on code that'll\neventually give us this if it pans out.\n\n> - on clone error, delete the newly-created stack ? I'd vote for this\n> one, until the previous one gets done.\n\nSeems reasonable.\n\n> => is there any particular reason why we would refuse \"+\" ?\n\nNot that I can think of at the moment, except maybe future-proofing.\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"57485","messageId":"b0943d9e0710290914p4163ffabt5767fdb2ab8d91d4@mail.gmail.com","threadId":"10464","inReplyTo":"20071025194808.GV26436@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: stgit restrictions on patch names","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-10-29T16:14:34Z","receivedAt":"2007-10-29T16:14:34Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 25/10/2007, Yann Dirson <ydirson@altern.org> wrote:\n> Looks like stgit is now more picky on patch names than in used to be:\n\nIt's not that we explicitly disallows \"+\" but I think I tried to avoid\nsome wrong patch names but was too lazy to create a better regexp.\n\nAs a quick fix, we could re-generate a patch name if it is invalid.\n\n> => the result of the cloning operation is a partial clone.  Do we want to:\n>\n> - implement a mechanism for checking beforehand that the operation\n> will not fail ?  Seems awkward to duplicate checks already found\n> elsewhere.\n>\n> - wait for proper transactions so we can rollback on error ?\n>\n> - on clone error, delete the newly-created stack ?  I'd vote for this\n> one, until the previous one gets done.\n\nI think the last one is the simplest to implement, while the second is\nnicer, I've never found the time to investigate it properly.\n\n-- \nCatalin\n"}]}