bug#33328: 27.0.50; Extend Emacs bug report

bug#33328: 27.0.50; Extend Emacs bug report

[Michael Albinus]

[-- Attachment #1: Type: text/plain, Size: 215 bytes --]


Working on Emacs branches, I'd like to see branch information in the bug
report. It could look like in this report, see the "Repository branch"
line. The respective patch is appended.

Is it OK to push to master?


[-- Attachment #2: Type: text/plain, Size: 3091 bytes --]

diff --git a/lisp/loadup.el b/lisp/loadup.el
index 5ecfae170f..0bb6a81adb 100644
--- a/lisp/loadup.el
+++ b/lisp/loadup.el
@@ -368,8 +368,8 @@
 				(string-to-number
 				 (substring name (length base) exelen))))
 			     files)))
-      (setq emacs-repository-version (condition-case nil (emacs-repository-get-version)
-                              (error nil)))
+      (setq emacs-repository-version (emacs-repository-get-version)
+            emacs-repository-branch (emacs-repository-get-branch))
       ;; A constant, so we shouldn't change it with `setq'.
       (defconst emacs-build-number
 	(if versions (1+ (apply 'max versions)) 1))))
diff --git a/lisp/mail/emacsbug.el b/lisp/mail/emacsbug.el
index 8cacad8726..e55f950aac 100644
--- a/lisp/mail/emacsbug.el
+++ b/lisp/mail/emacsbug.el
@@ -307,6 +307,8 @@ report-emacs-bug
 
     (if (stringp emacs-repository-version)
 	(insert "Repository revision: " emacs-repository-version "\n"))
+    (if (stringp emacs-repository-branch)
+	(insert "Repository branch: " emacs-repository-branch "\n"))
     (if (fboundp 'x-server-vendor)
 	(condition-case nil
             ;; This is used not only for X11 but also W32 and others.
diff --git a/lisp/version.el b/lisp/version.el
index 8491930819..4e7f0c1c33 100644
--- a/lisp/version.el
+++ b/lisp/version.el
@@ -133,7 +133,35 @@ emacs-repository-get-version
 
 Optional argument DIR is a directory to use instead of `source-directory'.
 Optional argument EXTERNAL is ignored."
-  (emacs-repository-version-git (or dir source-directory)))
+  (ignore-errors (emacs-repository-version-git (or dir source-directory))))
+
+(defvar emacs-repository-branch nil
+  "String giving the repository branch from which this Emacs was built.
+Value is nil if Emacs was not built from a repository checkout,
+or if we could not determine the branch.")
+
+(defun emacs-repository-branch-git (dir)
+  "Ask git itself for the branch information for directory DIR."
+  (message "Waiting for git...")
+  (with-temp-buffer
+    (let ((default-directory (file-name-as-directory dir)))
+      (and (zerop
+	    (with-demoted-errors "Error running git rev-parse --abbrev-ref: %S"
+	      (call-process "git" nil '(t nil) nil
+                            "rev-parse" "--abbrev-ref" "HEAD")))
+           (goto-char (point-min))
+           (buffer-substring (point) (line-end-position))))))
+
+(defun emacs-repository-get-branch (&optional dir)
+  "Try to return as a string the repository branch of the Emacs sources.
+The format of the returned string is dependent on the VCS in use.
+Value is nil if the sources do not seem to be under version
+control, or if we could not determine the branch.  Note that
+this reports on the current state of the sources, which may not
+correspond to the running Emacs.
+
+Optional argument DIR is a directory to use instead of `source-directory'."
+  (ignore-errors (emacs-repository-branch-git (or dir source-directory))))
 
 ;; We put version info into the executable in the form that `ident' uses.
 (purecopy (concat "\n$Id: " (subst-char-in-string ?\n ?\s (emacs-version))

[-- Attachment #3: Type: text/plain, Size: 6720 bytes --]



In GNU Emacs 27.0.50 (build 10, x86_64-pc-linux-gnu, GTK+ Version 3.24.1)
 of 2018-11-09 built on detlef
Repository revision: 4f0e54223a60a34818365475440e023747eab7e9
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12001000
System Description: Ubuntu 18.10

Recent messages:
Opening connection to imap.gmx.net via tls...
Opening connection to imap.gmx.net...done
Opening connection to outlook.office365.com via tls...
Opening connection to outlook.office365.com...done
Reading active file via nnml...
Reading incoming mail from pop...
nnml: Reading incoming mail (no new mail)...done
Reading active file via nnml...done
Reading active file via nndraft...done
Checking new news...done

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB
NOTIFY INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF
XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS LCMS2 GMP

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8

Major mode: Group

Minor modes in effect:
  gnus-undo-mode: t
  erc-notify-mode: t
  erc-notifications-mode: t
  display-time-mode: t
  shell-dirtrack-mode: t
  delete-selection-mode: t
  icomplete-mode: t
  show-paren-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
/home/albinus/src/elpa/packages/debbugs/debbugs-org hides /home/albinus/.emacs.d/elpa/debbugs-0.16/debbugs-org
/home/albinus/src/elpa/packages/debbugs/debbugs-gnu hides /home/albinus/.emacs.d/elpa/debbugs-0.16/debbugs-gnu
/home/albinus/src/elpa/packages/debbugs/debbugs hides /home/albinus/.emacs.d/elpa/debbugs-0.16/debbugs
/home/albinus/src/elpa/packages/debbugs/debbugs-autoloads hides /home/albinus/.emacs.d/elpa/debbugs-0.16/debbugs-autoloads
/home/albinus/src/elpa/packages/debbugs/debbugs-pkg hides /home/albinus/.emacs.d/elpa/debbugs-0.16/debbugs-pkg
/home/albinus/src/elpa/packages/debbugs/debbugs-browse hides /home/albinus/.emacs.d/elpa/debbugs-0.16/debbugs-browse
~/lisp/telepathy hides /home/albinus/.emacs.d/elpa/telepathy-20131209.1258/telepathy
/home/albinus/src/elpa/packages/tramp-theme/tramp-theme hides /home/albinus/.emacs.d/elpa/tramp-theme-0.2/tramp-theme
/home/albinus/src/elpa/packages/tramp-theme/tramp-theme-autoloads hides /home/albinus/.emacs.d/elpa/tramp-theme-0.2/tramp-theme-autoloads
/home/albinus/src/elpa/packages/tramp-theme/tramp-theme-pkg hides /home/albinus/.emacs.d/elpa/tramp-theme-0.2/tramp-theme-pkg
/home/albinus/src/tramp/lisp/tramp-smb hides /usr/local/src/emacs/lisp/net/tramp-smb
/home/albinus/src/tramp/lisp/tramp-uu hides /usr/local/src/emacs/lisp/net/tramp-uu
/home/albinus/src/tramp/lisp/tramp-adb hides /usr/local/src/emacs/lisp/net/tramp-adb
/home/albinus/src/tramp/lisp/tramp-archive hides /usr/local/src/emacs/lisp/net/tramp-archive
/home/albinus/src/tramp/lisp/tramp-cmds hides /usr/local/src/emacs/lisp/net/tramp-cmds
/home/albinus/src/tramp/lisp/tramp-cache hides /usr/local/src/emacs/lisp/net/tramp-cache
/home/albinus/src/tramp/lisp/trampver hides /usr/local/src/emacs/lisp/net/trampver
/home/albinus/src/tramp/lisp/tramp-ftp hides /usr/local/src/emacs/lisp/net/tramp-ftp
/home/albinus/src/tramp/lisp/tramp-sh hides /usr/local/src/emacs/lisp/net/tramp-sh
/home/albinus/src/tramp/lisp/tramp hides /usr/local/src/emacs/lisp/net/tramp
/home/albinus/src/tramp/lisp/tramp-loaddefs hides /usr/local/src/emacs/lisp/net/tramp-loaddefs
~/lisp/dbus hides /usr/local/src/emacs/lisp/net/dbus
/home/albinus/src/tramp/lisp/tramp-gvfs hides /usr/local/src/emacs/lisp/net/tramp-gvfs
/home/albinus/src/tramp/lisp/tramp-compat hides /usr/local/src/emacs/lisp/net/tramp-compat

Features:
(gnus-cite nnir pop3 utf-7 nndraft nnmh nnml gnutls network-stream nsm
gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg gnus-art
mm-uu mml2015 mm-view mml-smime smime dig mailcap gnus-cache gnus-sum
nnnil smtpmail gnus-demon nntp gnus-group gnus-undo gnus-start
gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int
gnus-range gnus-win gnus nnheader wid-edit shadow sort mail-extr
warnings emacsbug message rmc puny rfc822 mml mml-sec epa gnus-util
rmail rmail-loaddefs time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils elec-pair erc-notify
erc-networks erc-desktop-notifications erc-match notifications dbus xml
erc-goodies erc erc-backend erc-compat thingatpt pp erc-loaddefs
cperl-mode time tramp-sh kubernetes-tramp lxc-tramp docker-tramp
tramp-cache vagrant-tramp dash term disp-table ehelp tramp trampver
tramp-compat tramp-loaddefs ucs-normalize shell pcomplete comint
ansi-color ring parse-time format-spec advice delsel ido jka-compr
icomplete paren vc vc-dispatcher dired dired-loaddefs mule-util edmacro
kmacro rx slime-autoloads info finder-inf package let-alist derived
pcase cl-extra help-mode easymenu url-handlers url-parse auth-source
cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json map
url-vars seq byte-opt gv bytecomp byte-compile cconv epg epg-config
subr-x cl-loaddefs cl-lib tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core term/tty-colors frame cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 438192 18735)
 (symbols 48 37449 10)
 (strings 32 81835 4686)
 (string-bytes 1 2609780)
 (vectors 16 53284)
 (vector-slots 8 941041 34458)
 (floats 8 238 299)
 (intervals 56 390 0)
 (buffers 992 26))

bug#33328: 27.0.50; Extend Emacs bug report

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Fri, 09 Nov 2018 23:19:30 +0100
> 
> Working on Emacs branches, I'd like to see branch information in the bug
> report. It could look like in this report, see the "Repository branch"
> line. The respective patch is appended.
> 
> Is it OK to push to master?

You pushed ignoring-errors to the functions that return the revision
and the branch, and I wonder whether that is a good idea.  Those
functions are useful on their own right, and their doc strings say
nothing about the situation where something goes wrong with the Git
invocation or any other calamities.

Thanks.

bug#33328: 27.0.50; Extend Emacs bug report

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> You pushed ignoring-errors to the functions that return the revision
> and the branch, and I wonder whether that is a good idea.  Those
> functions are useful on their own right, and their doc strings say
> nothing about the situation where something goes wrong with the Git
> invocation or any other calamities.

I will move this back to loadup.el, where it has been originally. Plus
documenting the new variable emacs-repository-branch in etc/NEWS and the
Elisp manual, node "(elisp) Version Info". (emacs-repository-version
needs also an entry in the Elisp manual, will do this).

OK to push then?

> Thanks.

Best regards, Michael.

bug#33328: 27.0.50; Extend Emacs bug report

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: 33328@debbugs.gnu.org
> Date: Sat, 10 Nov 2018 09:57:30 +0100
> 
> I will move this back to loadup.el, where it has been originally. Plus
> documenting the new variable emacs-repository-branch in etc/NEWS and the
> Elisp manual, node "(elisp) Version Info". (emacs-repository-version
> needs also an entry in the Elisp manual, will do this).
> 
> OK to push then?

Fine with me, thanks.

bug#33328: 27.0.50; Extend Emacs bug report

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> I will move this back to loadup.el, where it has been originally. Plus
>> documenting the new variable emacs-repository-branch in etc/NEWS and the
>> Elisp manual, node "(elisp) Version Info". (emacs-repository-version
>> needs also an entry in the Elisp manual, will do this).
>> 
>> OK to push then?
>
> Fine with me, thanks.

Done, I'm closing the bug.

Best regards, Michael.

bug#33328: 27.0.50; Extend Emacs bug report

[Glenn Morris]

Michael Albinus wrote:

> Working on Emacs branches, I'd like to see branch information in the bug
> report.

Sorry for the slow reply, but given the hash from emacs-repository-version,
doesn't a command like "git name-rev HASH" give you this information,
without you needing to store extra information in the Emacs binary?

bug#33328: 27.0.50; Extend Emacs bug report

[Michael Albinus]

Glenn Morris <rgm@gnu.org> writes:

>> Working on Emacs branches, I'd like to see branch information in the bug
>> report.
>
> Sorry for the slow reply, but given the hash from emacs-repository-version,
> doesn't a command like "git name-rev HASH" give you this information,
> without you needing to store extra information in the Emacs binary?

Anything goes of course, but is it really a problem? A short string
shouldn't hurt.

I use this kind of information also in Tramp (see variable
tramp-repository-branch), and it would be an additional burden always to
use call-process for just opening a new debug buffer.

Best regards, Michael.

bug#33328: 27.0.50; Extend Emacs bug report

[Glenn Morris]

Michael Albinus wrote:

>> Sorry for the slow reply, but given the hash from emacs-repository-version,
>> doesn't a command like "git name-rev HASH" give you this information,
>> without you needing to store extra information in the Emacs binary?
>
> Anything goes of course, but is it really a problem? A short string
> shouldn't hurt.

The code to implement this doesn't seem that small, and seems redundant
to me.

http://lists.gnu.org/r/emacs-diffs/2018-11/msg00072.html

> I use this kind of information also in Tramp (see variable
> tramp-repository-branch), and it would be an additional burden always to
> use call-process for just opening a new debug buffer.

I meant, when you get a bug report, if you care which branch it came
from, and it isn't obvious from the version number, just use
git name-rev to find out. You will presumably be looking at the git log
anyway for debugging.

bug#33328: 27.0.50; Extend Emacs bug report

[Michael Albinus]

Glenn Morris <rgm@gnu.org> writes:

Hi Glenn,

>> I use this kind of information also in Tramp (see variable
>> tramp-repository-branch), and it would be an additional burden always to
>> use call-process for just opening a new debug buffer.
>
> I meant, when you get a bug report, if you care which branch it came
> from, and it isn't obvious from the version number, just use
> git name-rev to find out. You will presumably be looking at the git log
> anyway for debugging.

A version number is not sufficient. It depends, which branch is checked
out. See for example

--8<---------------cut here---------------start------------->8---
# ( cd ~/src/emacs ; git name-rev d2a07b9a82a632e8baa179c667a98d275e5f6973 )
d2a07b9a82a632e8baa179c667a98d275e5f6973 remotes/origin/scratch/accurate-warning-pos~44

# ( cd ~/src/emacs-test ; git name-rev d2a07b9a82a632e8baa179c667a98d275e5f6973 )
d2a07b9a82a632e8baa179c667a98d275e5f6973 remotes/origin/HEAD~89
--8<---------------cut here---------------end--------------->8---

The former is a master checkout, the latter is a
feature/tramp-thread-safe checkout. Just the revision
d2a07b9a82a632e8baa179c667a98d275e5f6973 doesn't tell me the branch the
original bug report has been written for.

Best regards, Michael.

bug#33328: 27.0.50; Extend Emacs bug report

[Glenn Morris]

Thanks for the example, name-rev clearly isn't doing what I thought. I
would still think the branch information would be derivable from the
hash, eg https://github.com/mhagger/git-when-merged , but clearly it's
not so simple.

bug#33328: 27.0.50; Extend Emacs bug report

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Thu, 22 Nov 2018 13:52:58 -0500
> Cc: 33328@debbugs.gnu.org
> 
> Thanks for the example, name-rev clearly isn't doing what I thought. I
> would still think the branch information would be derivable from the
> hash, eg https://github.com/mhagger/git-when-merged , but clearly it's
> not so simple.

Branches mean nothing to Git.

bug#33328: 27.0.50; Extend Emacs bug report

[Achim Gratz]

Michael Albinus writes:
> A version number is not sufficient. It depends, which branch is checked
> out. See for example

It is quite useless to ask which branch a given commit is on, since it
could be on any number of branches, only some of which might be shared
between your repo and the repo of the reporter.

> # ( cd ~/src/emacs ; git name-rev d2a07b9a82a632e8baa179c667a98d275e5f6973 )
> d2a07b9a82a632e8baa179c667a98d275e5f6973 remotes/origin/scratch/accurate-warning-pos~44

~/lisp/emacs-master> git branch --contains d2a07b9
* blafasel
  master

I've just created and checked out a new branch blafasel, then asked git
to name the (local) branches that have this commit.  I generally don't
pull feature branches and similar namespaces, but almost always work on
local branches.

> # ( cd ~/src/emacs-test ; git name-rev d2a07b9a82a632e8baa179c667a98d275e5f6973 )
> d2a07b9a82a632e8baa179c667a98d275e5f6973 remotes/origin/HEAD~89
>
> The former is a master checkout, the latter is a
> feature/tramp-thread-safe checkout. Just the revision
> d2a07b9a82a632e8baa179c667a98d275e5f6973 doesn't tell me the branch the
> original bug report has been written for.

So, what information would you gain if you learned it was branch
"blafasel"?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

bug#33328: 27.0.50; Extend Emacs bug report

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Thu, 22 Nov 2018 20:14:56 +0100
> 
> Michael Albinus writes:
> > A version number is not sufficient. It depends, which branch is checked
> > out. See for example
> 
> It is quite useless to ask which branch a given commit is on, since it
> could be on any number of branches, only some of which might be shared
> between your repo and the repo of the reporter.

In general, yes.  But not in Emacs development, not with public
development branches anyway.

bug#33328: 27.0.50; Extend Emacs bug report

[Eli Zaretskii]

> Date: Thu, 22 Nov 2018 21:22:52 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 33328@debbugs.gnu.org
> 
> > From: Achim Gratz <Stromeko@nexgo.de>
> > Date: Thu, 22 Nov 2018 20:14:56 +0100
> > 
> > Michael Albinus writes:
> > > A version number is not sufficient. It depends, which branch is checked
> > > out. See for example
> > 
> > It is quite useless to ask which branch a given commit is on, since it
> > could be on any number of branches, only some of which might be shared
> > between your repo and the repo of the reporter.
> 
> In general, yes.  But not in Emacs development, not with public
> development branches anyway.

And, btw, if you read carefully what Michael wrote above, you will see
that he is not asking what branch a given commit is on, he is asking a
different question.

bug#33328: 27.0.50; Extend Emacs bug report

[Achim Gratz]

Eli Zaretskii writes:
>> It is quite useless to ask which branch a given commit is on, since it
>> could be on any number of branches, only some of which might be shared
>> between your repo and the repo of the reporter.
>
> In general, yes.  But not in Emacs development, not with public
> development branches anyway.

You'd have to make a stipulation that the bug report must be made from
"public" branches only.  I don't think that'll work.  It's possible to
ask for the upstream branch that commit was in, which works until there
are intermediate clones used (i.e. the parent repo must be the public
one for it to work):

~/lisp/emacs-master> git branch -r --contains d2a07b9
  origin/feature/tramp-thread-safe
  origin/master
  origin/scratch/accurate-warning-pos

So as long as you keep your own repo just one level away from the public
one, the commit is all you need to determine which branches it was
possibly on, but you still can't tell which exact branch was actually
checked out (if any tracking branches even existed at the local repo)
for any particular bug report.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

bug#33328: 27.0.50; Extend Emacs bug report

[Achim Gratz]

Eli Zaretskii writes:
> And, btw, if you read carefully what Michael wrote above, you will see
> that he is not asking what branch a given commit is on, he is asking a
> different question.

Quote:
+(defvar emacs-repository-branch nil
+  "String giving the repository branch from which this Emacs was built.
+Value is nil if Emacs was not built from a repository checkout,
+or if we could not determine the branch.")

So he's clearly asking for the branch name that this Emacs was built
from, which (again) would always be a local branch (even if it had no
changes at all) if I had built that Emacs.  It's an ill-posed question
that doesn't have an answer or at least not one that has the usefulness
that Michael wants.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

bug#33328: 27.0.50; Extend Emacs bug report

[Michael Albinus]

Achim Gratz <Stromeko@nexgo.de> writes:

Hi Achim,

> So he's clearly asking for the branch name that this Emacs was built
> from, which (again) would always be a local branch (even if it had no
> changes at all) if I had built that Emacs.  It's an ill-posed question
> that doesn't have an answer or at least not one that has the usefulness
> that Michael wants.

There is a useful answer. If it tells me a branch name which is not
public, I know that I even cannot trust "emacs -Q" behavior. I will
continue with more inquisitorial questions :-)

Fortunately, most of the time this is not necessary 'cos people use
publich branches.

> Regards,
> Achim.

Best regards, Michael.

bug#33328: 27.0.50; Extend Emacs bug report

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Thu, 22 Nov 2018 20:36:57 +0100
> 
> It's an ill-posed question that doesn't have an answer or at least
> not one that has the usefulness that Michael wants.

It clearly does have a useful answer, as Michael points out.  Git may
not care about branches enough for this question to be meaningful for
it, but humans certainly do care.  And with the Emacs development
model, public development branches do matter.

bug#33328: 27.0.50; Extend Emacs bug report

[Achim Gratz]

Michael Albinus writes:
> There is a useful answer. If it tells me a branch name which is not
> public, I know that I even cannot trust "emacs -Q" behavior. I will
> continue with more inquisitorial questions :-)

No it doesn't.  Again, branch names are local things and may or may not
match up with upstream, whether you like it or not.  The commit id is
telling you that you are still looking at the same checkout that you
have (or not if there actually are local changes).

> Fortunately, most of the time this is not necessary 'cos people use
> publich branches.

Nope.  If you want to correlate commit id to branch names in the way you
expect to, you need to do it in a repo _you_ control.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

bug#33328: 27.0.50; Extend Emacs bug report

[Michael Albinus]

Achim Gratz <Stromeko@nexgo.de> writes:

Hi Achim,

>> Fortunately, most of the time this is not necessary 'cos people use
>> publich branches.
>
> Nope.  If you want to correlate commit id to branch names in the way you
> expect to, you need to do it in a repo _you_ control.

It is sufficient for me to know, whether a given branch name is a public
one. Then I can try to reproduce a bug or whatever.

If it is an unknown (local) branch name, I will ask for more
information. Or I will ask to rerun the failed test in a public
branch. Otherwise, I cannot investigate.

That's all about.

> Regards,
> Achim.

Best regards, Michael.