Re: Assessing about commit order in upstream Linux

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

 



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

IMHO the fact that 'A' is the parent of 'C' (IOW 'C' has an appropriate
base version) is mostly important to achieve an effortless merge of 'C'
and later on loses its major significance. So, I would say that
(contents-wise) the diagram can be further reduced to:

    D
    | \
    B  D^2
    |
    A

Just visually, a sane backporting order looks A, B an D^2 (A is assumed
non-merge and D is skipped, since cherry picking merges is not common).

I am quite sure people have thought about backporting techniques and
strategies long before I started to ask these questions. So, I am
still looking forward to seeing various experiences shared.

-- 
Best regards,
Eugeniu Rosca



[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