| Message ID | 20181015021900.1030041-2-sandals@crustytoothpaste.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Base SHA-256 implementation | expand |
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? > 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?
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.
diff --git a/sha1-file.c b/sha1-file.c index a4367b8f04..e29825f259 100644 --- a/sha1-file.c +++ b/sha1-file.c @@ -97,7 +97,7 @@ const struct git_hash_algo hash_algos[GIT_HASH_NALGOS] = { NULL, }, { - "sha-1", + "sha1", /* "sha1", big-endian */ 0x73686131, GIT_SHA1_RAWSZ,
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 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. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> --- sha1-file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)