list mirror (unofficial, one of many)
 help / color / Atom feed
From: Derrick Stolee <>
To: Bryan Turner <>,
	Git Users <>, "" <>,
	"" <>
Subject: Re: Split commit graphs and commit-graph read
Date: Sun, 10 Nov 2019 20:19:20 -0500
Message-ID: <> (raw)
In-Reply-To: <>

On 11/8/2019 6:41 PM, Bryan Turner wrote:

Hi Bryan,

> Just a quick question about a behavior I've noticed with the commit
> graph. (Amazing feature, by the way!)
> If the _very first_ write done is split:
> git commit-graph write --reachable --split
> You end up with something like this:
> .../objects$ ls -R info
> info:
> commit-graphs  packs
> info/commit-graphs:
> commit-graph-chain  graph-6612fcc8fd04d3af2cc268a6bd9161ae40f5fcbf.graph
> info/commit-graph doesn't exist, but I have a 1-graph "chain" in
> place. (And subsequent write --split calls write additional ones; I've
> got a few now in this repository, but still no info/commit-graph.)
> git commit-graph verify seems happy:
> .../objects$ git commit-graph verify
> Verifying commits in commit graph: 100% (98768/98768), done.

This workflow seems expected.

> But git commit-graph read isn't:
> .../objects$ git commit-graph read
> fatal: Could not open commit-graph
> '/path/to/repository/objects/info/commit-graph': No such file or
> directory
> Running some tests with commands like git for-each-ref and git
> rev-list shows that the "split" commit graph is being used (setting
> core.commitGraph=false makes commands noticeably slower), so
> functionally all seems well. But should git commit-graph read be
> handling this better?

Unfortunately, you're running into an issue because I designed the
"read" subcommand poorly (and also forgot to update it for
incremental commit-graph files). The biggest issue is that "read"
is not really meant for end-users. It really should have been built
as a test-tool. This point was corrected when I got around to writing
the multi-pack-index since it uses "test-tool read-midx" instead of

To fix this issue, I would probably go about it by removing the "read"
subcommand and creating a "test-tool read-commit-graph" for the tests
that need that output.

If others on-list think that the better thing to do is to update the
"read" subcommand to provide the same output, but iterate over each
layer of an incremental commit-graph, then I can do that work instead.


  reply index

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-08 23:41 Bryan Turner
2019-11-11  1:19 ` Derrick Stolee [this message]
2019-11-11  2:09   ` Junio C Hamano
2019-11-11  3:29   ` Jeff King
2019-11-12  0:28   ` Bryan Turner

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:

  List information:

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

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Example config snippet for mirrors

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:

AGPL code for this site: git clone