Re: [gentoo-scm] gentoo-x86 on git - Manifests

[Donnie Berkholz]

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
> Manifests.

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
> mergetool.

> 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
> time).

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 
(repoman cherry-pick?).

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?

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com