Re: Assessing about commit order in upstream Linux

From: Michal Suchánek <msuchanek@suse.de>
Date: May 28, 2020, 20:25 UTC
Message-ID: <20200528202538.GK25173@kitsune.suse.cz>
In-Reply-To: <20200528181226.GB9275@lxhi-065.adit-jv.com>

On Thu, May 28, 2020 at 08:12:26PM +0200, Eugeniu Rosca wrote:

Show 43 quoted lines

> Hi Michal,
> 
> On Tue, May 26, 2020 at 07:14:43PM +0200, Michal Suchánek wrote:
> > 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?
> > > 
> > As in if you have history with two branches
> > 
> >    D
> >   / \
> >  B   C
> >   \ /
> >    A
> > 
> > commits B and C are not comparable. They are both between A and D but
> > the order of B and C is arbitrary. Different renderings of the history
> > may choose different order of B and C. This is a simle example. Linux
> > history is a spaghetti of tens of branches.
> 
> While in theory 'B' and 'C' might look equivalent, IMHO in practice
> there is a clear distinction between the two. It's commonly known that
> Git refers to 'B' as the 'first parent' of 'D'. Git also provides means
> to identify such first parents via 'git log --first-parent'.
> 
> A fun fact about first parents is that, unless Linus is on vacation
> and hands over his responsibilities to GKH, you will be quite
> confident that 'git log --first-parent linux/master' will list
> stuff committed by Linus himself. That's why (I bet) in the minds
> of people involved in Linux development, the diagram looks like:
> 
>     D
>     | \
>     B  C
>     | /
>     A

And that's not the case. Commits B and C will typically com from different subsystems, and are truly interchangeable. These subsystems, again, will have number of separate branches that are merged together before they are submitted to Linus. Often a feature requires cross-merge between different subsystems which further complicates the history. Even if B is a commit authored by Linus and you can infer from that it's on the master branch it says nothing about order of B and C. They are still not comparable. And you may still need to reconcile the changes in B and C in D and whatever order you choose for backporting them you will need to reflect D in both B and C in the conflicting case.

HTH

Michal