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@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html