User: Password:
|
|
Subscribe / Log in / New account

The git tree is the source code

The git tree is the source code

Posted Nov 12, 2012 12:03 UTC (Mon) by nix (subscriber, #2304)
In reply to: The git tree is the source code by viro
Parent article: Introducing RedPatch (Ksplice Blog)

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.)


(Log in to post comments)

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 (guest, #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 (guest, #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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds