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
