Re: git: b5fb1f44ed43 - main - Issue #237 : Resolver uses nameserver commented out in /etc/resolv.conf

On Wed, May 15, 2024 at 4:04 AM Dag-Erling Smørgrav <des@freebsd.org> wrote:

> Dag-Erling Smørgrav <des@FreeBSD.org> writes:
> > The branch main has been updated by des:
> >
> > URL:
> https://cgit.FreeBSD.org/src/commit/?id=b5fb1f44ed435fa25fe3de87c9b9ee6c0aad5125
> >
> > commit b5fb1f44ed435fa25fe3de87c9b9ee6c0aad5125
> > Author:     Willem Toorop <willem@nlnetlabs.nl>
> > AuthorDate: 2024-05-07 12:43:16 +0000
> > Commit:     Dag-Erling Smørgrav <des@FreeBSD.org>
> > CommitDate: 2024-05-15 09:52:49 +0000
> >
> >     Issue #237 : Resolver uses nameserver commented out in
> /etc/resolv.conf
> >
> >     This /etc/resolv.conf:
> >         # x
> >
> >         # nameserver 8.8.8.8
> >
> >     Still configured 8.8.8.8 as nameserver, because the comment
> detection in `ldns_resolver_new_frm_fp_l()` didn't anticipate empty lines
> before the comment.
> >     This fix removed all comment handling from
> `ldns_resolver_new_frm_fp_l()`. Instead a new function is introduced
> `ldns_fget_token_l_resolv_conf()` that skips comments that start with '#'
> and ';'. The old `ldns_fget_token_l()` (that is used for zonefiles too)
> still accepts only ';' for comments.
> > ---
> >  contrib/ldns/parse.c    | 35 +++++++++++++++++++++++++++----
> >  contrib/ldns/resolver.c | 55
> ++++++++++---------------------------------------
> >  2 files changed, 42 insertions(+), 48 deletions(-)
>
> I actually did this as a subtree merge:
>
> % git subtree merge --prefix=contrib/ldns vendor/ldns
> Merge made by the 'ort' strategy.
>  contrib/ldns/parse.c    | 35 +++++++++++++++++++++++++++----
>  contrib/ldns/resolver.c | 55
> ++++++++++---------------------------------------
>  2 files changed, 42 insertions(+), 48 deletions(-)
> % git show
> % git commit --amend
> [main 2dbd65dc861c] ldns: Ignore commented-out lines in resolv.conf.
>  Date: Wed May 15 11:50:11 2024 +0200
> % git commit --amend
> [main bee1ed74ab26] ldns: Ignore commented-out lines in resolv.conf.
>  Date: Wed May 15 11:50:11 2024 +0200
>
> However, I had to rebase before pushing and that appears to have dropped
> the merge commit, and I didn't notice until after I'd pushed.
>
> % git reflog
> b5fb1f44ed43 (HEAD -> main, freebsd/main, freebsd/HEAD) HEAD@{0}: pull
> --rebase (finish): returning to refs/heads/main
> b5fb1f44ed43 (HEAD -> main, freebsd/main, freebsd/HEAD) HEAD@{1}: pull
> --rebase (pick): Issue #237 : Resolver uses nameserver commented out in
> /etc/resolv.conf
> 61dece6d27fb (github/main) HEAD@{2}: pull --rebase (start): checkout
> 61dece6d27fb2436928ca93d65667b358e05aa7b
> bee1ed74ab26 HEAD@{3}: commit (amend): ldns: Ignore commented-out lines
> in resolv.conf.
> 2dbd65dc861c HEAD@{4}: commit (amend): ldns: Ignore commented-out lines
> in resolv.conf.
> 74ce793d921d HEAD@{5}: merge 0c57cb21e0c6a8a86fa074baeaeb6a002e2b7734:
> Merge made by the 'ort' strategy.
> 61dece6d27fb (github/main) HEAD@{6}: pull --rebase: Fast-forward
>

The next merge should be fine. git will eliminate the already applied
deltas. It can usually do this even if you just always cherry-pick, but as
the span gets larger and larger, the algorithms inside of git break down.
We've had this issue with ACPICA, but as far as I know, nothing else (I've
fixed it, or have a tree with it fixed somewhere). So missing a merge
commit occasionally  generates only a little confusion, but usually isn't a
huge deal for the maintainer's next merge. There's no way to fix it after
the fact (well, you can do a revert commit and then redo the subtree merge,
but that's a lot of churn for almost no benefit).

The vendor branch handbook section has information on what to do when you
lose the "push race" since rebase with merge commits is 'fragile'. There's
ways one can do it, but they only sometimes work. Or they are dropped
entirely (like you experienced). Ed Maste also has a recipe that I find to
be riskier, but would be more efficient for scripting. The tl;dr is:

update vendor branch, etc then git checkout main
git subtree merge
<lose the race>
create branch JUNK to save your work
git checkout -B main freebsd/main (abandoning the merge commit on main)
git checkout JUNK
git merge main (yes, this is a merge commit, but it creates a 'loop' so you
can't push it, it's a bookmark to save your work)
git checkout main
git subtree merge (same as above)
git checkout JUNK . (the . is important, since that overwrites the current
tree with the contents of JUNK, rather than moving to the branch)
git push (hope you don't lose the race again, otherwise go back to <lose
the race>)
git branch -D JUNK (you don't need it anymore, it was just to save the
merged result).

Though often if there's no conflicts that need to be fixed in the subtree
merge, the above is overkill. Just do the subtree merge from a clean main.
It's faster and simpler.

But honestly, this should be one of the things we have a script for since
the above is tedious and error-prone.... I often forget something if I'm
doing this under the gun.

Warner