From: Jeff King <email@example.com> To: "Ævar Arnfjörð Bjarmason" <firstname.lastname@example.org> Cc: Jakub Narebski <email@example.com>, firstname.lastname@example.org, Junio C Hamano <email@example.com>, Adam Roben <firstname.lastname@example.org>, Bryan Larsen <email@example.com>, Matthias Urlichs <firstname.lastname@example.org>, Eric Sunshine <email@example.com> Subject: Re: [PATCH 2/3] hash-object doc: elaborate on -w and --literally promises Date: Tue, 28 May 2019 02:06:42 -0400 [thread overview] Message-ID: <20190528060641.GC7946@sigill.intra.peff.net> (raw) In-Reply-To: <firstname.lastname@example.org> On Fri, May 24, 2019 at 12:12:10PM +0200, Ævar Arnfjörð Bjarmason wrote: > > I thik that this implemetation detail of `--literally` is here to stay; > > how would you otherwise fix the issue if garbage object makes Git crash? > > > > However, I would prefer to have options state _intent_; if there is > > legitimate need for a tool that creates loose objects, it would be > > better to have separate `--loose` option to `git hash-object` (which > > would imply `-w`, otherwise it doesn't have sense). > > I wonder if we can just remove this option and replace it with a > GIT_TEST_* env variable, or even a test-tool helper. I can't see why > anyone other than our own test suite wants this, and that's why it was > added. So why document it & expose it in a plumbing tool? I can think of a few reasons you might want it in the general toolbox: - you could be recreating a known-buggy history and want to overcome consistency checks (e.g., imagine a tool that imports or modifies git history, and needs to recreate objects literally, warts and all). I think we don't do a lot of quality checks in hash-object now, but we have discussed it (and --literally would be the obvious escape hatch). - folks like security researchers who are poking at Git and want to see how it reacts to various almost-correct inputs. They _could_ use the test-tool helper, but being able to demonstrate bugs with the standard toolbox is helpful for communication. - likewise for general non-security debugging ("it behaves in this funny way if I violate this constraint...") So I actually think it's nice to have it as part of the plumbing, as long as it's buried and documented sufficiently that unsuspecting users do not stumble onto it. And at any rate, now that it has been in the wild for a while, we risk breaking somebody who has come to depend on it. -Peff
next prev parent reply other threads:[~2019-05-28 6:06 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-20 21:53 [PATCH 0/3] hash-object doc: small fixes Ævar Arnfjörð Bjarmason 2019-05-20 21:53 ` [PATCH 1/3] hash-object doc: stop mentioning git-cvsimport Ævar Arnfjörð Bjarmason 2019-05-22 4:57 ` Jeff King 2019-05-20 21:53 ` [PATCH 2/3] hash-object doc: elaborate on -w and --literally promises Ævar Arnfjörð Bjarmason 2019-05-22 5:08 ` Jeff King 2019-05-24 10:04 ` Jakub Narebski 2019-05-24 10:12 ` Ævar Arnfjörð Bjarmason 2019-05-28 6:06 ` Jeff King [this message] 2019-05-28 16:56 ` Junio C Hamano 2019-05-28 16:49 ` Junio C Hamano 2019-05-20 21:53 ` [PATCH 3/3] hash-object doc: point to ls-files and rev-parse Ævar Arnfjörð Bjarmason 2019-05-22 5:15 ` Jeff King
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=20190528060641.GC7946@sigill.intra.peff.net \ --email@example.com \ --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 \ --email@example.com \ --subject='Re: [PATCH 2/3] hash-object doc: elaborate on -w and --literally promises' \ /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).