git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: "Horst H. von Brand" <vonbrand@inf.utfsm.cl>
Cc: "Shawn O. Pearce" <spearce@spearce.org>,
	Nicolas Pitre <nico@cam.org>,
	git@vger.kernel.org, Matthias Lederhofer <matled@gmx.net>
Subject: Re: [PATCH] Hash name is SHA-1
Date: Thu, 25 Jan 2007 15:44:23 -0800	[thread overview]
Message-ID: <7vr6ti659k.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <20070125230302.GB13677@moooo.ath.cx> (Matthias Lederhofer's message of "Fri, 26 Jan 2007 00:03:02 +0100")

Matthias Lederhofer <matled@gmx.net> writes:

> The patch should probably only change sha1 to SHA-1 and not reformat
> the initialisation of _usage arrays or the comments (new line before
> first line of comment).  If the reformatting is desired it should be a
> separate patch imho.

I do agree the original patch conflates many different things,
and it would be nicer to do this clean-up as separate pieces.

* Code and comment reformatting.

  I agree that multi-line comment should begin with "/*\n",
  the comment sentences should begin with an indent and "* ",
  and the comment block should end with an indent and "*/\n".

  But this obviously belongs to a separate clean-up.

* The official name of these 40-hexdigit thingy we use to name
  objects is "object name" (see Documentation/glossary.txt).

  Taking an example from this hunk from 'update' hook
  documentation:

    @@ -30,12 +30,12 @@ and executable, it is called with three parameters:

            $GIT_DIR/hooks/update refname sha1-old sha1-new

    +The refname parameter is relative to $GIT_DIR; e.g. for the master
    +head this is "refs/heads/master".  The two sha1 are the object names
    +for the refname before and after the update.  Note that the hook is
    +called before the refname is updated, so either sha1-old is 0{40}
    +(meaning there is no such ref yet), or it should match what is
    +recorded in refname.

  I would prefer "the two object names are for the refname before...".

* Some commands take any object name, while some others only
  take committish.  For example, this hunk for show-branch:

    @@ -29,7 +29,7 @@ no <rev> nor <glob> is given on the command line.
     OPTIONS
     -------
     <rev>::
    -	Arbitrary extended SHA1 expression (see `git-rev-parse`)
    +	Arbitrary extended SHA-1 expression (see `git-rev-parse`)
            that typically names a branch HEAD or a tag.

     <glob>::

  is not Horst's fault but this needs to name a committish, so
  rephrasing it to "an arbitrary object name" is not even correct
  (let alone spellfixing SHA-1).

* The name of the hash function we currently happen to use, in
  order to come up with an "object name", is SHA-1 not SHA1.

  Currently we say sha1 and sha-1 interchangeably, but if we aim
  for consistency we should use the latter thoughout.  For example:

    @@ -59,7 +59,7 @@ OPTIONS
            one.

     --symbolic::
    -	Usually the object names are output in SHA1 form (with
    +	Usually the object names are output in SHA-1 form (with
            possible '{caret}' prefix); this option makes them output in a
            form as close to the original input as possible.

  is a good change.  But at the same time we might want to say
  just "are output as their hexadecimal values".

  reply	other threads:[~2007-01-25 23:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-25 12:50 Some cleanups Horst H. von Brand
2007-01-25 12:50 ` [PATCH] Hash name is SHA-1 Horst H. von Brand
2007-01-25 17:01   ` Shawn O. Pearce
2007-01-25 17:10     ` Nicolas Pitre
2007-01-25 18:56       ` Horst H. von Brand
2007-01-25 19:05         ` Shawn O. Pearce
2007-01-25 23:03   ` Matthias Lederhofer
2007-01-25 23:44     ` Junio C Hamano [this message]
2007-01-26 11:54       ` Andy Parkins
2007-01-26 23:46         ` Junio C Hamano
2007-01-26 11:34   ` Jakub Narebski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vr6ti659k.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=matled@gmx.net \
    --cc=nico@cam.org \
    --cc=spearce@spearce.org \
    --cc=vonbrand@inf.utfsm.cl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).