Date: Wed, 15 May 2024 09:01:39 -0600 From: Warner Losh <imp@bsdimp.com> To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= <des@freebsd.org> Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: b5fb1f44ed43 - main - Issue #237 : Resolver uses nameserver commented out in /etc/resolv.conf Message-ID: <CANCZdfq_V9bTS%2BzQ77imspqP5H=%2B7bida_f2M9YGwqQ%2BMM0kAg@mail.gmail.com> In-Reply-To: <865xvfz90f.fsf@ltc.des.dev> References: <202405150953.44F9rvSw043707@gitrepo.freebsd.org> <865xvfz90f.fsf@ltc.des.dev>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000f6d34206187f65b9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 15, 2024 at 4:04=E2=80=AFAM Dag-Erling Sm=C3=B8rgrav <des@freeb= sd.org> wrote: > Dag-Erling Sm=C3=B8rgrav <des@FreeBSD.org> writes: > > The branch main has been updated by des: > > > > URL: > https://cgit.FreeBSD.org/src/commit/?id=3Db5fb1f44ed435fa25fe3de87c9b9ee6= c0aad5125 > > > > commit b5fb1f44ed435fa25fe3de87c9b9ee6c0aad5125 > > Author: Willem Toorop <willem@nlnetlabs.nl> > > AuthorDate: 2024-05-07 12:43:16 +0000 > > Commit: Dag-Erling Sm=C3=B8rgrav <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=3Dcontrib/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 --000000000000f6d34206187f65b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Wed, May 15, 2024 at 4:04=E2=80=AF= AM Dag-Erling Sm=C3=B8rgrav <<a href=3D"mailto:des@freebsd.org">des@free= bsd.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"= margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef= t:1ex">Dag-Erling Sm=C3=B8rgrav <des@FreeBSD.org> writes:<br> > The branch main has been updated by des:<br> ><br> > URL: <a href=3D"https://cgit.FreeBSD.org/src/commit/?id=3Db5fb1f44ed43= 5fa25fe3de87c9b9ee6c0aad5125" rel=3D"noreferrer" target=3D"_blank">https://= cgit.FreeBSD.org/src/commit/?id=3Db5fb1f44ed435fa25fe3de87c9b9ee6c0aad5125<= /a><br> ><br> > commit b5fb1f44ed435fa25fe3de87c9b9ee6c0aad5125<br> > Author:=C2=A0 =C2=A0 =C2=A0Willem Toorop <<a href=3D"mailto:willem@= nlnetlabs.nl" target=3D"_blank">willem@nlnetlabs.nl</a>><br> > AuthorDate: 2024-05-07 12:43:16 +0000<br> > Commit:=C2=A0 =C2=A0 =C2=A0Dag-Erling Sm=C3=B8rgrav <des@FreeBSD.or= g><br> > CommitDate: 2024-05-15 09:52:49 +0000<br> ><br> >=C2=A0 =C2=A0 =C2=A0Issue #237 : Resolver uses nameserver commented out= in /etc/resolv.conf<br> >=C2=A0 =C2=A0 =C2=A0<br> >=C2=A0 =C2=A0 =C2=A0This /etc/resolv.conf:<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# x<br> >=C2=A0 =C2=A0 =C2=A0<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# nameserver 8.8.8.8<br> >=C2=A0 =C2=A0 =C2=A0<br> >=C2=A0 =C2=A0 =C2=A0Still 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.<br> >=C2=A0 =C2=A0 =C2=A0This fix removed all comment handling from `ldns_re= solver_new_frm_fp_l()`. Instead a new function is introduced `ldns_fget_tok= en_l_resolv_conf()` that skips comments that start with '#' and = 9;;'. The old `ldns_fget_token_l()` (that is used for zonefiles too) st= ill accepts only ';' for comments.<br> > ---<br> >=C2=A0 contrib/ldns/parse.c=C2=A0 =C2=A0 | 35 +++++++++++++++++++++++++= ++----<br> >=C2=A0 contrib/ldns/resolver.c | 55 ++++++++++-------------------------= --------------<br> >=C2=A0 2 files changed, 42 insertions(+), 48 deletions(-)<br> <br> I actually did this as a subtree merge:<br> <br> % git subtree merge --prefix=3Dcontrib/ldns vendor/ldns<br> Merge made by the 'ort' strategy.<br> =C2=A0contrib/ldns/parse.c=C2=A0 =C2=A0 | 35 +++++++++++++++++++++++++++---= -<br> =C2=A0contrib/ldns/resolver.c | 55 ++++++++++------------------------------= ---------<br> =C2=A02 files changed, 42 insertions(+), 48 deletions(-)<br> % git show<br> % git commit --amend<br> [main 2dbd65dc861c] ldns: Ignore commented-out lines in resolv.conf.<br> =C2=A0Date: Wed May 15 11:50:11 2024 +0200<br> % git commit --amend=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<br> [main bee1ed74ab26] ldns: Ignore commented-out lines in resolv.conf.<br> =C2=A0Date: Wed May 15 11:50:11 2024 +0200<br> <br> However, I had to rebase before pushing and that appears to have dropped<br= > the merge commit, and I didn't notice until after I'd pushed.<br> <br> % git reflog<br> b5fb1f44ed43 (HEAD -> main, freebsd/main, freebsd/HEAD) HEAD@{0}: pull -= -rebase (finish): returning to refs/heads/main<br> b5fb1f44ed43 (HEAD -> main, freebsd/main, freebsd/HEAD) HEAD@{1}: pull -= -rebase (pick): Issue #237 : Resolver uses nameserver commented out in /etc= /resolv.conf<br> 61dece6d27fb (github/main) HEAD@{2}: pull --rebase (start): checkout 61dece= 6d27fb2436928ca93d65667b358e05aa7b<br> bee1ed74ab26 HEAD@{3}: commit (amend): ldns: Ignore commented-out lines in = resolv.conf.<br> 2dbd65dc861c HEAD@{4}: commit (amend): ldns: Ignore commented-out lines in = resolv.conf.<br> 74ce793d921d HEAD@{5}: merge 0c57cb21e0c6a8a86fa074baeaeb6a002e2b7734: Merg= e made by the 'ort' strategy.<br> 61dece6d27fb (github/main) HEAD@{6}: pull --rebase: Fast-forward<br></block= quote><div><br></div><div>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 k= now, nothing else (I've fixed it, or have a tree with it fixed somewher= e). So missing a merge commit occasionally=C2=A0 generates only a little co= nfusion, but usually isn't a huge deal for the maintainer's next me= rge. 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).</div><div><br></div><div>The vendor branch handbook sec= tion 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=C2=A0that I find to be riskie= r, but would be more efficient for scripting. The tl;dr is:</div><div><br><= /div><div>update vendor branch, etc then git checkout main<br></div><div>gi= t subtree merge</div><div><lose the race></div><div>create branch JUN= K to save your work</div><div>git checkout -B main freebsd/main (abandoning= the merge commit on main)</div><div>git checkout JUNK</div><div>git merge = main (yes, this is a merge commit, but it creates a 'loop' so you c= an't push it, it's a bookmark to save your work)</div><div>git chec= kout main</div><div>git subtree merge (same as above)</div><div>git checkou= t JUNK . (the . is important, since that overwrites the current tree with t= he contents of JUNK, rather than moving to the branch)</div><div>git push (= hope you don't lose the race again, otherwise go back to <lose the r= ace>)</div><div>git branch -D JUNK (you don't need it anymore, it wa= s just to save the merged result).</div><div><br></div><div>Though often if= there's no conflicts that need to be fixed in the subtree merge, the a= bove is overkill. Just do the subtree merge from a clean main. It's fas= ter and simpler.</div><div><br></div><div>But honestly, this should be one = of the things we have a script for since the above is tedious and error-pro= ne.... I often forget something if I'm doing this under the gun.</div><= div><br></div><div>Warner</div></div></div> --000000000000f6d34206187f65b9--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfq_V9bTS%2BzQ77imspqP5H=%2B7bida_f2M9YGwqQ%2BMM0kAg>