From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53259 invoked by alias); 21 Sep 2017 10:58:52 -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 52881 invoked by uid 89); 21 Sep 2017 10:58:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,RDNS_DYNAMIC autolearn=no version=3.3.2 spammy=onetime, one-time, acting, pros X-Spam-User: qpsmtpd, 2 recipients X-HELO: void-ptr.info Received: from pppoe.185.44.68.223.lanport.ru (HELO void-ptr.info) (185.44.68.223) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 21 Sep 2017 10:58:50 +0000 Received: from ptr by void-ptr.info with local (Exim 4.72) (envelope-from ) id 1duzBt-0003hO-0q; Thu, 21 Sep 2017 13:58:45 +0300 Date: Thu, 21 Sep 2017 10:58:00 -0000 From: Petr Ovtchenkov To: Matt Rice Cc: Fiodar Stryzhniou , Andreas Schwab , Binutils , Joel Brobecker , Matthias Klose , GDB Subject: Re: meaning of "Automatic date update in version.in" commits Message-ID: <20170921135845.479dfc76@void-ptr.info> In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00072.txt.bz2 On Thu, 21 Sep 2017 01:42:28 -0700 Matt Rice wrote: > 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.) Date is worst thing that you may use in SONAME. Especially in conjunction with attempts to use DVCS as date source. (D == _Distributed_, so _no time ordering_). And I should repeat: - from datestamps equality not follow ABI compatibility, - from datestamps inequality not follow ABI incompatibility. What you want achieve with SONAME variations? > > 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.