From: "Ævar Arnfjörð Bjarmason" <email@example.com> To: "brian m. carlson" <firstname.lastname@example.org> Cc: Junio C Hamano <email@example.com>, firstname.lastname@example.org, Jeff King <email@example.com>, Eric Wong <firstname.lastname@example.org> Subject: Re: What's cooking in git.git (Apr 2021, #05; Mon, 19) Date: Wed, 21 Apr 2021 10:26:06 +0200 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <YH9gPt410QBRjG59@camp.crustytoothpaste.net> On Wed, Apr 21 2021, brian m. carlson wrote: > On 2021-04-20 at 13:52:33, Ævar Arnfjörð Bjarmason wrote: >> This has a textual conflict (no longer a semantic one) with the above >> ab/unexpected-object-type etc. >> >> As noted in >> https://firstname.lastname@example.org/ I had >> questions about the approach in hash-object.c, in particular I have >> POC/WIP patches that make one of brian's TODO tests pass, by doing the >> "we are in SHA256 mode" earlier, which is also less code as we won't >> need to add special handling to a large part of hash-object.c (or, in >> the future, other such commands). > > I'm going to drop those first two patches for now, since I plan to > implement them in a different way in the future. Using something like the: git --object-format=sha256 <cmd> Approch I suggsted in https://email@example.com/ ? 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.
next prev parent reply other threads:[~2021-04-21 8:26 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-19 23:25 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 [this message] 2021-04-21 22:32 ` brian m. carlson 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: What'\''s cooking in git.git (Apr 2021, #05; Mon, 19)' \ /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
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 NNTP newsgroup(s).