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@crustytoothpaste.net> 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