On 02/09/2019 22:47, Matt Rogers wrote:
I can redo the commit, I had thought that I had previously fixed the
author but I guess I was mistaken.
As for issues with non utf-8 encodings, I don't know of any simple way
to check for those except for restricting to asci alphanumeric characters
If I read the Wikipedia article [1] about the utf-8 design choices it is
pretty reasonable and robust most of the time, though that maybe a part
one way trapdoor.
Also the code given doesn't resolve onelines that consist only of
restricted file names (e.g. COM, NUL, etc. On windows)
It maybe that the rebase doc may need (if it happens) a short comment
warning of that.
Also need to check if the `label_oid()` function actually makes the
label distinct, hence prevents such labels from being used as such a
restricted file name - i.e. does it include the oid element.
Ultimately the label could be tweaked to have say the 4char prefix to
fool the Windows 'starts with' name detection - which assumes I
understand how some of those bad filenames are detected...
On Mon, Sep 2, 2019, 5:24 PM Philip Oakley <philipoakley@iee.email> wrote:
On 02/09/2019 19:29, Junio C Hamano wrote:
> I see there are "lets make sure it is unique by suffixing "-%d" in
> other codepaths; would that help if this piece of code yields a
> label that is not unique?
maybe use a trailing 4 characters of the oid to get a reasonably
unique
label?
Oh, just seen dscho's "we make sure that the labels are unique,
via the
`label_oid()` function!", maybe needs mentioning in the commit
message
if re-rolled.
Philip
[1] https://en.wikipedia.org/wiki/UTF-8#Description
