Re: Tree with leading '0' modes in 1.7.0.3

[Scott Chacon <schacon@gmail.com>]

Hey,

Sorry it's taken me a bit - I'm traveling right now.

On Fri, Mar 26, 2010 at 6:56 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
>> > > Given that GitHub has blessed the world with this corruption,
>> > > we may need to modify JGit to accept it.

Well, shouldn't it accept it just because CGit accepts it?  Isn't that
an incompatibility in implementation?

>> But GitHub's approach here seems to be "Meh, its fine, don't worry
>> about it".

That isn't really my approach, I actually thought I had fixed this a
while ago.  It seems to be a pretty understandable mistake, since
ls-tree and cat-file -p both output zero padded modes and it is only
an issue on trees with subtrees, obviously, so we don't see it all the
time at GitHub.  I have fixed this and it's in the queue for
deployment which should be in the next few days (I gotta get home
first).

> It's up to GitHub to fork Git then, and while at it stop calling it Git
> compatible.  Really.  If we start to get slack about the pack format
> like this then every Git reimplementation du jour will make similar
> deviations except in different directions and we'll end up with a mess
> to support.

Really?  It's not the pack format - we use stock Git servers and
almost always have.  It's the tree writing when someone edits a file
inline - I was writing out zero-padded trees. And, it _is_ Git
compatible - CGit only issues a warning, and that only if the
circumstances align such that we write a tree with a subtree, which
again is pretty rare.  There are only a handful of projects like this
and in all CGit circumstances makes no practical difference.

> My stance has always been that the C Git is authoritative with regards to
> formats and protocols.  It's up to Github to fix their screw-up.

It is fixed and will be deployed soon, but really, there is no reason
to be snippy.  It is a simple and minor mistake effecting very few
repositories (maybe 100 out of 730k), and the only reason it's an
issue at all is that JGit is not following the authoritative CGit
implementation of basically ignoring it.

Also, if we're all concerned about "Git reimplementation du jour"
deviations, then we need to focus on libifying Git so there isn't a
need for such re-implementations.  I'm hoping to help with a possible
GSoC project on libgit2, but the lack of a linkable library will
ensure that re-implementations in nearly every useful language will
continue.

Scott