On Tue, Oct 16, 2018 at 05:17:53PM +0200, Duy Nguyen wrote:
> On Mon, Oct 15, 2018 at 4:21 AM brian m. carlson
> <sandals@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > The transition plan anticipates us using a syntax such as "^{sha1}" for
> > disambiguation. Since this is a syntax some people will be typing a
> > lot, it makes sense to provide a short, easy-to-type syntax. Omitting
> > the dash doesn't create any ambiguity, but it does make it shorter and
>
> "but" or "and"? I think both clauses are on the same side ... or did
> you mean omitting the dash does create ambiguity?
I think "but" is correct here. This is a standard "This doesn't make it
worse, but it does make it better" phrase. The "but" creates a contrast
between what it doesn't do and what it does.
I'm trying to come up with a different way to say this that may be
easier to understand, but I'm failing to do so in a natural-sounding
way. Does the following sound better?
Omitting the dash doesn't introduce any ambiguity; however, it does
make the text shorter and easier to type, especially for touch
typists.
> > easier to type, especially for touch typists. In addition, the
> > transition plan already uses "sha1" in this context.
> >
> > Rename the name of SHA-1 implementation to "sha1".
> >
> > Note that this change creates no backwards compatibility concerns, since
> > we haven't yet used this field in any serialized data formats.
>
> But we're not going to use this _string_ in any data format either
> because we'll stick to format_id field anyway, right?
We'll use it in extensions.objectFormat and other config files. But in
anything binary, we'll use format_id.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature
