mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <>
To: "Ævar Arnfjörð Bjarmason" <>
Cc: Jakub Narebski <>,, Junio C Hamano <>,
	Adam Roben <>,
	Bryan Larsen <>,
	Matthias Urlichs <>,
	Eric Sunshine <>
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: <> (raw)
In-Reply-To: <>

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.


  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:

  List information:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \

* 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

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).