From: "brian m. carlson" <firstname.lastname@example.org> To: Chris Torek <email@example.com> Cc: Taylor Blau <firstname.lastname@example.org>, Denton Liu <email@example.com>, Git Mailing List <firstname.lastname@example.org> Subject: Re: [PATCH 2/4] builtin/rev-parse: learn --null-oid Date: Sun, 20 Sep 2020 18:58:17 +0000 [thread overview] Message-ID: <20200920185817.GJ67496@camp.crustytoothpaste.net> (raw) In-Reply-To: <CAPx1Gvd6vcvM410wZUZygr4-2Ob6gaScF3DnBtWWsT95XDmKSQ@mail.gmail.com> [-- Attachment #1: Type: text/plain, Size: 2015 bytes --] On 2020-09-20 at 04:25:33, Chris Torek wrote: > On Fri, Sep 18, 2020 at 2:34 PM brian m. carlson > <email@example.com> wrote: > > What I typically do when I write shell scripts, and which may obviate > > the need for this patch is turn this: > > > > [ "$oid" = 0000000000000000000000000000000000000000 ] > > > > into this: > > > > echo "$oid" | grep -qsE '^0+$' > > > > This is slightly less efficient, but it's also backwards compatible > > with older Git version assuming you have a POSIX grep. > > Note that a lot of `grep`s do not have `-q` and/or `-s` so the > portable variant of this is `grep '^0+$' >/dev/null` (you only need > the `2>&1` part if you're concerned about bad input files or > an error on a pipe or something). If we're looking for best compatibility here, then using egrep and /dev/null is best, I agree. I personally use the POSIX version because it's been that way since at least 2001 and I don't have a problem with requiring compliance with a 19-year-old standard. But for Git, we should definitely do whatever we do in the testsuite if we use this approach, since presumably that works everywhere. As Andreas pointed out, there are ways to avoid the external process that we could stuff in a shell function. I'm not picky. > > I'm not sure we need an empty tree and empty blob object, because it's > > pretty easy to write these: > > > > git hash-object -t tree /dev/null > > git hash-object -t blob /dev/null > > > > That's what I've done in some of the transition code at least. > > That's what's recommended in my 2012 stackoverflow Q&A, too. > The use of `/dev/null` directly here is perhaps unsatisfactory on > old Windows systems, though...? I believe all modern versions of Git for Windows provide /dev/null via the shell, since it's required for a lot of things to work, so I'm not worried about this case. It is definitely good to think about Windows, though. -- brian m. carlson: Houston, Texas, US [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2020-09-20 18:58 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-18 11:19 [PATCH 0/4] sample hooks: become hash agnostic Denton Liu 2020-09-18 11:19 ` [PATCH 1/4] hooks--pre-push.sample: prefer $() for command substitution Denton Liu 2020-09-18 16:57 ` Eric Sunshine 2020-09-18 11:19 ` [PATCH 2/4] builtin/rev-parse: learn --null-oid Denton Liu 2020-09-18 14:11 ` Taylor Blau 2020-09-18 14:16 ` Taylor Blau 2020-09-18 18:16 ` Junio C Hamano 2020-09-18 18:21 ` Taylor Blau 2020-09-18 21:26 ` brian m. carlson 2020-09-20 4:25 ` Chris Torek 2020-09-20 18:58 ` brian m. carlson [this message] 2020-09-20 15:35 ` Taylor Blau 2020-09-20 16:03 ` Andreas Schwab 2020-09-18 11:19 ` [PATCH 3/4] hooks--pre-push.sample: use hash-agnostic null OID Denton Liu 2020-09-18 17:06 ` Eric Sunshine 2020-09-18 11:19 ` [PATCH 4/4] hooks--update.sample: " Denton Liu 2020-09-18 17:08 ` Eric Sunshine 2020-09-18 21:35 ` [PATCH 0/4] sample hooks: become hash agnostic brian m. carlson 2020-09-23 9:38 ` [PATCH v2 0/3] " Denton Liu 2020-09-23 9:38 ` [PATCH v2 1/3] hooks--pre-push.sample: modernize script Denton Liu 2020-09-23 9:38 ` [PATCH v2 2/3] hooks--pre-push.sample: use hash-agnostic zero OID Denton Liu 2020-09-23 9:38 ` [PATCH v2 3/3] hooks--update.sample: " Denton Liu 2020-09-23 16:34 ` [PATCH v2 0/3] sample hooks: become hash agnostic Junio C Hamano
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=20200920185817.GJ67496@camp.crustytoothpaste.net \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 2/4] builtin/rev-parse: learn --null-oid' \ /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
Code repositories for project(s) associated with this 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).