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 |