Date: Mon, 4 Jan 2021 17:28:09 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= <uqs@freebsd.org> To: Mark Millard via freebsd-git <freebsd-git@freebsd.org> Subject: Re: Reporting context with list submittals for defects when local git branches are involved: needs a new description? Message-ID: <X/NCGVQvHE7TmBue@acme.spoerlein.net> In-Reply-To: <29E9AA04-C66B-4298-B84D-6549A88C038B@yahoo.com> References: <89B5ACB3-C05C-40EB-AF0B-5E049928DD6D.ref@yahoo.com> <89B5ACB3-C05C-40EB-AF0B-5E049928DD6D@yahoo.com> <CAHgpiFzjKRAkECccUgMWzOoq=syRC9j0hwHR4U6WvJMEf0p%2B_g@mail.gmail.com> <29E9AA04-C66B-4298-B84D-6549A88C038B@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2021-01-04 at 01:41:29 -0800, Mark Millard via freebsd-git wrote:
>
>On 2021-Jan-4, at 00:39, Ryan Libby <rlibby at freebsd.org> wrote:
>
>> On Sun, Jan 3, 2021 at 7:23 PM Mark Millard via freebsd-git
>> <freebsd-git@freebsd.org> wrote:
>>>
>>> I use a main context here to provide an example of the
>>> issue. I'm not claiming main is the only context with
>>> the issue.
>>>
>>> Taking an extremely simple case where I'm targeting the
>>> head of what git fetch freebsd provided, with my local
>>> patches (re)applied via rebase:
>>>
>>> # git reflog
>>> c9819aa7b91c (HEAD -> mm-src) HEAD@{0}: rebase (finish): returning to refs/heads/mm-src
>>> c9819aa7b91c (HEAD -> mm-src) HEAD@{1}: rebase (pick): mm-src snapshot for mm's patched build in git context.
>>> d03fd8ede2c4 (freebsd/main, freebsd/HEAD, main) HEAD@{2}: rebase (start): checkout d03fd8ede2c4
>>> . . .
>>>
>>> One could imagine that I'd picked to work from something
>>> older than d03fd8ede2c4 (say to avoid a known problem).
>>> Either way, uname returns the likes of:
>>>
>>> # uname -apKU
>>> FreeBSD FBSDFHUGE 13.0-CURRENT FreeBSD 13.0-CURRENT mm-src-c255571-gc9819aa7b91c GENERIC-NODBG amd64 amd64 1300133 1300133
>>>
>>> (I've been experimenting with reproducible builds but that
>>> does not change the point: The identification ends up being
>>> specific to my local branch, other than the 1300133's.)
>>>
>>> Thus it appears that the:
>>>
>>> # freebsd-version ; uname -a
>>> 13.0-CURRENT
>>> FreeBSD FBSDFHUGE 13.0-CURRENT FreeBSD 13.0-CURRENT mm-src-c255571-gc9819aa7b91c GENERIC-NODBG amd64
>>>
>>> historically used is not sufficient when local branches are
>>> involved.
>>>
>>> It looks like something like the partial git reflog showing a
>>> relationship to a freebsd/main or freebsd/HEAD commit is
>>> effectively required, or at least some wording like a "based on
>>> freebsd/main d03fd8ede2c4" is required and no tool currently,
>>> directly provides appropriate information: it is a manual
>>> operation.
>>>
>>> Food for thought.
>>>
>>> . . .
>>>
>>> _______________________________________________
>>> freebsd-git@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-git
>>> To unsubscribe, send any mail to "freebsd-git-unsubscribe@freebsd.org"
>>
>> Does this show what you expect?
>> git log --oneline --parents freebsd/main..c9819aa7b91c
>>
>> Or for just the "merge base" commit:
>> git merge-base freebsd/main c9819aa7b91c
>>
>> Yes, we should document something like that for filing bugs.
>>
>
>Avoiding the manual lookup and typing of c9819aa7b91c :
>
># git log --oneline --parents freebsd/main..mm-src
>c9819aa7b91c d03fd8ede2c4 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context.
>
># git merge-base freebsd/main mm-src
>d03fd8ede2c493d0c5a74b625a93a48e018515e1
>
>The first automatically identifies the commit in my mm-src
>branch, even if mm-src later gets a new HEAD. Having such
>recorded in a problem report could be important for the
>originator of the report (but possibly no one else).
>
>Cool. Thanks.
>
>Showing a more complicated example that also involved
>reverting a couple of commits so that the loader would
>display on a amd64 machine (a default text mode context):
>
># git log --oneline --parents freebsd/main..mm-src-2021-01-02.avoid_framebuffer_console_change
>2c557eeab90c ff4c62fe5612 (mm-src-2021-01-02.avoid_framebuffer_console_change) Revert "loader: implement framebuffer console"
>ff4c62fe5612 33700671c435 Revert "loader: fix build on non-x86 platforms"
>33700671c435 486580c44ce2 mm-src snapshot taretting just after conversion to git.
>
># git merge-base freebsd/main mm-src-2021-01-02.avoid_framebuffer_console_change
>486580c44ce29c1e3b1d9b858a08d9df9428b699
>
>Here only the last line of the "git log --oneline --parents" has an
>identification as a freebsd/main commit hash and only the first line
>has the long-branch-name's "at the time" HEAD identifying hash. But
>knowing about the reverts could still be important information.
>
>Adding a named branch that would not get its history rewritten
>to go with the defect report might be important. So in the mm-src
>example context earlier, I might not actually use mm-src directly
>but first create a mm-src.defect-description branch from mm-src
>instead and then report via mm-src.defect-description . (More
>to think about.)
>
>(I've been doing things mostly to experiment.)
I'm a bit confused as to what you are asking here, tbh. Are you working
on a branch of your own? In that case, a bug report needs to have some
concrete pointers to what you've changed locally, or you need to revert
to a clean tree or something.
Or do you just want to have some minor things modified on your tree? In
that case, maybe using git stash and git rebase --autostash would suit
you better?
Stuffing ever more information into the uname output or version string
isn't helpful, because as soon as you're 1 commit away from mainline,
who knows what crazy stuff has happened in your tree?
Cheers
Uli
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?X/NCGVQvHE7TmBue>