From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org, Jeff King <peff@peff.net>,
Eric Wong <e@80x24.org>
Subject: Re: What's cooking in git.git (Apr 2021, #05; Mon, 19)
Date: Wed, 21 Apr 2021 22:32:57 +0000 [thread overview]
Message-ID: <YICoGeaxHdf6pemo@camp.crustytoothpaste.net> (raw)
In-Reply-To: <87tuo02gdd.fsf@evledraar.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]
On 2021-04-21 at 08:26:06, Ævar Arnfjörð Bjarmason wrote:
> Using something like the:
>
> git --object-format=sha256 <cmd>
>
> Approch I suggsted in
> https://lore.kernel.org/git/8735vq2l8a.fsf@evledraar.gmail.com/ ?
Yes, I generally like that approach and will likely adopt it with some
modifications. For example, I think we'll still need some sanity checks
to be sure that we're not allowing users to specify a totally different
algorithm from what's in the repo when working with the repo because
that will likely break things in a variety of ways.
What I want to do right now is figure out what additional changes are
going to be required and in which programs these changes should be made,
and that requires that I do more work in the series so I can have a
better idea of what's involved. Since that's going to take some time,
I'm going to drop those patches so I can get the rest of the series in
shape.
> In any case having something like the OPT_OBJECT_FORMAT() I added in
> that WIP patch would make sense wouldn't it, to reduce the duplication
> of current "object-format". It would also save each current caller from
> doing the "unknown" and other sanity checks, since they could rely on
> parse_options() having died in that case.
I agree that's a nice improvement and would be happy to see it come in
independent of my changes. I'll probably pick it up sooner or later if
you don't get to it first.
--
brian m. carlson (he/him or they/them)
Houston, Texas, US
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2021-04-21 22:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-19 23:25 What's cooking in git.git (Apr 2021, #05; Mon, 19) Junio C Hamano
2021-04-20 13:23 ` Matheus Tavares Bernardino
2021-04-20 13:52 ` Ævar Arnfjörð Bjarmason
2021-04-20 22:15 ` Junio C Hamano
2021-04-20 23:14 ` brian m. carlson
2021-04-21 8:26 ` Ævar Arnfjörð Bjarmason
2021-04-21 22:32 ` brian m. carlson [this message]
2021-04-20 23:51 ` Junio C Hamano
2021-04-23 14:41 ` Jeff King
2021-04-20 14:28 ` Jeff Hostetler
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YICoGeaxHdf6pemo@camp.crustytoothpaste.net \
--to=sandals@crustytoothpaste.net \
--cc=avarab@gmail.com \
--cc=e@80x24.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.