Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-scm
Navigation:
Lists: gentoo-scm: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-scm@g.o
From: Maciej Mrozowski <reavertm@...>
Subject: gentoo-x86 on git - Manifests
Date: Mon, 16 Feb 2009 08:05:54 +0100
Hi

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.
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.
As I imagine, merging branches and cherry-picking in git controlled workflow 
is quite popular use case - manually merging (using merge tool - I found 
default kdiff3 to be the best) Manifest is not especially hard, but always 
painful as one needs to carefully select Manifest lines that are expected to 
be correct without requiring to rerun repoman manifest.
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).
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.
So maybe it would be just possible to store Manifests but somehow exclude them 
from merging (make them fully transparent for developer) - so conflicts 
related to them would be just resolved somehow/ignored (and wouldn't grab 
attention) - and every developer would be of course obligated to repoman 
manifest and repoman full before *final* push.

(Btw, I tend to not use repoman commit - last time I checked it didn't provide 
full control in regard of what files are being commited and for me it usually 
ended up ignoring already staged ChangeLogs as they were staged by echangelog 
before and repoman commited only those unstaged - what is the best practice 
working with repoman and git now?)

-- 
regards
MM
Attachment:
signature.asc (This is a digitally signed message part.)
Replies:
Re: gentoo-x86 on git - Manifests
-- Tomáš Chvátal
Re: gentoo-x86 on git - Manifests
-- Donnie Berkholz
Navigation:
Lists: gentoo-scm: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Update on -council list
Next by thread:
Re: gentoo-x86 on git - Manifests
Previous by date:
Update on -council list
Next by date:
Re: gentoo-x86 on git - Manifests


Updated Jun 17, 2009

Summary: Archive of the gentoo-scm mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.