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
Message-Id: 498CDDA0.4080602@gentoo.org
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA1
3
4 Hi everybody,
5 So I had an interesting conversation with dleverton and dberkholz on
6 #gentoo-overlays. I was trying to find a solution that would allow
7 people who wanted a complete overlay to be able to work with a full
8 history, but those that just wanted a small checkout to work (and
9 importantly commit from) could do so also. Here are the edited
10 highlights, particularly I hadn't been aware of the graft functionality
11 of git (link for more info in the conversation):
12
13 Feb 06 19:25:43 <dberkholz> we can't use large pack sizes
14 Feb 06 19:25:55 <dberkholz> pack resuming doesn't work
15 Feb 06 19:26:10 <dberkholz> i don't really think minimizing disk
16 space is that useful of a goal, though
17 Feb 06 19:26:16 <dberkholz> if you've got 1G, you've probably got 2G
18 ...
19 Feb 06 22:53:11 <ikelos> dberkholz: You're probably right. It'd
20 only be valuable for the initial pack. Also, it might not be worth
21 having the entire history present. How many people have needed to work
22 with CVS's complete history directly (rather than grabbing the odd file
23 from sources.g.o)? The question is when and how to prune it... 5:\
24 Feb 06 22:55:19 <dleverton> ikelos: dunno about "complete", but I
25 have in the past wanted a "blame" that works across version bumps,
26 sometimes for fairly old stuff.
27 Feb 06 22:55:30 <dberkholz> you can't filter a website like you can
28 with `git log`
29 Feb 06 22:56:23 <ikelos> No, I was just wondering about the
30 majority of devs. I'm not suggesting the full git repo not be
31 available, just that it not be a requirement for committing new stuff to
32 the tree (if/when we switch to a git-based portage)...
33 Feb 06 22:56:30 <dberkholz> i can't think of a time when i have ever
34 gone to sources.g.o in firefox instead of typing cvs log
35 ...
36 Feb 06 23:05:31 <dleverton> Try "graft"
37 Feb 06 23:06:10 <dberkholz> yeah, that'll probably have less false
38 positives..
39 Feb 06 23:06:29 <ikelos> Ah cool, thanks 5:)
40 Feb 06 23:08:52 <ikelos> http://git.or.cz/gitwiki/GraftPoint
41 Feb 06 23:11:25 <ikelos> Seems relatively simple, and might save
42 people from 900Mb downloads...
43 Feb 06 23:12:03 <dberkholz> if you think that people don't care
44 about history
45 Feb 06 23:12:26 <ikelos> Well, it gives people the option to not
46 care about history. If they do, they can download it, graft it, and
47 they're back in business...
48 Feb 06 23:12:26 <dberkholz> with a tree this large, there are so
49 many changesets committed that even if you only want the last 5 commits
50 to each package, it adds up quick
51 Feb 06 23:12:43 <dberkholz> nobody should be grabbing a non-shallow
52 git repo if they don't want history
53 Feb 06 23:12:55 <dberkholz> shallow meaning basically that you can't
54 commit and push
55 Feb 06 23:13:18 <ikelos> Surely some devs will want to accumulate
56 history, but may not need all the past history?
57 Feb 06 23:14:01 <dberkholz> i don't think you're presenting any
58 compelling rationales to make this more complex
59 Feb 06 23:14:38 <ikelos> Well, I was trying to make everybody
60 happy. It was you that suggested one big repo would make it awkward for
61 people to start forking their own and running with it...
62 Feb 06 23:14:59 <ikelos> This would allow people to have a small
63 repo to start doing development from, but also allow those that want the
64 whole thing to have it.
65 Feb 06 23:15:22 <ikelos> It also doesn't seem that complex (and
66 it's probably been relatively well tested if linus wanted it for the
67 kernel history?)
68 Feb 06 23:16:03 <ikelos> Anyway, I'm just investigating options
69 here... 5:)
70 Feb 06 23:16:25 <dberkholz> ok, now i see what problem you're trying
71 to solve
72
73 Just thought it might be worth having the conversation in the archives
74 somewhere...
75 Mike 5:)
76 -----BEGIN PGP SIGNATURE-----
77 Version: GnuPG v2.0.9 (GNU/Linux)
78
79 iEYEARECAAYFAkmM3aAACgkQu7rWomwgFXp29gCfZHW0N1uAZ9kRm9Xkqzp6RwZR
80 l9oAoIH2VRX58X81ALrQoMlVL1nxn5Tb
81 =e1nQ
82 -----END PGP SIGNATURE-----