At Thu, 27 Apr 2006 23:17:24 +0200, Wolfgang Pfeiffer wrote: > > On Thu, Apr 27, 2006 at 06:02:07PM +0200, ruben wrote: > > > > Once you have that, how do you get for example 2.6.16 out of it? > > I assume you can get all previous 2.6 versions this way, right? > > No. I would guess that's not possible. Actually I would rather see > it as a waste of resources, because if someone needs an older 2.6 > version he or she might easily get that by going to > http://www.kernel.org/pub/linux/kernel/v2.6/ > > The git tree, if I understand the HOWTO at > http://linux.yyz.us/git-howto.html correctly, looks more like a > kernel-factory or working-place for those writing the > sources. I.e. the dev branch of the kernel. The fact users can > download these sources might be intended (for testing the files, > etc. ...) but in that environment, provided i got its purpose > correctly, it makes no sense at all to offer old sources ... > > And, if I may digress, the fact I can pull only the latest sources > with git makes it easy to me to update my current local source > directory: I don't have to care for the correct sources version to > download or update, because there is only one ... :) If you prefer > things being simple like I do, an extremely convenient option ... :)
Git is a revision control system and one of the features of such a system is that you can get back to older revisions of the whole system or separate files. So, the old sources sit in there in some form or another like other people already mentioned. In the mean time, I looked at some tutorials for git, and it's not that straightforward it seems. You first need to make a branch which contains all commits up to the tag for the version you want. And then you need to change the active branch to that branch. > > And if you get for example 2.6.15, 2.6.16 and 2.6.17-rc1, will/can > > hardlinks be used between the repositories to save space? > > To link, e.g., 2.6.15 to 2.6.16 looks more like a red alert to me than > a nice place to compile a kernel in .. :) ... ? Or what did I miss? Well, to give the whole explanation. I've used darcs as a revision control system before. Darcs is similar to git, in the sense that after you "get" the code, you have a repository with all the history and everything. With darcs, you can also use tags to indicate the state of the code at some point, like when release 2.6.9 is done, you could add a tag v2.6.9 for example. Now, darcs does not support branches in the same way as git. Instead of doing a branch, you just create a new directory where you create a new repository from a certain tag from the repository you already have. For example, you could create a branch to do some experimental stuff, and later on push the changes back in the main branch. Now, to save space, darcs will hardlink (if possible) files from the new experimental branch to files in the main branch when those files are identical. Darcs stores the state of a repository as a set of patches and when you do a branch, a lot of those patches are common and diskspace can be saved by hardlinking them. So, with darcs, I'd have a 'main' branch to keep up to date with the kernel from Linus, and for example a 2.6.15 and a 1.6.16 branch for kernels that I compiled for my machine and that I'd like to keep around to have a working kernel to fall back on. (or formerly I had a tree which was patched with softmac and one which was patched with dscape) With this approach I could have several trees, while not duplicating (as in space) the whole repository each time. From what I've read, I believe git can also use hardlinks in the same way. -ruben
