Date: Fri, 24 Apr 2026 13:55:03 +0200 From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@FreeBSD.org> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 5cfcccf76730 - main - Revert "Import tzdata 2026b" Message-ID: <86v7dg4lpk.fsf@ltc.des.dev> In-Reply-To: <aeo-iqnCo8b-VKmn@rincewind.trouble.is> (Philip Paeps's message of "Thu, 23 Apr 2026 23:45:14 %2B0800") References: <69ea3ab7.36284.125e6d40@gitrepo.freebsd.org> <20260423154235.652AB283@slippy.cwsent.com> <aeo-iqnCo8b-VKmn@rincewind.trouble.is>
index | next in thread | previous in thread | raw e-mail
Philip Paeps <philip@freebsd.org> writes: > Because Git ate the merge commit this was meant to be and turned it > into a mess. I did something stupid. I'll commit what I meant to > commit shortly. Just doing another build test to make sure I don't > make a mess twice. :) Most likely, you had to rebase your working copy before pushing, and while rebasing merge commits is supported (with the --rebase-merges / -r option), rebasing _subtree merges_ does not appear to work. When `git rebase` replays the merge, it applies it to the root instead of the subtree, and since the files you are merging don't exist in the root, it goes hunting for similar files elsewhere on the theory that they've been renamed in the tree you are merging into. Unfortunately it finds contrib/tzcode before it finds contrib/tzdata, and proceeds to apply part of the merge in the wrong place. Apparently, with a new enough Git you can use the --strategy / -s option (`-r -s subtree` or `-r -s subtree=contrib/tzdata`) to handle subtree merges correctly when rebasing. I only just found out about it, so I don't know how well it works in practice. DES -- Dag-Erling Smørgrav - des@FreeBSD.orghome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86v7dg4lpk.fsf>