From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7584 invoked by alias); 21 Sep 2017 08:42:38 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 7563 invoked by uid 89); 21 Sep 2017 08:42:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=onetime, one-time, acting, pros X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-lf0-f68.google.com Received: from mail-lf0-f68.google.com (HELO mail-lf0-f68.google.com) (209.85.215.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 21 Sep 2017 08:42:31 +0000 Received: by mail-lf0-f68.google.com with SMTP id q132so2615471lfe.4; Thu, 21 Sep 2017 01:42:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NfKVPkB9jCcg7PkGno78ZW3Zds+ne2IeD+4mysRTjCE=; b=NZPqqfFpDRwyEmaddeX8Gm1JHvPo30wfZwQetkZtuCPx6ny1LSo1bJvV3qUkN56360 T57/aIUtPqBInFwkzR+N/tNqY6NP5r/FvW236XKDXFLZUVlcTHc2x7yKS5ST7XKhv/Mn WAen8EuWmpx10Y+T/SbL9iWHQXLgxjikGQjI+bnCKq4kqMLLDuchsizYt1JGaY565Jkz LwjBzd4vlN9iHW9IHqPD23R7cp/Z16LJwXvOYD87REWMcLGBh8oH7cyKFBxWyUAD8rf6 Tt6xUkJ/zCLlMeY2J5GMR4TSt1refVN5bh6phS2mg9c8jSIfdygpILwPrS0+CNbXsj+i VtCQ== X-Gm-Message-State: AHPjjUgZjx/p+JZ3VAKIB9sbH0y/Eg+7Fqc6R4CAhN2uYcdJWRQwQFQQ dORBICmIXc5BtL1gpsXDv4VeaPoXoYw9JrCTXVg= X-Google-Smtp-Source: AOwi7QDpH1aK6ylKTlR6gWdKQ4LWNO5vdPqgf26e6IZfaE84QlZ3iz82GRL8UF5lt1BWjRdiAcZKIBDjDGHDKEi/bEQ= X-Received: by 10.46.88.20 with SMTP id m20mr641034ljb.72.1505983349233; Thu, 21 Sep 2017 01:42:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.235.197 with HTTP; Thu, 21 Sep 2017 01:42:28 -0700 (PDT) In-Reply-To: References: From: Matt Rice Date: Thu, 21 Sep 2017 08:42:00 -0000 Message-ID: Subject: Re: meaning of "Automatic date update in version.in" commits To: Fiodar Stryzhniou Cc: Andreas Schwab , Petr Ovtchenkov , Binutils , Joel Brobecker , Matthias Klose , GDB Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00071.txt.bz2 On Wed, Sep 20, 2017 at 9:58 PM, Fiodar Stryzhniou via gdb wrote: > I propose set date with git hook. With every commit create bfd/version.in before commit and vice versa. Hmm, I don't know much about git hooks per se, but I didn't think e.g. server side hooks could filter on commit? Anyhow, I see 2 options, assuming there are some list of requirements for when git is required: compile time? no configure time? (C.) autoreconf time? n/a checkout time? always (A.) commit time? always (B.) option A. seems to be using git smudge/filter to on checkout populate the version.in using a smudge rule, and then filtering it out using a filter, acting much like the RCS keywords... pros: no extra commit stuff at all cons: requires setting up git config stuff in the repository for executing the smudge/filter rules on checkout this should likely be checked by the configure process e.g. configure should produce an error telling the user to enable the smudge/filter rules when the version is $Date$ rather an actual date... option B. would be somewhat the reverse of this, using a git filter, to modify the commit to insert a date into commits, it would require that committers (rather than people checking out) modify their git config to update version.in on commit. would act somewhat like the project git-crypt https://www.agwa.name/projects/git-crypt/ perhaps this is what Fiodar is referring to above? we would then probably require Brobecke's git hooks, to check that the commit/filter was run before commit Option A. shifts the burden onto users to checkout the repository with the filters enabled Option B. causes some developer discomfort when it comes to merging and branches and what not, and it would probably show up in every patch review. Option C. requiring git at configure time, could be inconvenient for some downstream distros with build machinery that doesn't include git. I personally would not consider it an option... out of these 3, my preference would be A, this is quite counter to the preference I would typically have, e.g. jump through that extra hoop so it doesn't get shifted to the user compiling the software. but I think that the B. hoop is perhaps on fire, and would end up more annoying than the cron commit we have now... So in that regard the choice largely falls to: is the existing cron mechanism annoying enough that we would burden the user with A? I think that since it is a one-time thing when cloning a repository/setting up the repository it is at least worth considering since leaving it as it is does add overhead for e.g. the build bot finding commit broke, and git bisect.