Thread (6 messages) flat view 6 messages, 4 authors, 2017-02-08

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

From: Jeff King <hidden>
Date: 2017-02-06 18:50:19

On Mon, Feb 06, 2017 at 05:18:03PM +0700, Duy Nguyen wrote:
On Mon, Feb 6, 2017 at 1:15 PM, Samuel Lijin [off-list ref] wrote:
quoted
# 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help