Re: Assessing about commit order in upstream Linux

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 28, 2020 at 08:12:26PM +0200, Eugeniu Rosca wrote:
> 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@xxxxxxxxxxxxxx> 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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux