Gentoo Archives: gentoo-scm

From: Maciej Mrozowski <reavertm@××××××.fm>
To: gentoo-scm@l.g.o
Subject: [gentoo-scm] gentoo-x86 on git - Manifests
Date: Mon, 16 Feb 2009 07:06:05
Message-Id: 200902160805.55088.reavertm@poczta.fm
1 Hi
2
3 I've been playing in git controlled overlay (kde-testing) for quite some time,
4 and I found one thing particularly disturbing - merge conflicts related to
5 Manifests.
6 This is especially painful when one wants to do quick cherry-pick from other
7 branch. While ChangeLogs, ebuilds and matadata.xml is usually merged
8 automatically or with just some simple user interaction (like choose
9 remote/local/delete/use modified etc) - Manifests always requires using git
10 mergetool.
11 As I imagine, merging branches and cherry-picking in git controlled workflow
12 is quite popular use case - manually merging (using merge tool - I found
13 default kdiff3 to be the best) Manifest is not especially hard, but always
14 painful as one needs to carefully select Manifest lines that are expected to
15 be correct without requiring to rerun repoman manifest.
16 Why? Because otherwise every cherry-pick would require separate another commit
17 only with purpose to fix Manifests. And the most important is - those
18 conflicts on Manifests requires extra user interaction (takes most of the
19 time).
20 Hence the question - is it possible to *not* store and .gitignore Manifests is
21 git controlled portage repository?
22 As portage metadata is regenerated, maybe it would be as well possible to
23 regenerate manifests on server?
24 I guess it would be possible but ineffective as it would require all needed
25 distfiles to be present as well and this is unacceptable.
26 So maybe it would be just possible to store Manifests but somehow exclude them
27 from merging (make them fully transparent for developer) - so conflicts
28 related to them would be just resolved somehow/ignored (and wouldn't grab
29 attention) - and every developer would be of course obligated to repoman
30 manifest and repoman full before *final* push.
31
32 (Btw, I tend to not use repoman commit - last time I checked it didn't provide
33 full control in regard of what files are being commited and for me it usually
34 ended up ignoring already staged ChangeLogs as they were staged by echangelog
35 before and repoman commited only those unstaged - what is the best practice
36 working with repoman and git now?)
37
38 --
39 regards
40 MM

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-scm] gentoo-x86 on git - Manifests Donnie Berkholz <dberkholz@g.o>
Re: [gentoo-scm] gentoo-x86 on git - Manifests "Tomáš Chvátal" <scarabeus@g.o>