Re: On automated commits
Jan Beulich <[email protected]>
| Newsgroups | gmane.comp.gnu.binutils,gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
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