git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Petr Baudis <pasky@ucw.cz>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Linus Torvalds <torvalds@osdl.org>, Ingo Molnar <mingo@elte.hu>,
	git@vger.kernel.org
Subject: Re: full kernel history, in patchset format
Date: Mon, 18 Apr 2005 02:35:26 +0200	[thread overview]
Message-ID: <20050418003526.GD1461@pasky.ji.cz> (raw)
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...
> 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.

> 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

  reply	other threads:[~2005-04-18  0:32 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-16 13:15 full kernel history, in patchset format Ingo Molnar
2005-04-16 13:35 ` Ingo Molnar
2005-04-16 14:55   ` David Mansfield
2005-04-16 19:18     ` Ingo Molnar
2005-04-16 15:08 ` Francois Romieu
2005-04-16 17:04 ` Linus Torvalds
2005-04-16 17:43   ` Petr Baudis
2005-04-16 15:44     ` Christopher Li
2005-04-16 18:31   ` Junio C Hamano
2005-04-16 18:35     ` Mike Taht
2005-04-16 19:19       ` Junio C Hamano
2005-04-16 16:26         ` Christopher Li
2005-04-16 19:44           ` Junio C Hamano
2005-04-16 19:42         ` Mike Taht
2005-04-16 20:19           ` Daniel Barkalow
2005-04-16 18:46     ` Junio C Hamano
2005-04-16 19:13   ` Jan-Benedict Glaw
2005-04-16 19:23   ` Thomas Gleixner
2005-04-16 18:32     ` Petr Baudis
2005-04-16 18:36       ` Petr Baudis
2005-04-16 19:41       ` Thomas Gleixner
2005-04-16 18:44     ` Linus Torvalds
2005-04-16 19:50       ` Thomas Gleixner
2005-04-16 18:57         ` Petr Baudis
2005-04-16 19:27           ` Junio C Hamano
2005-04-16 19:15         ` Linus Torvalds
2005-04-16 20:35           ` Thomas Gleixner
2005-04-16 23:08     ` David Lang
2005-04-16 19:41   ` Ingo Molnar
2005-04-17 23:31   ` David Woodhouse
2005-04-17 23:39     ` Petr Baudis
2005-04-18  0:06       ` David Woodhouse
2005-04-18  0:35         ` Petr Baudis [this message]
2005-04-18  0:45           ` David Woodhouse
2005-04-18  0:50             ` Petr Baudis
2005-04-18  0:51               ` David Woodhouse
2005-04-18  0:59                 ` Petr Baudis
2005-04-18  1:16           ` Linus Torvalds
2005-04-18  1:36             ` David Woodhouse
2005-04-18 10:07 ` Catalin Marinas
2005-04-18 22:41   ` David Mansfield
2005-04-19  8:33     ` Catalin Marinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050418003526.GD1461@pasky.ji.cz \
    --to=pasky@ucw.cz \
    --cc=dwmw2@infradead.org \
    --cc=git@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).