From: Philip Oakley Date: Mon, 02 Sep 2019 22:13:17 GMT Subject: Re: [PATCH 1/1] rebase -r: let `label` generate safer labels Message-ID: In-Reply-To: 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 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