List Archive: gentoo-scm
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On 08:05 Mon 16 Feb , Maciej Mrozowski wrote:
> I've been playing in git controlled overlay (kde-testing) for quite some time,
> and I found one thing particularly disturbing - merge conflicts related to
Good to hear about some real experience using a more interesting
workflow than other overlays, w/ branches etc.
> This is especially painful when one wants to do quick cherry-pick from other
> branch. While ChangeLogs, ebuilds and matadata.xml is usually merged
> automatically or with just some simple user interaction (like choose
> remote/local/delete/use modified etc) - Manifests always requires using git
> Why? Because otherwise every cherry-pick would require separate another commit
> only with purpose to fix Manifests. And the most important is - those
> conflicts on Manifests requires extra user interaction (takes most of the
Hmm. One way to deal with this is keeping Manifests split in a 2nd
commit as they are in CVS. That way you would only cherrypick the
non-Manifest changes, then presumably autogenerate & commit the Manifest
What are some other options? We could have a manifest directory instead,
with 1 file inside per distfile.
> Hence the question - is it possible to *not* store and .gitignore Manifests is
> git controlled portage repository?
> As portage metadata is regenerated, maybe it would be as well possible to
> regenerate manifests on server?
> I guess it would be possible but ineffective as it would require all needed
> distfiles to be present as well and this is unacceptable.
Well, if you did the generation on the master mirror, this would be fine
for the main tree. How about overlays, though?
Developer, Gentoo Linux