| |||||||||||||
The git tree is the source codeThe git tree is the source codePosted Nov 12, 2012 16:05 UTC (Mon) by khim (subscriber, #9252)In reply to: The git tree is the source code by nix Parent article: Introducing RedPatch (Ksplice Blog)
It makes sense when kernel is only part of the package. "~500Mb for full history" may not seem like much, but take 500Mb for kernel, 600Mb for gcc, 100Mb for binutils, etc and you soon arrive at gigabytes. And if you throw aways history of other projects to save space, then why will you want to offer special treatment to kernel?
(Log in to post comments)
The git tree is the source code Posted Nov 12, 2012 17:13 UTC (Mon) by peter.todd (subscriber, #63121) [Link]
Git offers a method to do a git checkout without getting full history known as a shallow clone. It's fast and allows you to later get the rest of history if you need to merge the tree later on. Secondly if you haven't been importing binary files into your repository even years worth of changes tends to compress very effectively to the point where the space taken up by old revisions is a small multiple of the most recent revision.
I find it hard to believe that arguing tarballs are the preferred form of source code for a project otherwise developed with git would pass the balance of probabilities test in a civil case. After all, as mentioned elsewhere the other side just needs to ask your developers what they use to work with the source code. Even if they reply with a different revision control system, that indicates that you should be publishing your changes from it instead.
Having said that, if internally you *actually* don't use *any* revision control system, then yeah, maybe for you the preferred form really is tarballs.
The git tree is the source code Posted Nov 12, 2012 19:34 UTC (Mon) by tzafrir (subscriber, #11501) [Link]
A shallow clone removes all the history from a project. I suspect you'll find it hard to believe that arguing shallow clones are the preferred form of source code for a project otherwise developed with git would pass the balance of probabilities test in a civil case.
The git tree is the source code Posted Nov 12, 2012 21:43 UTC (Mon) by viro (subscriber, #7872) [Link]
FWIW, I don't believe that such a requirement would fly in a court; at least not for quite a few years. Said that, size arguments are BS:
$ du -s . 652664 . $ du -s .git 118828 .git and that - on a tree with alternates pointing to straight mirror of kernel.org linux-2.6.git (which obviously doesn't need to be distributed). Note that unpacked kernel source eats about 4.5 times more than everything in .git. IOW, it's really noise. Granted, that's unpacked (i.e. working tree, not package being distributed), but packed (tar.bz2) will give only ~2 times increase compared to that of source without history - more than 1.2, but not very much more.
_Legally_ git doesn't qualify as "preferred source", but for all practical purposes it is strongly preferred as far as kernel work is concerned. gcc is a different story - they prefer suckversion and _that_ is a space hog, indeed. binutils... IIRC, they also use svn these days.
I don't know how to express that in license without running into insane corners, like "you must never rebase / cherry-pick / fold incremental fixes". On the other hand there's patently obnoxious behaviour several groups used to demonstrate - once a year or so they ran diff between the mainline and whatever had been in their CVS tree and post megabytes of non-differentiated garbage to e.g. l-k, usually reverting a bunch of fixes in process. Hell knows... TBH, I doubt that license is the right tool here...
The git tree is the source code Posted Nov 13, 2012 12:12 UTC (Tue) by jwakely (subscriber, #60262) [Link]
> gcc is a different story - they prefer suckversion
It's true the repo lives in subversion, but some (many?) of us use git-svn to work with it. I certainly don't prefer subversion and can't remember the last time I used subversion to commit anything.
|
|||||||||||||