From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4685 invoked by alias); 19 Sep 2019 19:29:42 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 4677 invoked by uid 89); 19 Sep 2019 19:29:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00,LIKELY_SPAM_BODY,SPF_HELO_PASS autolearn=no version=3.3.1 spammy=Anyone, periods, H*f:CADzB X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Sep 2019 19:29:41 +0000 Received: from mail-oi1-f200.google.com (mail-oi1-f200.google.com [209.85.167.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C4166806CD for ; Thu, 19 Sep 2019 19:29:39 +0000 (UTC) Received: by mail-oi1-f200.google.com with SMTP id c205so2591698oib.10 for ; Thu, 19 Sep 2019 12:29:39 -0700 (PDT) MIME-Version: 1.0 References: <846D2EF4-879F-4518-ABA5-7DD74E6B4F18@linaro.org> <42281a3e-7a7a-d115-2468-b01275d00821@suse.cz> <1e000037-44bd-7d5a-3817-d5048ecc4330@suse.cz> <20190805153430.GT2726@tucnak> <3ea86e3a-4510-6279-64d6-d202fd77bb74@redhat.com> In-Reply-To: From: Jason Merrill Date: Thu, 19 Sep 2019 19:29:00 -0000 Message-ID: Subject: Re: Monotonically increasing counter (was Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git) To: Jakub Jelinek Cc: =?UTF-8?Q?Martin_Li=C5=A1ka?= , Richard Biener , Maxim Kuvyrkov , GCC Patches , Paolo Bonzini Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg01211.txt.bz2 On Wed, Aug 14, 2019 at 2:14 PM Jason Merrill wrote: > On Mon, Aug 5, 2019 at 2:22 PM Jason Merrill wrote: > > On 8/5/19 11:34 AM, Jakub Jelinek wrote: > > > On Mon, Aug 05, 2019 at 11:20:09AM -0400, Jason Merrill wrote: > > >> I agree. But for those who want a monotonically increasing > > >> identifier, there's already one in git: CommitDate. In the discussion > > >> of this issue four years ago, > > > > > > While commit date is monotonically increasing, it has the problem that at > > > certain dates there are very few commits, at others many. When doing > > > bisection by hand, one does the revision computation (min+max)/2 in head > > > (it doesn't have to be precise of course, just roughly, and isn't perfect > > > either, because in svn all of trunk and branches contribute to the revision > > > numbers), with dates it would be division into further uneven chunks. > > > > That's true, but is it a major problem? If you have multiple commits on > > one day, you (can) have multiple binaries with the same date and > > different times, and you can adjust your heuristic for choosing the next > > bisection point accordingly. Over longer periods, the number of commits > > per day averages out. > > > > > Could we tag the branchpoints, say when we branch off gcc 10, we tag the > > > branchpoint as tags/r11 and then we could use r11-123 as 123th commit on the > > > trunk since the branchpoint, and let bugzilla and web redirection handle > > > those rNN-NNNN style identifiers? > > > git describe --all --match 'r[0-9]*' ... | sed ... > > > to map hashes etc. to these rNN-NNNN identifiers and something to map them > > > back to hashes say for git web? > > > > Well, having such tags would allow git describe to produce identifiers > > that you might find more readable. For instance, if I do > > > > git tag -a -m 'GCC 9 branchpoint' b9 $(git merge-base trunk gcc-9-branch) > > Though I guess what you were suggesting is slightly different: this > will put the tag in the history of both trunk and branch, and it would > be better for "r11" to be only in the history of GCC 11. So probably > best to tag the commit that bumps BASE-VER instead, i.e. > > $ git tag -a -m 'GCC 10 stage 1 open' gcc10 > 70f448fa5347ba24e0916201dd8549bc16783ff0 > $ git tag -a -m 'GCC 9 stage 1 open' gcc9 > 949bc65ce4d0d7dd036ccfb279bffe63d02feee6 > $ git tag -a -m 'GCC 8 stage 1 open' gcc8 > 498621e8159c1f494a9b8a5f2c3e5225c74ed242 > ... > $ git describe trunk > gcc10-2527-gac18cc031cd > $ git describe gcc-9-branch > gcc9-7633-g28a024c36af > > Does this sound good to you? Anyone have thoughts about naming for the tags? > > Since alphabetical sorting won't do well with gcc9 and gcc10, you may > want to use the beginning of time tag for naming your binaries. Also > because the stage 1 boundary isn't that interesting for bisection. > > > git tag -a -m'Beginning of Time' r1 3cf0d8938a953ef13e57239613d42686f152b4fe > > git describe --match r1 trunk > > > > r1-170718-gdb868bacf6a > > > > These tags don't need to be shared, this works fine locally. > > > > Note that when you feed such an identifier to other git commands, they > > ignore the first two parts and just use the hash. > > > > This might be a good alternative to dates for you, and people could > > refer to them interchangeably with raw hashes in the web interface. I suppose we also need to decide what form we want to use for the equivalent of gcc.gnu.org/rNNNNN. I figure it needs to be some prefix followed by a "commit-ish" (hash, tag, etc.). Perhaps "g:" as the prefix, so gcc.gnu.org/g:HEAD gcc.gnu.org/g:gcc-9-branch gcc.gnu.org/g:3cf0d8938a953e ? Jason