invalid git history

[thestinger]

The Git history for this repository is invalid. You'll run into this if you enable verification of the history in your configuration (which should really be the default):

[transfer]
    fsckobjects = true

[fetch]
    fsckobjects = true

[receive]
    fsckobjects = true

% git clone https://github.com/kennethreitz/requests.git
Cloning into 'requests'...
remote: Counting objects: 16580, done.
error: object 5e6ecdad9f69b1ff789a17733b8edc6fd7091bd8: badTimezone: invalid author/committer line - bad time zone
fatal: Error in object

If you look at the commit with verification disabled, you can see the problem:

commit 5e6ecdad9f69b1ff789a17733b8edc6fd7091bd8
Author: Shrikant Sharat Kandula <[email protected]>
Date:   Thu Sep 8 02:38:50 2011 +51800

    Typo in documentation

    The kwarg is named `headers`, not `header`. Also, its a dict, not a set.

I don't have a suggestion on how to approach this. It's quite unfortunate. The history would probably have to be rewritten, and that would be awful. I do think it's worth noting though... verification by default may become the default on various distributions or even upstream.

[untitaker]

verification by default may become the default on various distributions

I'd assume there are many more large/popular repositories that contain at least broken timestamps. IMO it'd be impudent if a distro patches git in a way that would break cloning repos like this. Given requests' history with downstream patches, I guess others would agree.

or even upstream.

Upstream should decide, yes.

---

EDIT: From the larger Python repos, it seems that Werkzeug is also affected by this.

[thestinger]

If verification is off, there aren't even checks to make sure that the hashes are correct. It would make sense if there was a loose mode accepting some invalid history, like invalid timestamps.

[kennethreitz]

Well, one solution is to $ git config fsck.badTimezone ignore

[kennethreitz]

OK, here's my position on this.

• This is nothing for us to be concerned with. The only people effected by this are people who signed up to be effected by this by automatically running git fsck when performing normal Git operations. I can definitely see why this could be considered a good idea, but since almost no one does this, this is not something Requests needs be concerned with.
• I say this mainly because the only solution is to rewrite our Git history. Honestly, I don't think anyone would even notice that we've done so (I've done it a few times in the past), but that's definitely not something I want to do to correct this.
• If a time comes with this behavior becomes default to git, I'd be happy to reconsider.

[kennethreitz]

Also of note is the fact that this commit has existed since 2011 and no one has noticed for 5 years.

[sigmavirus24]

Also of note is that this is a duplicate issue: https://github.com/kennethreitz/requests/issues/2690

[junkblocker]

FYI, this is breaking YouCompleteMe install for those who turned full fsck on.

[sigmavirus24]

@junkblocker I'm sorry about that but we're not going to rewrite history.

[kennethreitz]

@junkblocker perhaps you can do a shallow clone instead?

[junkblocker]

I am not directly cloning YCM, I am doing it via NeoBundle (a vim plugin manager). I think I have shallow clone set up for that but it probably doesn't do shallow checkout of submodules (if there is a way to do that via git).

Additionally, I wonder if there is a way to ignore fsck per repository via global .gitconfig.

[ryneeverett]

I am not directly cloning YCM, I am doing it via NeoBundle (a vim plugin manager). I think I have shallow clone set up for that but it probably doesn't do shallow checkout of submodules (if there is a way to do that via git).

See http://duncansungwkim.blogspot.ca/2014/04/workaround-of-git-shalow-clone-with.html. There is a workaround but it may involve forking your plugin manager. (Ran into the same with vim-plug.)

[sigmavirus24]

Because further conversation on this bug will not be productive and there are 844 people subscribed to notifications for this repository, I'm locking this conversation. If you have problems with other projects, please continue the discussion there.