From owner-freebsd-git@freebsd.org Mon Jan 4 16:28:19 2021 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 072564DB654 for ; Mon, 4 Jan 2021 16:28:19 +0000 (UTC) (envelope-from uqs@freebsd.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a05:fc87:1:5::15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.spoerlein.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D8gzQ4Yh5z3Fw7; Mon, 4 Jan 2021 16:28:18 +0000 (UTC) (envelope-from uqs@freebsd.org) Received: from localhost (acme.spoerlein.net [IPv6:2a05:fc87:1:5:0:0:0:15]) by acme.spoerlein.net (8.16.1/8.15.2) with ESMTPS id 104GS9qU086270 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 4 Jan 2021 17:28:09 +0100 (CET) (envelope-from uqs@freebsd.org) Date: Mon, 4 Jan 2021 17:28:09 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Mark Millard via freebsd-git Subject: Re: Reporting context with list submittals for defects when local git branches are involved: needs a new description? Message-ID: References: <89B5ACB3-C05C-40EB-AF0B-5E049928DD6D.ref@yahoo.com> <89B5ACB3-C05C-40EB-AF0B-5E049928DD6D@yahoo.com> <29E9AA04-C66B-4298-B84D-6549A88C038B@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <29E9AA04-C66B-4298-B84D-6549A88C038B@yahoo.com> User-Agent: Mutt/2.0.1 (2020-11-14) X-Rspamd-Queue-Id: 4D8gzQ4Yh5z3Fw7 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:39540, ipnet:2a05:fc87::/32, country:CH] X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2021 16:28:19 -0000 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 wrote: > >> On Sun, Jan 3, 2021 at 7:23 PM Mark Millard via freebsd-git >> 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