Reporting context with list submittals for defects when local git branches are involved: needs a new description?

[Mark Millard]

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 at 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 at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-git
>> To unsubscribe, send any mail to "freebsd-git-unsubscribe at 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.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)