-----BEGIN PGP SIGNED MESSAGE-----
Donnie Berkholz wrote:
> Wouldn't it be great if Mike could simple merge his package into the
> tree without losing all that history? This would make git-bisect
> meaningful, instead of bringing in a huge collection of unrelated
> changes in a single commit.
I don't think "huge collection of unrelated changes in a single commit"
fits for either 1 repo/tree or 1 repo/package. In either case I'd
expect a single commit to be a single set of relevant changes, or have I
not understood what you meant? In the 1 repo/tree, I'd only expect to
see commits that spanned package directories if they were in some way
relevant (changing all the license for something like gst-plugins-*)...
It might be worth playing around with --depth?
"Create a shallow clone with a history truncated to the specified number
of revisions. A shallow repository has a number of limitations (you
cannot clone or fetch from it, nor push from nor into it), but is
adequate if you are only interested in the recent history of a large
project with a long history, and would want to send in fixes as patches."
It's not clear whether it can pull/fetch/update from upstream, and it's
not clear how easy it would be to re-integrate. It might also still end
up pulling 100+ Mb for a full portage checkout, so this may not end up
being a feasible solution, but it's worth a look. The other option is
some form of git-split tool used at fork time to strip everything down
to just the required files. We can import from either type of repo
using patchsets if necessary, but I don't see it as being a particularly
My larger concern with 1 repo/package is the more likely situation where
developer Mike is trying to deal with a bug, and eventually spots that
the user is using cat/foo-1.0 from commit a83b28d, only there is no
commit a83b28d in the package repo, because the user's using a fork in
his main tree. It's just cost the developer 20 minutes looking for all
the possible answers, then finally checking git-log and eventually
finding there's no commit, all because it's not easy to determine
whether everybody's working on the same page. That's why there's
overlay names all over the portage output in recent versions if you're
building a non-main-tree package.
If you can solve the management issues, I still like the idea (a 600+ Mb
repo is still horribly huge, and I'd sooner not have to lug that
around), but as I mentioned in my earlier email, there's a lot of
unanswered questions as to how it would work...
> Thanks for the pointer to that thread, I hadn't seen it!
No probs! 5:)
> I don't really think this matters. At some point we'll want to cut off
> CVS access. Whether we have git in place on only a test repo or on the
> gold repo before this cutoff doesn't seem like it would be that
Fair enough, it just sounded like people wanted to get git as the main
repo before CVS was cut off, and if we're gonna do that, someone should
locally test the cvsserver to make sure there's no issues...
> Just curious why you want to post it as a separate repo? If you come up
> with a magic repacking command, just push your new commits and ask Robin
> to run a repack.
I wasn't intending to, it was just if people had specific requests. I'm
also hoping to keep it more up to date (the one on exp/gentoo-x86.git
doesn't seem to have had a history update in a few months).
Unfortunately since I'm using cvsimport rather than cvs2svn, the log
messages produced are likely to be different. Since they're a part of
the commit, it won't be a case of simply commiting my changes, since all
the hashes will be different. However, as I said, it's mostly a little
local experiment, and I'd only post it if there were requests...
> I expect Robin would want to set you up on git.overlays.g.o if you
> really want to post it. He got a little annoyed with me when I put mine
> on dev.g.o.
Yeah, fair enough. I'd clear it with infra before dumping anything that
big anywhere on *.g.o ... 5;)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
-----END PGP SIGNATURE-----