Gentoo Archives: gentoo-scm

From: Mike Auty <ikelos@g.o>
To: gentoo-scm@l.g.o
Subject: [gentoo-scm] Grafting and small repos
Date: Sat, 07 Feb 2009 01:02:32
Hash: SHA1

Hi everybody,
	So I had an interesting conversation with dleverton and dberkholz on
#gentoo-overlays.  I was trying to find a solution that would allow
people who wanted a complete overlay to be able to work with a full
history, but those that just wanted a small checkout to work (and
importantly commit from) could do so also.  Here are the edited
highlights, particularly I hadn't been aware of the graft functionality
of git (link for more info in the conversation):

Feb 06 19:25:43 <dberkholz>     we can't use large pack sizes
Feb 06 19:25:55 <dberkholz>     pack resuming doesn't work
Feb 06 19:26:10 <dberkholz>     i don't really think minimizing disk
space is that useful of a goal, though
Feb 06 19:26:16 <dberkholz>     if you've got 1G, you've probably got 2G
Feb 06 22:53:11 <ikelos>        dberkholz: You're probably right.  It'd
only be valuable for the initial pack.  Also, it might not be worth
having the entire history present.  How many people have needed to work
with CVS's complete history directly (rather than grabbing the odd file
from sources.g.o)?  The question is when and how to prune it... 5:\
Feb 06 22:55:19 <dleverton>     ikelos: dunno about "complete", but I
have in the past wanted a "blame" that works across version bumps,
sometimes for fairly old stuff.
Feb 06 22:55:30 <dberkholz>     you can't filter a website like you can
with `git log`
Feb 06 22:56:23 <ikelos>        No, I was just wondering about the
majority of devs.  I'm not suggesting the full git repo not be
available, just that it not be a requirement for committing new stuff to
 the tree (if/when we switch to a git-based portage)...
Feb 06 22:56:30 <dberkholz>     i can't think of a time when i have ever
gone to sources.g.o in firefox instead of typing cvs log
Feb 06 23:05:31 <dleverton>     Try "graft"
Feb 06 23:06:10 <dberkholz>     yeah, that'll probably have less false
Feb 06 23:06:29 <ikelos>        Ah cool, thanks  5:)
Feb 06 23:08:52 <ikelos>
Feb 06 23:11:25 <ikelos>        Seems relatively simple, and might save
people from 900Mb downloads...
Feb 06 23:12:03 <dberkholz>     if you think that people don't care
about history
Feb 06 23:12:26 <ikelos>        Well, it gives people the option to not
care about history.  If they do, they can download it, graft it, and
they're back in business...
Feb 06 23:12:26 <dberkholz>     with a tree this large, there are so
many changesets committed that even if you only want the last 5 commits
to each package, it adds up quick
Feb 06 23:12:43 <dberkholz>     nobody should be grabbing a non-shallow
git repo if they don't want history
Feb 06 23:12:55 <dberkholz>     shallow meaning basically that you can't
commit and push
Feb 06 23:13:18 <ikelos>        Surely some devs will want to accumulate
history, but may not need all the past history?
Feb 06 23:14:01 <dberkholz>     i don't think you're presenting any
compelling rationales to make this more complex
Feb 06 23:14:38 <ikelos>        Well, I was trying to make everybody
happy.  It was you that suggested one big repo would make it awkward for
people to start forking their own and running with it...
Feb 06 23:14:59 <ikelos>        This would allow people to have a small
repo to start doing development from, but also allow those that want the
whole thing to have it.
Feb 06 23:15:22 <ikelos>        It also doesn't seem that complex (and
it's probably been relatively well tested if linus wanted it for the
kernel history?)
Feb 06 23:16:03 <ikelos>        Anyway, I'm just investigating options
here...  5:)
Feb 06 23:16:25 <dberkholz>     ok, now i see what problem you're trying
to solve

	Just thought it might be worth having the conversation in the archives
	Mike  5:)
Version: GnuPG v2.0.9 (GNU/Linux)