git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 2/3] hash-object doc: elaborate on -w and --literally promises

From
Jeff King <peff@peff.net>
Date
May 28, 2019, 06:06 UTC
Message-ID
<20190528060641.GC7946@sigill.intra.peff.net>
In-Reply-To
<87lfywf9fp.fsf@evledraar.gmail.com>
On Fri, May 24, 2019 at 12:12:10PM +0200, Ævar Arnfjörð Bjarmason wrote:
Show 12 quoted lines
> > 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
Previous: Ævar Arnfjörð BjarmasonNext: Junio C Hamano
Message 8 of 12 in “hash-object doc: small fixes”
  1. 0/3 hash-object doc: small fixesÆvar Arnfjörð Bjarmason, May 20, 2019
  2. 1/3 hash-object doc: stop mentioning git-cvsimportÆvar Arnfjörð Bjarmason, May 20, 2019
  3. Jeff KingMay 22, 2019
  4. 2/3 hash-object doc: elaborate on -w and --literally promisesÆvar Arnfjörð Bjarmason, May 20, 2019
  5. Jeff KingMay 22, 2019
  6. Jakub NarebskiMay 24, 2019
  7. Ævar Arnfjörð BjarmasonMay 24, 2019
  8. Jeff KingMay 28, 2019
  9. Junio C HamanoMay 28, 2019
  10. Junio C HamanoMay 28, 2019
  11. 3/3 hash-object doc: point to ls-files and rev-parseÆvar Arnfjörð Bjarmason, May 20, 2019
  12. Jeff KingMay 22, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.