Re: Regression in: [PATCH on sb/more-repo-in-api] revision: use commit graph in get_reference()

From: SZEDER Gábor <szeder.dev@gmail.com>
Date: Jan 25, 2019, 22:14 UTC
Message-ID: <20190125221414.GG6702@szeder.dev>
In-Reply-To: <CAGZ79kZRnuTU3ukP1UdBUZD1x+nubYSwLxYgJse1mcj8JUOa2g@mail.gmail.com>

On Fri, Jan 25, 2019 at 11:56:38AM -0800, Stefan Beller wrote:

Show 21 quoted lines

> > Have fun! :)
> 
> $ git gc
> ...
> Computing commit graph generation numbers: 100% (164264/164264), done.
> $ ./git version
> git version 2.20.1.775.g2313a6b87fe.dirty
> # pu + one commit addressing
> # https://public-inbox.org/git/CAGZ79kaUg3NTRPRi5mLk6ag87iDB_Ltq_kEiLwZ2HGZ+-Vsd8w@mail.gmail.com/
> 
> $ ./git -c core.commitGraph=false describe --dirty --all
> remotes/gitgitgadget/pu-1-g03745a36e6
> $ ./git -c core.commitGraph=true describe --dirty --all
> remotes/gitgitgadget/pu-1-g03745a36e6
> $ ./git -c core.commitGraph=true describe --dirty
> v2.20.1-776-g03745a36e6
> $ ./git -c core.commitGraph=false describe --dirty
> v2.20.1-776-g03745a36e6
> 
> it looks like it is working correctly here?
> Or did I miss some hint as in how to setup the reproduction properly?

How many refs are pointing to the commits you tried to describe? In the git repo, with an all-encompassing commit-graph it seems to be important that more than one refs point there. I could reproduce the issue in a fresh git.git clone with Git built from commit 2313a6b87fe:

  $ git clone https://github.com/git/git
  Cloning into 'git'...
  <...>
  $ git commit-graph write --reachable
  Computing commit graph generation numbers: 100% (56722/56722), done.
  # 'HOME=.' makes sure that this command doesn't read my global
  # gitconfig.
  $ HOME=. ~/src/git/git describe --all --dirty
  heads/master-dirty
  $ git checkout origin/pu 
  HEAD is now at cb3b9e7ee3 Merge branch 'jh/trace2' into pu
  $ HOME=. ~/src/git/git -c core.commitGraph=true describe --all --dirty
  remotes/origin/pu
  $ git branch a-second-ref-pointing-at-pu buzz ~/src/tmp/git
  $ HOME=. ~/src/git/git -c core.commitGraph=true describe --all --dirty
  heads/a-second-ref-pointing-at-pu-dirty

I could also reproduce it in other repositories lying around here, but could not manage to reproduce it in a minimal repository.

The smallest I could get is the test script below, where the last test fails, i.e. the clean worktree is described as '-dirty', when the to-be-described HEAD is not in the commit-graph. I suspect this is the same issue, because it bisects down to this same commit.

  --- >8 ---

Subject: [PATCH] test

---
 t/t9999-test.sh | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)
 create mode 100755 t/t9999-test.sh

diff --git a/t/t9999-test.sh b/t/t9999-test.sh
new file mode 100755
index 0000000000..cd1286e157
--- /dev/null
+++ b/t/t9999-test.sh
@@ -0,0 +1,26 @@
+#!/bin/sh
+
+test_description='test'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+	test_commit one &&
+	test_commit two &&
+	# Two refs point there.
+	git for-each-ref --points-at=two &&
+	git config core.commitGraph true
+'
+
+test_expect_success 'full commit-graph' '
+	git commit-graph write --reachable &&
+	verbose test "$(git describe --all --dirty)" = tags/two
+'
+
+test_expect_success 'partial commit-graph, described HEAD is not in C-G' '
+	git rev-parse one | git commit-graph write --stdin-commits &&
+	git status &&
+	verbose test "$(git describe --all --dirty)" = tags/two
+'
+
+test_done

-- 
2.20.1.642.gc55a771460