| 1 |
Dnia 2014-09-18, o godz. 19:39:08 |
| 2 |
Tobias Klausmann <klausman@g.o> napisał(a): |
| 3 |
|
| 4 |
> Since we're causing at least mild upheaval process-wise, I |
| 5 |
> thought I'd bring up a topic that will be exacerbated by the git |
| 6 |
> migration if it's not really addressed. |
| 7 |
> |
| 8 |
> AIUI, we try to avoid merge conflicts, unless the merge is a |
| 9 |
> meaningful integration of divergent processes. |
| 10 |
> |
| 11 |
> However, one aspect of how ebuilds are written these days will |
| 12 |
> cause a non-trivial amount of merge commits that are not actually |
| 13 |
> useful in that sense. |
| 14 |
> |
| 15 |
> This is due to the way keywording and stabilization work on an |
| 16 |
> ebuild level. Since keywords are all in one line, any merge tool |
| 17 |
> will barf on two keywords being changed in disparate clones. I.e. |
| 18 |
> if I change ~alpha->alpha while someone else changes |
| 19 |
> ~amd64->amd64, we will have a merge conflict. |
| 20 |
|
| 21 |
If someone stabilizes the package you have edited, then most likely you |
| 22 |
actually want to edit your commits and move the changes to a revbump. |
| 23 |
|
| 24 |
If at all, I'd be more worried by a case when queued version bumps |
| 25 |
would lose keywords that were added in the meantime to older versions. |
| 26 |
|
| 27 |
-- |
| 28 |
Best regards, |
| 29 |
Michał Górny |
Archives