On 2008-12-27 13:37:20 +0100, Hannes Eder wrote: > This allows following usage: > > $ stg new full/path/file-fix-foobar > Now at patch "full-path-file-fix-foobar" > > Signed-off-by: Hannes Eder <hannes@xxxxxxxxxxxxxx> > --- > > I ran into as a '/' in a patch messed up stgit. > > I find this useful as 'stg uncommit' does the same translation. Clearly, bad path names shouldn't mess anything up -- see https://gna.org/bugs/?10919 But I would prefer "stg new" to quit with an error message when given an illegal patch name, not silently mangle it. (Of course, the commands that generate patch names from commit messages -- such as "stg new" when not given an explicit patch name -- should mangle the commit message as much as necessary. But when the user gives us a patch name, we should either use that as is or fail with an informative message.) I think the right thing to do would be to construct a function that validates patch names (I don't think we have one right now), and then call it whenever we need to check if a patch name is OK. Such as when the user gives us the name of a new patch. And when we've auto-generated a patch name from a commit message, we should probably assert that that the check function is OK with the name. -- Karl Hasselström, kha@xxxxxxxxxxx www.treskal.com/kalle -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
