Re: [STGIT][PATCH] new: translate non word characters in patch name to '-'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Hannes Eder" <hannes@xxxxxxxxxxxxxx> writes:

> On 12/28/08, Karl Hasselström <kha@xxxxxxxxxxx> wrote:
>> 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.
>
> What about instead of 'fail with an informative message', just issue a
> warning that
> the name has been mangled. I use pathnames in patch names frequently,
> so this would be very handy.

No, I agree with Karl. For example, a tool (such as the Emacs
frontend) might want to do a "stg new foobar" and then do something
with the patch it now knows is called "foobar". And if it was called
something else the tool will fail.

-- 
David Kågedal

--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux