1 |
On 9 May 2016 at 00:09, Anthony G. Basile <blueness@g.o> wrote: |
2 |
> 1. announce to gentoo-dev@ the intention to start a branch intending to |
3 |
> merge |
4 |
> |
5 |
> 2. hack hack hack |
6 |
> |
7 |
> 3. test the merge for any conflicts etc, |
8 |
> |
9 |
> 4. announce to the list a date/time to merge |
10 |
> |
11 |
> 5. if okay, ermge |
12 |
|
13 |
|
14 |
I think that's a bit excessive myself. I dislike merges, but I don't |
15 |
hate them *quite* that much to justify such formality. |
16 |
|
17 |
Because IMO, its not about forbidding merges, its about making sure |
18 |
the use of merges is appropriate and effective. |
19 |
|
20 |
For instance, stabilizing ~100 ebuilds in response to a single stable |
21 |
request, it would make logical sense to group all those stabilizations |
22 |
so that they appear on the left side as a single atomic change, while |
23 |
still existing as a series on the right side of the branch for |
24 |
historical accuracy |
25 |
and for other practical reasons ( like simplified commit reverts ) |
26 |
|
27 |
Pretty much *anything* that does "bulk changes for single purpose" is |
28 |
a good candidate for a merge. |
29 |
|
30 |
For instance, there's ~100 commits sitting around somewhere in a |
31 |
repository for introducing Perl 5.24 to the tree, which requires a |
32 |
commit for each and every entry in virtual/perl-* |
33 |
|
34 |
It would make much sense for this series to be visible on Master as a |
35 |
"add Perl 5.24 to tree" commit, because all the changes are inherently |
36 |
interdependent, |
37 |
and it would make little sense to rewind to a specific point within |
38 |
that series and use it as a portage tree. |
39 |
|
40 |
But that's not significant enough to warrant a lot of formal fluffing around. |
41 |
|
42 |
It for sure would be best if that 100 commit range was rebased before |
43 |
merging, but it should still be a non-fast-forward merge just to keep |
44 |
the history logical. |
45 |
|
46 |
|
47 |
|
48 |
-- |
49 |
Kent |
50 |
|
51 |
KENTNL - https://metacpan.org/author/KENTNL |