Re: Assessing about commit order in upstream Linux

[Eugeniu Rosca <erosca@de.adit-jv.com>]

Hi Junio,

On Tue, May 26, 2020 at 08:21:25AM -0700, Junio C Hamano wrote:
> Eugeniu Rosca <erosca@de.adit-jv.com> writes:
> 
> > So, the two approaches lead to different results. If you see any false
> > assumption or mistaken belief, could you please pinpoint that? TIA.
> 
> Perhaps the assumption/belief that the set of commits in a history
> can be totally ordered is the issue?  When multiple people work
> together on a project, especially in a project where "pull --no-ff"
> is not enforced, there can exist only partial order among them?
> 

IMHO it might be an issue in truly decentralized projects, for which we
can't define an upstream and a downstream. But is it an issue for Linux?

Here is a quick attempt to sketch how commits flow into linux/master,
every development cycle, again and again, respecting the same pattern.

       +-----------------o Linus
       |   +-------------o Maintainers
       |   |           +-o Contributors
       v   v           v

master o
       |   +-------------------+
       |   |                   |
   C(M)o---o Same story as "A" |
       |   |                   |
     B o   +-------------------+
       |
   A(M)o---o A^2 
       |   |   
   A~1 o   o A^2~1
       |   |   
   A~2 o   o A^2~2
           |
           o A^2~3(M)--o A^2~3^2
           |           |
           |           o A^2~3^2~1
           |           |
           |           o A^2~3^2~2
           |
           o A^2~4(M)--o A^2~4^2
           |           |
           o A^2~5     o A^2~4^2~1
                       |
                       o A^2~4^2~2

The order of these commits matter to me because:

 - Commits A^2~4^2~2 through A^2~4^2 likely originate from the same
   series, with a well defined topic/scope and inner sequence. It would
   be ideal to mirror this same order during backporting. Otherwise,
   both the product of porting is questionable and the reviewing
   effort is high.

 - Likewise, commits A^2~3^2~2 through A^2~3^2 probably come from one
   single series. The reviewers would hugely appreciate if these are
   not  scattered during backporting, but are kept together (preferably
   in the exact same succession).

 - Any merge commit (marked with '(M)' above) might carry a conflict
   resolution in itself (aka 'evil merge') which might act as dependency
   to any of its children. So, cherry picking commits in no particular
   order may very likely introduce build and runtime failures, whose
   reasons may be difficult to spot in the downstream projects.

Having said that, I am curious, does anybody resonate with these
statements, based on personal experience (in Linux or other projects)?

-- 
Best regards,
Eugeniu Rosca