Re: full kernel history, in patchset format

From: Petr Baudis <pasky@ucw.cz>
Date: Apr 18, 2005, 00:35 UTC
Message-ID: <20050418003526.GD1461@pasky.ji.cz>
In-Reply-To: <1113782805.11910.36.camel@localhost.localdomain>

Dear diary, on Mon, Apr 18, 2005 at 02:06:43AM CEST, I got a letter where David Woodhouse <dwmw2@infradead.org> told me that...

Show 9 quoted lines

> On Mon, 2005-04-18 at 01:39 +0200, Petr Baudis wrote:
> > Of course an entirely different thing are _trees_ associated with those
> > commits. As long as you stay with a simple three-way merge, you
> > basically never want to look at trees which aren't heads and which you
> > don't specifically request to look at. And the trees and what they carry
> > inside is the main bulk of data.
> 
> If the trees are absent and you're trying to merge, what do you gain
> from having the commit objects?

merge-base

> For the special case of removing history before 2.6.12-rc2 from the
> trees, I certainly think we can do it by leaving out all the commits,
> not just the trees. We can do that easily, but there's no way we can
> _add_ that history retrospectively if we omit it in the first place.

I'm confused by this paragraph, but that might be my English skills failing somehow.

Show 7 quoted lines

> For history older than 2.6.12-rc2 I'd suggest that it would be available
> in a different place, and absent from the 'main' working tree that
> everyone uses by default. The only difference we'd see in the working
> tree is that the 2.6.12-rc2 commit -- the oldest commit in that tree --
> would actually have an absentee parent instead of appearing to be an
> import. And all the sha1 hashes of all subsequent commits would be
> different, of course.

Yes, that's what I suggested too.

> To allow pruning of older objects in the general case would be a little
> bit harder than that, because as things stand you'd be re-fetching them
> every time you rsync from elsewhere -- but that wouldn't really be hard
> to fix if we care.

I think http-pull is very promising. :-)

It could be actually much faster than rsync, since you don't need to build directory listings etc, which actually takes non-trivial amount of time already with the kernel git repository.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor