From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Matt Armstrong Newsgroups: gmane.emacs.bugs Subject: bug#59064: 29.0.50; build problem git worktree linked to main worktree (repo) Date: Sun, 06 Nov 2022 10:17:06 -0800 Message-ID: <87v8nsaqxp.fsf@rfc20.org> References: <87y1so1fso.fsf@no.workgroup> <87iljsruwz.fsf@no.workgroup> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38773"; mail-complaints-to="usenet@ciao.gmane.io" Cc: philip kaludercic To: Gregor Zattler , 59064@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Nov 06 19:18:22 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1orkDu-0009rp-1Z for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 06 Nov 2022 19:18:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1orkDe-0005iX-9D; Sun, 06 Nov 2022 13:18:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1orkDb-0005iI-Rt for bug-gnu-emacs@gnu.org; Sun, 06 Nov 2022 13:18:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1orkDb-0007OK-DS for bug-gnu-emacs@gnu.org; Sun, 06 Nov 2022 13:18:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1orkDa-0005qP-5f; Sun, 06 Nov 2022 13:18:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Matt Armstrong Original-Sender: "Debbugs-submit" Resent-CC: philipk@posteo.net, bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Nov 2022 18:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59064 X-GNU-PR-Package: emacs X-Debbugs-Original-Xcc: philip kaludercic Original-Received: via spool by 59064-submit@debbugs.gnu.org id=B59064.166775864322420 (code B ref 59064); Sun, 06 Nov 2022 18:18:02 +0000 Original-Received: (at 59064) by debbugs.gnu.org; 6 Nov 2022 18:17:23 +0000 Original-Received: from localhost ([127.0.0.1]:60554 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1orkCw-0005pX-GC for submit@debbugs.gnu.org; Sun, 06 Nov 2022 13:17:22 -0500 Original-Received: from relay1-d.mail.gandi.net ([217.70.183.193]:43635) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1orkCs-0005pH-6k for 59064@debbugs.gnu.org; Sun, 06 Nov 2022 13:17:20 -0500 Original-Received: (Authenticated sender: matt@rfc20.org) by mail.gandi.net (Postfix) with ESMTPSA id 13411240004; Sun, 6 Nov 2022 18:17:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rfc20.org; s=gm1; t=1667758631; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ByQbEknMK2BdALNw7ZofO/j+EfMXHimY1K1E3XOmM/o=; b=BFkfuFkEwCZkBBtroNOthdmMMOAseG8xiAGnCo3q/PKuWCnMAz+mf+cmtTm/AGcyu0jx9J 1wiZT8nLYK4sZ93D/cWUgnz+siAnz3eMcUwLJ3wyVuQtDDNyEwir1jOOLDWTSCXLwKLeTk 40QgmOinSoLhD4VIOQAFjszWpvG1A2eEx2c2uaxmfe1DdtuGY0CPBTo0mKss8+pPwIwPS3 Kor6mny6W6binOS7BnEVol2ZScnJ7NmxjLZytFiNJ77EYrGKtK28EFqcf4H91ZlXbIOJXt SNr09zgovjyFFJWVdaCqOpd7MRmUWnTlR8JSh6m28JLrFC+o2zR7mUDNmHvW6Q== Original-Received: from matt by naz with local (Exim 4.96) (envelope-from ) id 1orkCg-000SEl-0G; Sun, 06 Nov 2022 10:17:06 -0800 In-Reply-To: <87iljsruwz.fsf@no.workgroup> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:247228 Archived-At: X-Debbugs-CC: Philip Kaludercic Hi Philip, this bug manifests for Gregor as Emacs build error in a particular kind of git repository, but it is really a problem with `vc-git-mode-line-string' caused by a recent commit of yours to `vc-working-revision'. Could you take a look? Gregor Zattler writes: > I will try to bisect. But since I have no clue regarding the build > system I only hope that this will not hit other build failures in > between. This will take days... Gregor, no need to bisect. Your most recent instructions helped. This is not a mysterious problem with the build system, but a simpler one with a recent regression in Emacs' vc-mode. The steps to reproduce are simple: 1) In the root directory of an existing Emacs git repository, run this: git switch master git worktree add -d ../b59064 Note that the -d is important. This creates a "detached" work tree attached to no branch at all, but just happens to be at the same rev as "master". 2) cd ../b59064 3) git status Confirm this prints "Not currently on any branch." 3) emacs -Q (using a recent Emacs built on master, not one built in this new repository) 3) M-: (setq debug-on-error t) Edit any file in this repository, I did C-x C-f "INSTALL". You may then need to run M-x vc-mode. You get the following problem in `vc-git-mode-line-string': Debugger entered--Lisp error: (args-out-of-range "master" 0 7) vc-git-mode-line-string("/home/matt/git/e/b59064/admin/grammars/srecode-tem...") apply(vc-git-mode-line-string "/home/matt/git/e/b59064/admin/grammars/srecode-tem...") vc-call-backend(Git mode-line-string "/home/matt/git/e/b59064/admin/grammars/srecode-tem...") vc-mode-line("/home/matt/git/e/b59064/admin/grammars/srecode-tem..." Git) vc-refresh-state() run-hooks(find-file-hook) after-find-file(nil t) find-file-noselect-1(# "~/git/e/b59064/admin/grammars/srecode-template.wy" nil nil "~/git/e/b59064/admin/grammars/srecode-template.wy" (67952095 27)) find-file-noselect("/home/matt/git/e/b59064/admin/grammars/srecode-tem..." nil nil nil) find-file("/home/matt/git/e/b59064/admin/grammars/srecode-tem...") dired--find-file(find-file "/home/matt/git/e/b59064/admin/grammars/srecode-tem...") dired--find-possibly-alternative-file("/home/matt/git/e/b59064/admin/grammars/srecode-tem...") dired-find-file() funcall-interactively(dired-find-file) call-interactively(dired-find-file nil nil) command-execute(dired-find-file) The `vc-git-mode-line-string' code assumes that if `vc-git--symbolic-ref` returns nil then `vc-working-revision' must necessarily return a full hex git rev ID, so it unconditionally performs the following on that value: (substring rev 0 7) However, Philip Kaludercic's recent commit 307ad210040 changed `vc-working-revision' to resolve a hex ID to a symbolic revision if possible, so in this case the function returns "master", causing `substring' to signal as above. This is not currently a problem in "normal" git trees because the following command works in them: git symbolic-ref HEAD ...and this is what vc-git-mode-line-string normally uses to construct the displayed revision used in that line. In detached worktrees that command fails: $ git symbolic-ref HEAD fatal: ref HEAD is not a symbolic ref ...yet the following works: $ git rev-parse HEAD 6e5ec085510ccf52ac6cb07c3a1a2778324a1d89 ...and from that we can get to a symbolic name (the new code Philip added to `vc-working-revision'): $ git name-rev --no-undefined --name-only 6e5ec085510ccf52ac6cb07c3a1a2778324a1d89 master Arguably, `vc-git-mode-line-string' should no longer call `vc-working-revision' but instead a lower level variation that must return the hex rev id. Perhaps?