Re: git: 722b16673c40 - main - acpica: Import ACPICA 20230331

On Wed, Jan 31, 2024 at 7:50 AM Ed Maste <emaste@freebsd.org> wrote:

> On Wed, 31 Jan 2024 at 00:17, Cy Schubert <Cy.Schubert@cschubert.com>
> wrote:
> >
> >  but would the history graph be different? Or does that matter?
>
> It will be different - a merge would be
>
> main   --- A --- B ---- C ---- D
>                 /             /
>               /             /
> vendor --- X ------------ Y
>
> cherry-pick will be:
>
> main   --- A --- B ---- C ---- D'
>                 /
>               /
> vendor --- X ------------ Y
>
> as you mention D and D' have the same contents, but D' has only one
> parent. When searching for unmerged changes commit Y might be
> reported, but that view of the history won't otherwise cause material
> issues.
>
> If there's another update in the future and it's merged we'll be back to:
>
> main   --- A --- B ---- C ---- D' --- E
>                /                     /
>              /                     /
> vendor --- X ------------ Y ---- Z
>
> In this case Y would no longer get reported as needing to be merged.
>

There's an important detail here. If D really is identical to D' except
for the second parent and its delta is the same as from X to Y, then when
it comes time to merge Z to create E, we'll be fine. Git understands how
to cope with cherry-picked changed in this situation because the change
hash (different than the commit hash) will be the same. However, if there
was
any change at all, no matter how trivial or trifling, then it will consider
those changes in need of merging, and conflicts are possible during that
process.It will require that you do additional work to sort them out when
you
sorted out them already in the cherry-pick. If we always merge, the only
conflicts that are possible are actual conflicts. It's why we don't do this
by
cherry-pick generally. While rerere can code adequately, the data for rerere
is on an individual's machine, while the merge info metadata is inside the
pushed repo.

Warner