Re: [PATCH 1/1] rebase -r: let `label` generate safer labels
- From
Philip Oakley <philipoakley@iee.email>
- Date
- Sep 2, 2019, 22:13 UTC
- Message-ID
- <b39e5215-f5d6-eca3-7f08-813b5508d779@iee.email>
- In-Reply-To
- <CAOjrSZtw+wYHxFRQCfb80xzm9OsGDh2rW8uD+AYYdmDPxk5DFQ@mail.gmail.com>
On 02/09/2019 22:47, Matt Rogers wrote:
Show 5 quoted lines
> 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...
Show 21 quoted lines
> > > > 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