| |||||||||||||
The git tree is the source codeThe git tree is the source codePosted Nov 11, 2012 18:27 UTC (Sun) by khim (subscriber, #9252)In reply to: The git tree is the source code by epa Parent article: Introducing RedPatch (Ksplice Blog)
The FSF is not relevant here - as the copyright holders of the code they wrote, they could not get in trouble for violating the GPL no matter what they did. FSF set the standard. Others (for example Cygnus) worked in this fashion also. Counsel: And so during your time at Red Hat you normally worked on changes to the software using the git tree? And now for the cross-examination: As I've said: I wish you luckâyou'll need it. I'm not saying it's impossible to prove that git is "the preferred form for making modifications to the program", but it'll be quite hard. You'll need to collect statistic and prove that most developers use replica of the official git tree (I'm not sure if that's even true at all and to use this argument in court you need to prove that it's true without any shadow of doubt), then you'll need to somehow explain why kernel developers themselves don't think git repo is essential, etc. Fell free to do that if you have too many millions of dollars to burn.
(Log in to post comments)
The git tree is the source code Posted Nov 11, 2012 19:03 UTC (Sun) by Jonno (subscriber, #49613) [Link]
> to use this argument in court you need to prove that it's true *without any shadow of doubt*
Actually, that would be a civil case, so you only have to prove it *on the balance of probabilities* (eg. that is more likely than not) but that is still quite a hurdle.
And BTW, even criminal cases only require *beyond reasonable doubt*, not beyond any doubt, as that would generally be impossible...
The git tree is the source code Posted Nov 11, 2012 21:22 UTC (Sun) by epa (subscriber, #39769) [Link]
OK, I wasn't aware that developers working on the Linux kernel preferred to start with the tarball rather than fork from Linus's git tree or the git tree of some other kernel developer. If that is the case, then it's fair to say that they are distributing the code in the same form they received it, which is also the preferred form for making further changes.
The git tree is the source code Posted Nov 12, 2012 15:59 UTC (Mon) by khim (subscriber, #9252) [Link] It may be surprising, but yes, not all developers use Git. That's well-known fact. And the ones who use it not always use replica of the official repo. It's hard to find out solid numbers, of course.
The git tree is the source code Posted Nov 11, 2012 23:06 UTC (Sun) by viro (subscriber, #7872) [Link]
> Counsel: Was your repo a replica of the official tree?
> Witness 1: No.
Perjury is generally frowned upon... I do *not* think that "preferred form" argument would fly, since the general practice is what it is, but your "defence" is a load of horse manure. Anybody who starts a tree by importing a tarball instead of doing git clone is an idiot; "too large and unwieldy" being what, ~500Mb for full history? _And_ that's ~500Mb that only has to be present in a local clone of mainline tree; setting alternates to point to it eliminates that from yours, so unless you seriously propose a workflow that consists of git show or git format-patch on another box + mail or scp to the box where you work on your tree for each backport... *shudder*
In any case, I don't think that "RH kernel team does not consist of hopeless idiots" can be considered confidential information, so... No, rhel6 kernel git tree is *not* set up in such a cretinous way.
The git tree is the source code Posted Nov 12, 2012 12:03 UTC (Mon) by nix (subscriber, #2304) [Link]
Quite. I suppose it might make sense, if you were doing development on a really space-constrained embedded box or something -- but I hope you're never running a compile on that sort of machine, or you'll be waiting for hours and hours.
(Alternates aren't ideal -- one fetch in the wrong place and oops you suddenly have heaps of redundant objects since you need to pull in the other place too and you probably don't have them set as alternates of each other. You need to be quite rigid in your fetching habits if this is really to save you a lot of space. But, heck, I do that sometimes and it just vanishes in the oceans of space on my multiple-year-old obsolete small disks. Even the *Chromium* source tree vanishes in the oceans of space on those disks. Disks you can actually buy nowadays will be even larger. This argument will never fly.)
The git tree is the source code Posted Nov 12, 2012 16:05 UTC (Mon) by khim (subscriber, #9252) [Link] 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?
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.
|
|||||||||||||