Re: git/git-scm.com GH Issue Tracker

From: Jeff King <peff@peff.net>
Date: Feb 6, 2017, 18:49 UTC
Message-ID: <20170206184951.vwq6ib2qzxc542i4@sigill.intra.peff.net>
In-Reply-To: <CACsJy8BCTY=T9f2ac7HUuHA-_RzjaxPHZNPQs9ecBhmsnDuRVQ@mail.gmail.com>

On Mon, Feb 06, 2017 at 05:18:03PM +0700, Duy Nguyen wrote:

Show 10 quoted lines

> On Mon, Feb 6, 2017 at 1:15 PM, Samuel Lijin <sxlijin@gmail.com> wrote:
> > # Irrelevant but someone should take a look
> >
> > 693
> 
> To save people some time (and since i looked at it anyway), this is
> about whether "warning in tree xxx: contains zero-padded file modes:
> from fsck should be a warning or error. It is a warning now even
> though "git -c transfer.fsckobjects=true clone" treats it as an error.
> There are some discussions in the past [1] [2] about this.

The bug that caused the trees is long-fixed. There's a question of how severity levels should be handled in transfer.fsckObjects. By default it treats everything as a reason to reject the object. Dscho added configurable levels a few versions ago. It may be a good idea to tweak the defaults to something more permissive[1].

> There's also a question "And I failed to find in the documentation if
> transfer.fsckobjects could be disabled per repository, can you confirm
> it's not possible for now ?"

I don't know why it wouldn't be, though note that it won't override the operation-specific {receive,fetch}.fsckObjects.

-Peff

[1] If we had a more permissive set of defaults, it would probably make
    sense to turn on fsckObjects by default. Some of the checks are
    security-relevant, like disallowing trees with ".GIT",
    "../../etc/passwd", etc. Those _should_ be handled sanely by the
    rest of Git, but it serves as a belt-and-suspenders check, and also
    protects anybody with a buggy Git downstream from you.

    GitHub has had the feature turned on for ages, with a few caveats:

      - we loosened the zero-padded mode warning, because it was causing
	too many false positives

      - we loosened the timezone checks for the same reason; we've seen
	time zones that aren't exactly 4 characters before

      - we occasionally get complaints from people trying to push old
	histories with bogus committer idents. Usually a missing name or
	similar.

     So those are the ones we'd probably need to loosen off the bat, and
     they're all pretty harmless. But it would be a potential irritating
     regression for somebody if they have a history with other minor
     flaws, and Git suddenly starts refusing to clone it.