On Thu, Dec 18, 2025 at 8:22 PM Kevin Hao <[email protected]> wrote:
>
> On Thu, Dec 18, 2025 at 12:42:01PM -0500, Bruce Ashfield via 
> lists.yoctoproject.org wrote:
> > It was a struggle, but it is exactly why I mentioned above that I won't do 
> > the
> > merge using -Xtheirs.
> >
> > The history was riddled with merges, etc, and what we want in a scenario
> > like this is just the new patches, cleanly on top. So after fighting with 
> > git
> > for
> > a while, I did isolate the 480-ish patches and performed a cherry-pick on
> > them to a clean branch on top of the latest rt merged into the existing 
> > ti-soc
> > branch.
> >
> > There were about 10 or 15 empty changes which I skipped, and one
> > conflict. Which was an include in a .dtsi file which I kept.
> >
> > I've pulled that branch into the rt ti-soc branch and pushed it. I could 
> > very
> > easily have missed something, so check that branch and send me patches
> > on top for what I got wrong, or missed.
>
> Thank you for handling this, Bruce.
>
> While `-Xtheirs` may appear inelegant in typical merge scenarios, it should 
> not
> introduce any issues in this specific case. I will provide a more detailed
> explanation below.
>

I'm very aware of the different strategies and how they work, I don't
need an explanation.

> We also have an alternative approach to avoid this type of conflict: instead 
> of
> applying individual patches separately to the BSP standard and RT branches,
> we could merge the BSP standard branch directly into the BSP RT branch. 
> Personally,
> I prefer this method.

Sorry, but no.

Cheers,

Bruce

>
> Let me explain why we encounter these false merge conflicts, which should not 
> exist
> in the first place. Using the `ti-soc` branch as an example: when these BSP 
> branches
> were initially created, the BSP changes (715 patches) were merged separately 
> into
> the BSP standard and RT branches. This was ideal, as each BSP patch was 
> applied to
> both branches with a unique commit ID.
> - On the standard branch:
>   commit 924dc4f8fe11
>   Merge: 1cf1ca9467d8 ac12549ec3d7
>   Author: Bruce Ashfield <[email protected]>
>   Date:   Tue Jun 10 22:13:03 2025 -0400
>
>       Merge branch 'v6.12/standard/ti-sdk-6.12/ti-soc-merge' into 
> v6.12/standard/ti-soc
>
> - On the RT branch:
>   commit a88b69f237ec
>   Merge: 7e0aff00ea56 ac12549ec3d7
>   Author: Bruce Ashfield <[email protected]>
>   Date:   Tue Jun 10 22:15:08 2025 -0400
>
>       Merge branch 'v6.12/standard/ti-sdk-6.12/ti-soc-merge' into 
> v6.12/standard/preempt-rt/ti-soc
>
>
> However, during the development of our BSP, we identified several bugs and 
> submitted
> fixes as individual patches rather than through pull requests. These patches 
> were
> subsequently applied onto the BSP's standard and RT branches, respectively.
> From a git perspective, the same patch applied to both branches appears as 
> entirely
> distinct and unrelated commits. Below are examples of such patches for this 
> BSP:
>
> - On the standard branch:
>   khao@pek-lpggp6:~/linux/lysm/v6.12/ti (lysm/v6.12/ti)$ git log --oneline 
> --no-merges ^924dc4f8fe11 ^d8b5572e17e1 d4e26044d179
>   5c6282874555 media: wave5: Fix device cleanup order to prevent kernel panic
>   d2db27c49077 media: wave5: Fix kthread worker destruction in polling mode
>   33a3fdbd3530 media: wave5: Fix PM runtime usage count underflow
>   8c3e6d7c52ef Revert "PENDING: arm64: dts: ti: k3-am62a7-sk: Add bootph flag 
> for eMMC"
>   d9dee4847e7d am65-cpts: Fix "BUG: assuming non migratable context" in 
> ptp_classify_raw
>   e1e3732057de arch: arm64: dts: ti: k3-j721e-vision-apps.dtso: drop 
> deprecated ti-serdes.h include
>   ae6c7cd674d6 spi: cadence-quadspi: revert to devm_pm_runtime_enable() and 
> remove manual disable
>   1cad3d99af11 arm64: dts: ti: Add DTB overlays for vision apps and edgeai 
> apps
>   bde03505abec arm64: dts: ti: k3-j721e-common-proc-board: Remove duplicate 
> OSPI1 status property
>
> - On the RT branch:
>   khao@pek-lpggp6:~/linux/lysm/v6.12/ti-rt (lysm/v6.12/ti-rt)$ git log 
> --oneline --no-merges ^a88b69f237ec ^8e83a6359c02 c91ff735f371
>   6044d9380d4c media: wave5: Fix device cleanup order to prevent kernel panic
>   50a1a1f060f9 media: wave5: Fix kthread worker destruction in polling mode
>   398a47cccc77 media: wave5: Fix PM runtime usage count underflow
>   4aaaa3778f7b Revert "PENDING: arm64: dts: ti: k3-am62a7-sk: Add bootph flag 
> for eMMC"
>   8aa1c1df1798 am65-cpts: Fix "BUG: assuming non migratable context" in 
> ptp_classify_raw
>   bfc342ce3829 arch: arm64: dts: ti: k3-j721e-vision-apps.dtso: drop 
> deprecated ti-serdes.h include
>   28b4fb87d17b spi: cadence-quadspi: revert to devm_pm_runtime_enable() and 
> remove manual disable
>   fad73e41e9a1 arm64: dts: ti: Add DTB overlays for vision apps and edgeai 
> apps
>   d700524f0914 arm64: dts: ti: k3-j721e-common-proc-board: Remove duplicate 
> OSPI1 status property
>
> Later, when introducing another set of changes to this BSP, we encounter false
> merge conflicts. This occurs because the earlier patches lack unique commit 
> IDs,
> preventing git’s merge strategy from accurately identifying a common base.
> As a result, git incorrectly assumes conflicts during a three-way merge.
> In reality, the files flagged as conflicting are identical across both the
> standard and RT branches. This explains why we can resolve these conflicts
> simply by using the '-Xtheirs'.
>
> Thanks,
> Kevin



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16072): 
https://lists.yoctoproject.org/g/linux-yocto/message/16072
Mute This Topic: https://lists.yoctoproject.org/mt/116824924/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to