unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: luangruo@yahoo.com, 74413@debbugs.gnu.org,
	Stefan Kangas <stefankangas@gmail.com>
Subject: bug#74413: [PATCH] Allow to store and read repository information of VCS builds
Date: Mon, 18 Nov 2024 18:54:26 +0200	[thread overview]
Message-ID: <44260.566057504$1731948922@news.gmane.org> (raw)
In-Reply-To: <867c90vbfk.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 18 Nov 2024 16:55:27 +0200")

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Björn Bidar <bjorn.bidar@thaodan.de>
>> Cc: Po Lu <luangruo@yahoo.com>,  74413@debbugs.gnu.org
>> Date: Mon, 18 Nov 2024 16:21:28 +0200
>> 
>> > Doesn't that go against the tendency to have _less_ detailed/private
>> > information in the build?  We've lately removed some relatively useful
>> > infos from what we report in commands that use the build information.
>> 
>> The information added is only the branch and the repository similarly as
>> used by the Android builds. There's no private information there unless
>> the exact change reference Emacs was built on is private.
>
> The branch name could be private.

That could be but at that point you wouldn't have access to the binary
that contains the information and probably wouldn't report bugs to this
tracker either I think.

> Stefan, WDYT about this feature suggestion?
>
>> > More generally, could you present the motivation and the rationale for
>> > making this information available in production builds?
>> 
>> The information wouldn't be only available to production builds but also
>> testing/developer builds that are builtin in a CI environment to
>> e.g. provide test builds for developers to use or to instruct user to
>> use to try to reproduce a bug.
>> 
>> Even for production builds it could be useful for convenience to track
>> down the exact reference/branch a build came from from, that's
>> side effect only thou.
>
> This is already available if Emacs is built in a Git repository, and
> the information is stored in the dumped Emacs.  So what is gained by
> also recording the repository version on a disk file external to
> Emacs?

The information is only stored if the worker already had git installed
and checked out the sources with git inside the worker.
Also the function currently fails unless the system the user uses also happens to
have git installed and the sources if the are installed also contain the
VCS metadata.
Storing the VCS metadata in the sources doesn't happen usually as it
increases the size of a good chunk. In my case e.g. from 188MB to 788MB.
Why not have the same feature for other platforms too?





  reply	other threads:[~2024-11-18 16:54 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87wmh1j6po.fsf@>
2024-11-18 12:45 ` bug#74413: [PATCH] Allow to store and read repository information of VCS builds Eli Zaretskii
2024-11-18 14:21   ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]   ` <875xoklj13.fsf@>
2024-11-18 14:55     ` Eli Zaretskii
2024-11-18 16:54       ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
     [not found]       ` <87frnowkhp.fsf@>
2024-11-18 19:03         ` Eli Zaretskii
2024-11-18 19:31           ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]           ` <874j44wd7k.fsf@>
2024-11-18 19:41             ` Eli Zaretskii
2024-11-18 21:48               ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]               ` <87y11g5i2x.fsf@>
2024-11-19 15:16                 ` Eli Zaretskii
2024-11-19 16:13                   ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-19 17:08                     ` Eli Zaretskii
2024-11-20  7:55                       ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-18 23:48       ` Stefan Kangas
2024-11-19  6:35         ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-19 15:19         ` Eli Zaretskii
2024-11-19 16:16           ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-19 17:20             ` Eli Zaretskii
2024-11-18  8:18 Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='44260.566057504$1731948922@news.gmane.org' \
    --to=bug-gnu-emacs@gnu.org \
    --cc=74413@debbugs.gnu.org \
    --cc=bjorn.bidar@thaodan.de \
    --cc=eliz@gnu.org \
    --cc=luangruo@yahoo.com \
    --cc=stefankangas@gmail.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).