From: Karl Hasselström <kha@treskal.com>
Date: Sun, 28 Dec 2008 20:49:38 GMT
Subject: Re: [STGIT][PATCH] new: translate non word characters in patch name to '-'
Message-ID: <20081228204938.GA13143@diana.vm.bytemark.co.uk>
In-Reply-To: <49562413.0437560a.287d.5133@mx.google.com>

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@hanneseder.net>
> ---
>
> 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@treskal.com
      www.treskal.com/kalle