From: Jan Beulich via Gdb <gdb@sourceware.org>
To: Sam James <sam@gentoo.org>
Cc: rostiprodev@gmail.com, binutils@sourceware.org, gdb@sourceware.org
Subject: Re: On automated commits
Date: Tue, 25 Jun 2024 08:15:09 +0200 [thread overview]
Message-ID: <a2ea8387-82d4-4717-966c-04f1dca85f9d@suse.com> (raw)
In-Reply-To: <87sex2orqp.fsf@gentoo.org>
On 25.06.2024 01:17, Sam James wrote:
> This was reported at
> https://sourceware.org/bugzilla/show_bug.cgi?id=31881 and Nick agreed
> it's worth discussing on the ML.
>
> Currently, binutils-gdb.git gets nightly commits to each active release
> branch and master.
>
> This is a bit noisy - especially so for the release branches where
> it makes it hard to see if there's a new commit to backport downstream,
> obfuscates git log, and also as pointed out in the PR, consumes disk
> space forever.
>
> On the PR, mjw suggests using gnulib's git-version-gen - which is a
> solution I like the idea of (I have some draft to implement it for
> Valgrind too) instead of automated commits to bump the version.
I, too, was wondering whether these automatic updates couldn't be done
away with. Just one remark on generating from configure: Please don't
leave out the possibility of people like me not building directly from
the git tree, but from "snapshots" thereof, i.e. a case where the most
recent commit wouldn't be possible to establish from the tree at hand.
Maybe it's enough to cater for this by not doing anything when the
target file already exists (as would also be the case in builds from
e.g. the tarball); making the file in the course of taking the
"snapshot" is of course easily possible.
As to "most recent commit", just to mention it: Commits can linger in
people's trees for a long time, so when eventually pushed at least the
authoring date can be pretty misleading.
Jan
next prev parent reply other threads:[~2024-06-25 6:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-24 23:17 Sam James via Gdb
2024-06-25 6:15 ` Jan Beulich via Gdb [this message]
2024-06-26 17:41 ` Tom Tromey via Gdb
2024-06-26 18:08 ` Fangrui Song
2024-06-26 18:17 ` Joel Brobecker via Gdb
2024-06-27 1:32 ` Alan Modra via Gdb
2024-06-27 2:46 ` H.J. Lu via Gdb
2024-06-27 3:04 ` Jiang, Haochen via Gdb
2024-06-27 3:06 ` Sam James via Gdb
2024-06-27 13:23 ` Paul Koning via Gdb
2024-06-27 13:43 ` Alan Modra via Gdb
2024-06-27 16:06 ` Jens Remus via Gdb
2024-07-02 14:59 ` John Baldwin via Gdb
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a2ea8387-82d4-4717-966c-04f1dca85f9d@suse.com \
--to=gdb@sourceware.org \
--cc=binutils@sourceware.org \
--cc=jbeulich@suse.com \
--cc=rostiprodev@gmail.com \
--cc=sam@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox