| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Donnie Berkholz wrote: |
| 5 |
> Wouldn't it be great if Mike could simple merge his package into the |
| 6 |
> tree without losing all that history? This would make git-bisect |
| 7 |
> meaningful, instead of bringing in a huge collection of unrelated |
| 8 |
> changes in a single commit. |
| 9 |
|
| 10 |
I don't think "huge collection of unrelated changes in a single commit" |
| 11 |
fits for either 1 repo/tree or 1 repo/package. In either case I'd |
| 12 |
expect a single commit to be a single set of relevant changes, or have I |
| 13 |
not understood what you meant? In the 1 repo/tree, I'd only expect to |
| 14 |
see commits that spanned package directories if they were in some way |
| 15 |
relevant (changing all the license for something like gst-plugins-*)... |
| 16 |
|
| 17 |
It might be worth playing around with --depth? |
| 18 |
|
| 19 |
"Create a shallow clone with a history truncated to the specified number |
| 20 |
of revisions. A shallow repository has a number of limitations (you |
| 21 |
cannot clone or fetch from it, nor push from nor into it), but is |
| 22 |
adequate if you are only interested in the recent history of a large |
| 23 |
project with a long history, and would want to send in fixes as patches." |
| 24 |
|
| 25 |
It's not clear whether it can pull/fetch/update from upstream, and it's |
| 26 |
not clear how easy it would be to re-integrate. It might also still end |
| 27 |
up pulling 100+ Mb for a full portage checkout, so this may not end up |
| 28 |
being a feasible solution, but it's worth a look. The other option is |
| 29 |
some form of git-split tool used at fork time to strip everything down |
| 30 |
to just the required files. We can import from either type of repo |
| 31 |
using patchsets if necessary, but I don't see it as being a particularly |
| 32 |
common scenario. |
| 33 |
|
| 34 |
My larger concern with 1 repo/package is the more likely situation where |
| 35 |
developer Mike is trying to deal with a bug, and eventually spots that |
| 36 |
the user is using cat/foo-1.0 from commit a83b28d, only there is no |
| 37 |
commit a83b28d in the package repo, because the user's using a fork in |
| 38 |
his main tree. It's just cost the developer 20 minutes looking for all |
| 39 |
the possible answers, then finally checking git-log and eventually |
| 40 |
finding there's no commit, all because it's not easy to determine |
| 41 |
whether everybody's working on the same page. That's why there's |
| 42 |
overlay names all over the portage output in recent versions if you're |
| 43 |
building a non-main-tree package. |
| 44 |
|
| 45 |
If you can solve the management issues, I still like the idea (a 600+ Mb |
| 46 |
repo is still horribly huge, and I'd sooner not have to lug that |
| 47 |
around), but as I mentioned in my earlier email, there's a lot of |
| 48 |
unanswered questions as to how it would work... |
| 49 |
|
| 50 |
> Thanks for the pointer to that thread, I hadn't seen it! |
| 51 |
|
| 52 |
No probs! 5:) |
| 53 |
|
| 54 |
> I don't really think this matters. At some point we'll want to cut off |
| 55 |
> CVS access. Whether we have git in place on only a test repo or on the |
| 56 |
> gold repo before this cutoff doesn't seem like it would be that |
| 57 |
> relevant. |
| 58 |
|
| 59 |
Fair enough, it just sounded like people wanted to get git as the main |
| 60 |
repo before CVS was cut off, and if we're gonna do that, someone should |
| 61 |
locally test the cvsserver to make sure there's no issues... |
| 62 |
|
| 63 |
> Just curious why you want to post it as a separate repo? If you come up |
| 64 |
> with a magic repacking command, just push your new commits and ask Robin |
| 65 |
> to run a repack. |
| 66 |
|
| 67 |
I wasn't intending to, it was just if people had specific requests. I'm |
| 68 |
also hoping to keep it more up to date (the one on exp/gentoo-x86.git |
| 69 |
doesn't seem to have had a history update in a few months). |
| 70 |
Unfortunately since I'm using cvsimport rather than cvs2svn, the log |
| 71 |
messages produced are likely to be different. Since they're a part of |
| 72 |
the commit, it won't be a case of simply commiting my changes, since all |
| 73 |
the hashes will be different. However, as I said, it's mostly a little |
| 74 |
local experiment, and I'd only post it if there were requests... |
| 75 |
|
| 76 |
> I expect Robin would want to set you up on git.overlays.g.o if you |
| 77 |
> really want to post it. He got a little annoyed with me when I put mine |
| 78 |
> on dev.g.o. |
| 79 |
|
| 80 |
Yeah, fair enough. I'd clear it with infra before dumping anything that |
| 81 |
big anywhere on *.g.o ... 5;) |
| 82 |
|
| 83 |
Mike 5:) |
| 84 |
-----BEGIN PGP SIGNATURE----- |
| 85 |
Version: GnuPG v2.0.9 (GNU/Linux) |
| 86 |
|
| 87 |
iEYEARECAAYFAkl+F4AACgkQu7rWomwgFXotAwCfVMsKjpZABK5w+CcqMbf6o4LX |
| 88 |
Cg0AmwQ8VhrQN3FWOMHXlqegHJ3NTgyX |
| 89 |
=rvhl |
| 90 |
-----END PGP SIGNATURE----- |
Archives