From patchwork Mon Jul 19 11:23:40 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Serge Belyshev X-Patchwork-Id: 1506910 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (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) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4GSzy26lxnz9sRf for ; Mon, 19 Jul 2021 21:24:09 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AFB2139450FF for ; Mon, 19 Jul 2021 11:24:06 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from depni-mx.sinp.msu.ru (depni-mx.sinp.msu.ru [213.131.7.21]) by sourceware.org (Postfix) with ESMTP id 6094F3860C3D for ; Mon, 19 Jul 2021 11:23:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6094F3860C3D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=depni.sinp.msu.ru Authentication-Results: sourceware.org; spf=none smtp.mailfrom=depni.sinp.msu.ru Received: from spider (ip-95-220-118-46.bb.netbynet.ru [95.220.118.46]) by depni-mx.sinp.msu.ru (Postfix) with ESMTPSA id C5F101BF507; Mon, 19 Jul 2021 14:23:46 +0300 (MSK) From: Serge Belyshev To: Jakub Jelinek Subject: [PATCH v3] gcc_update: use human readable name for revision string in gcc/REVISION References: <878s271je5.fsf@depni.sinp.msu.ru> <20210716072941.GC2380545@tucnak> <20210716093608.GF2380545@tucnak> <8735se1r4b.fsf_-_@depni.sinp.msu.ru> <20210719110915.GP2380545@tucnak> Date: Mon, 19 Jul 2021 14:23:40 +0300 In-Reply-To: <20210719110915.GP2380545@tucnak> (Jakub Jelinek's message of "Mon, 19 Jul 2021 13:09:15 +0200") Message-ID: <87eebuzgw3.fsf_-_@depni.sinp.msu.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 X-Spam-Status: No, score=-8.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: GCC Patches , Iain Sandoe Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" >> > On 19 Jul 2021, at 11:39, Richard Biener via Gcc-patches wrote: >> > >> > On Fri, Jul 16, 2021 at 12:37 PM Serge Belyshev >> > wrote: >> >> >> >> Based on discussion I've chosen open-coded version without commit hash. >> > >> > As said I'd prefer one with (shortened) hash, Oh, I misunderstood then. >> >> Likewise, I’ve been using a local change to produce “r12-2447-gcca1e30db142” since soon after >> change; I suspect that 12 digits is ‘enough’. It makes it easier for the folks who want to find by >> SHA1 as well as folks who want to find by revision number. > > If the patch is changed from > revision=$r; > to > revision=${r}-g${revision}; > then the exact hash length isn't hardcoded to 12 digits, but whatever git > chooses to make it unique (with the current state of repository). > Of course, changes later on in the repository can introduce collisions and > more hash letters might be needed, but that is a general git problem. And > at least when we have the rXX-YYYY-gZZZZZZZZZ revisions, it is still unique > on the release branches, just one might need to use > $(git gcc-descr `echo $rev | sed 's/-g[0-9a-f]*$//'`) > instead of just > $rev > in case such collision happens if git tells rXX-YYYY-gZZZZZZZZ is ambiguous. > Right, variant with hash has the advantage that it is understood by git out of the box without customisations, so be it then. OK for mainline? --- contrib/Changelog: * gcc_update: derive human readable name for HEAD using git describe like "git gcc-descr" with short commit hash. Drop "revision" from gcc/REVISION. --- contrib/gcc_update | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/contrib/gcc_update b/contrib/gcc_update index 80fac9fc995..ce472545e25 100755 --- a/contrib/gcc_update +++ b/contrib/gcc_update @@ -332,7 +332,22 @@ case $vcs_type in exit 1 fi - revision=`$GCC_GIT log -n1 --pretty=tformat:%p:%t:%H` + # Open-coded version of "git gcc-descr" from contrib/gcc-git-customization.sh + revision=`$GCC_GIT log -n1 --pretty=tformat:%h` + r=`$GCC_GIT describe --all --match 'basepoints/gcc-[0-9]*' HEAD \ + | sed -n 's,^\(tags/\)\?basepoints/gcc-\([0-9]\+\)-\([0-9]\+\)-g[0-9a-f]*$,r\2-\3,p;s,^\(tags/\)\?basepoints/gcc-\([0-9]\+\)$,r\2-0,p'`; + if test -n $r; then + o=`$GCC_GIT config --get gcc-config.upstream`; + rr=`echo $r | sed -n 's,^r\([0-9]\+\)-[0-9]\+\(-g[0-9a-f]\+\)\?$,\1,p'`; + if $GCC_GIT rev-parse --verify --quiet ${o:-origin}/releases/gcc-$rr >/dev/null; then + m=releases/gcc-$rr; + else + m=master; + fi; + if $GCC_GIT merge-base --is-ancestor HEAD ${o:-origin}/$m; then + revision=${r}-g${revision}; + fi + fi branch=`$GCC_GIT name-rev --name-only HEAD || :` ;; @@ -414,6 +429,6 @@ rm -f LAST_UPDATED gcc/REVISION date echo "`TZ=UTC date` (revision $revision)" } > LAST_UPDATED -echo "[$branch revision $revision]" > gcc/REVISION +echo "[$branch $revision]" > gcc/REVISION touch_files_reexec