Notes from the Git Contributor's Summit, 2026

Thanks to everybody who participated in this year's Contributor's Summit, and to the folks who took notes during the discussions.

I'm sharing the notes here so that people who could not attend can catch up, and so we can continue the discussions on the list. The shared notes are also in Google Docs:

  https://docs.google.com/document/d/15gDNTjCh9-aQ1ES2MDot5_Qnxj6vRMGwxbH7eixxT84/edit

The topics covered in the replies below are:

 - Security mailing list and security process
 - Git 3.0
 - Documentation
 - Outreachy sponsorship
 - What can we do next with pluggable ODB?
 - AI contribution policy
 - Protocol v2 for pushes

I've lightly edited the notes for readability and kept the speaker attributions. These are discussion notes, rather than a verbatim transcript; please reply with corrections or anything the notes missed. Release dates and reports of work in progress reflect the discussion at the summit.

Each topic has its own reply to this message so that follow-up discussion can stay with the relevant notes.

If you have feedback about the summit itself, please share it here or with me off-list.

Thanks, Taylor

Topic: Security mailing list and security process
Leader: Toon Claes
Notetaker: Peff

* Toon: We have a high influx of reports on the security list from
  outside the community, probably from people using AI. There are many
  unaddressed reports. We need a better process for addressing them, and
  to figure out who will do the work.

* Emily: How are we cutting security releases now? Are we waiting for
  the reports to stop before cutting a release?

* Taylor: There are many reports we still need to triage and determine
  which are important.

* Toon: I have been organizing the reports, and some patches have been
  sitting around for months.

* Patrick: Eventually we have to cut a release, because the influx will
  not stop.

* Peff: We should act on what we have triaged once we have enough for a
  release.

* Patrick: We get many duplicate reports from AI findings. We should be
  more willing to cut releases, with a well-defined timeline. We should
  document the process, perhaps in terms of a number of weeks after a
  report.

* Peff: I am hesitant to promise a response to reports within a fixed
  number of weeks.

* Patrick: We should try to rely on companies investing in fixes,
  without forcing volunteers to work on them.

* brian: We should document our security model. Many reports are not
  vulnerabilities, but explaining why takes work.

* Patrick: Documenting the model might also help AI tools respect it.

* Emily: Are we interested in following the Linux kernel's approach of
  not embargoing AI-found vulnerabilities?

* Patrick: I am worried about that because of vulnerabilities affecting
  forges.

* Taylor: It depends on the models; some are better than others.

* Patrick: We should fix non-security issues on the public mailing list,
  and be more proactive about moving reports there when nobody else
  replies.

* brian: Sometimes there is pushback about whether something is a
  vulnerability.

* Patrick: There should probably be a period after which it is assumed
  that a report can go public.

* Patrick: GitLab has put some resources into this, but I would like to
  see more from other companies.

* Emily: It has been difficult to get resources from companies. The
  response is often that AI could help with triage, but putting
  non-public knowledge into public AI systems feels risky.

* Taylor: We could consider using AI to help with triage and writing
  patches. It might be easier to get companies to sponsor the work if it
  is less arduous.

* brian: There are DCO questions, which I would like to leave for the AI
  discussion. At GitHub, Elijah is our only person in git-contrib. There
  is more work than we have staff for, and corporate email requirements
  make list work difficult.

* Peff: We can coordinate in the cabal repository.

* Patrick: Could we put money into a fund to pay somebody to work on
  security, perhaps using AI, and get ahead of the findings?

* Martin: The project has a bucket of money.

* Taylor: I do not have the exact figure, but probably around $100k.
  Would we hire a third party, or somebody from one of the companies?

* Patrick: We probably need somebody from the project.

* Emily: Why is there resistance to hiring a third party?

* Peff: I am skeptical because the onboarding cost and time might be
  substantial.

* Emily: There are contracting firms suited to open source. We have been
  happy with Collabora, and I am happy to explore similar options,
  though it costs a bit more.

* Adrian: Such projects are hard to pitch internally. We do address
  security issues in other projects, but at a normal rate of $200/hour,
  a $100k project is difficult to pitch.

* Peff: Toon has already made a list, and we have fixes. Can we make a
  release with what we have? The list may not be as long as we think.

* Patrick: Can we write down the process, and perhaps automate it?

* Taylor: It is not primarily a scripting issue. We need to assemble the
  required tags and have the confidence to say we have enough to cut a
  release. We should discuss it on the list. The list of reports is long
  enough that we may never get through all of it.

* Patrick: We should get more comfortable with faster releases.

* brian: Anyone should be able to propose a new release.

* Patrick: We can try to accommodate different release schedules, but
  eventually we should put our foot down.

* Taylor: Microsoft needs around seven weeks for a release.

* brian: Microsoft needs to provide staffing if it wants a particular
  schedule.

* Taylor: Does anybody object to telling Microsoft that we will not
  follow its schedule?

* [No objections recorded.]

* Patrick: Agreed. Who wants to tell them?

* Taylor: I do not want to make an ultimatum about adding resources.
  They might add a third party that does not work well with us and still
  stick with Patch Tuesday.

* Peff: I had hoped to goad Toon into handling a release.

* Toon: OK, but I mostly do not know how.

* Patrick: That is a general problem: the process is not documented, and
  we need to figure it out.

* Peff: I will see if I can dig up the resources I remember. Is it OK to
  discuss the process on the public list?

* [General agreement that discussion on the public list is OK.]

* Peff: I will write an email to the public list to start the process
  discussion.

* Taylor: Johannes, Junio, and I should contribute our experience.

* Patrick: Would scripting make it easier?

* Taylor: No, it is the work of merging fixes up through the versions.

* Junio: Fixes do not always apply to both old and new code.

* Peff: There is also the work of writing security advisories and
  obtaining CVEs.

Topic: Git 3.0
Leader: Patrick Steinhardt
Notetaker: Justin

* Patrick: The blocker was GitHub not having SHA-256 support. When will
  GitHub fully support it?

* brian: GitHub has shipped it experimentally, with general availability
  probably in November.

* Patrick: GitLab already has public, non-experimental support. We are
  looking at spring next year for Git 3.0. libgit2 has support; JGit
  does not.

* Emily: Google will not fund SHA-256 support in JGit.

* brian: It does not look like Bitbucket will support it.

* Emily: Gitoxide may have funding for SHA-256 support.

* brian: There will be a couple more releases: 2.56, then 2.9x, and so
  on.

* Taylor: We could use 2.99 and then 2.999 if needed.

* Patrick: 2.99 would be a stronger signal than 2.95.

* Peff: Why might users not want to jump to 3.0? Rust support will be
  mandatory.

* Patrick: A possible schedule is 2.56 in September 2026, 2.98 in
  December 2026, and 2.99 and 3.0 in March 2027. We need to find out
  whether anybody is interested in an LTS release.

* brian: Gentoo would be interested in a 2.99 LTS release.

* Patrick: We could potentially cut out one of the releases.

* Peff: We could make one of the cycles shorter.

* Taylor: The 3.0 release could be small, containing only the changes to
  the defaults.

* Patrick: The counterargument is that we want to use 2.99 as a signal.

* Peff: We should release 2.99.1 and 3.0 at the same time, with only the
  BREAKING_CHANGES defaults flipped in 3.0.

* [Consensus among the attendees.]

* brian: Are there any objections to Rust in 3.0?

* [No objections recorded.]

* Peff: Are there timing concerns around distribution release cycles? We
  might want to synchronize with them.

* brian: If we do 2.99 and 3.0 back to back, that puts us in the April
  timeframe.

* Patrick: Do we want to drop 2.57?

* [The notes record dropping 2.57 in favor of an earlier 2.98.]

* Peff: GitHub might encounter bugs once users start using SHA-256.
  Would we see similar bugs in Git?

* brian: Codeberg exposes this in its UI, and has a decent number of
  users.

* Patrick: GitLab has test suites covering this, and we have upstreamed
  a few fixes. I am confident there are very few bugs.

* Patrick: Should we migrate?

* Taylor: I may be a little behind on the interoperability work. Would
  it also handle historical tags?

* brian: Yes. The work is done, but not on the list. You can clone a
  normal SHA-1 repository and get interoperability with SHA-256.

Topic: Documentation

* Julia: There is a big gap between contributors who know Git's concepts
  and users who do not know what objects or the index are. I have been
  working on a website to bridge that gap. We do not explain some basic
  terms, such as "upstream". Some documentation receives hundreds of
  comments. How can we bring that feedback to the mailing list without
  overwhelming it, and improve the documentation with very little
  funding?

* Patrick: Could we expand the funding? This work is important, and we
  are not technical writers.

* brian: We have gitglossary and the Pro Git book, but it would be good
  to have beginner documentation. Many users arrive from university
  without knowing these concepts. I have submitted some documentation in
  this area.

* Patrick: Pro Git may be outdated in places. Scott wants a new version
  and could fund somebody to work on it.

* Emily: We can suggest a huge book to somebody who is new and just
  wants to use Git.

* Peff: The manpages are reference material, so they should be terse.
  Most users also need something less terse. If somebody is interested
  in working on this, we should consider replacing outdated
  documentation rather than preserving it for its own sake.

* Patrick: We should allow iterative work. Review can be nitpicky, but
  perhaps we can be more accommodating so this can move faster.

* Julia: Being able to merge quickly and iterate would help.
  Mailing-list feedback is useful.

* brian: Thank you for working on the documentation. Bad documentation,
  or no documentation, makes software hard to use.

* Patrick: Terse does not necessarily mean accessible. We could learn
  from TLDR and include examples.

* Julia: Examples are useful, and we should update the existing ones.

* Josh: We could consider Diataxis, which separates tutorials, guides,
  explanations, and reference material:
  https://diataxis.fr/

* Julia: The format of the reference manpages makes sense.

* Peff: I did not mean to defend the manpages. New-user documentation
  and manpages are two separate things, and both need work.

* Julia: Git has guides and manpages, which is a useful separation. The
  guides are harder to discover; the manpages are more accessible.

* Patrick: How much time do you have funding for?

* Julia: We have 100 hours split between two people.

* Patrick and others: Perhaps we could use the Git fund.

* Peff: Other companies might also be interested in funding the work.

* [OpenAI, GitHub, and GitButler were mentioned as possibilities.]

* brian / Emily / Mark: We can ask about funding.

* Mark: We have both machine-readable and human-readable material.

* Toon: We are only discussing written documentation.

* Peff: Costs can escalate with video. I am biased toward written
  documentation.

* Patrick: GitButler has resources, and younger users may prefer videos.

* Julia: We could link good Git videos from the website.

* Emily: There are links on Discord that we could include.

* Julia: We do not have a good entry point on the Git website explaining
  how to learn Git.

* Peff: The site had one, but it gets outdated. We should refresh it as
  we go.

* Julia: Some documentation says "see section XYZ" without linking it.
  We cannot link to subsections of manpages.

* Peff: I spent some time generating subsection links.

* Julia: We have links to other pages, but not to subsections.

* Peff: References in the text need the linkgit markup. This could be an
  incremental project.

* Julia: I added a cheatsheet to the website. Do we want to move away
  from ASCII diagrams?

* Patrick: Could we use different sources for different outputs, with
  SVG for HTML and ASCII for manpages?

* brian: We could do that.

* Patrick: Perhaps Mermaid would let us keep a plain-text source and
  choose the output format.

* Julia: It should be possible. We have CI scripts that Johannes worked
  on, and we used Graphviz.

* brian: There are extensions, but they are not packaged for
  distributions.

* Peff: We support both AsciiDoc and Asciidoctor. Would it help to get
  out of that dual world?

* Patrick: Traditionally this was for migration. AsciiDoc was thought to
  be unmaintained, but it is maintained now.

* Peff: We could move to Asciidoctor.

* brian: Fedora still uses AsciiDoc. Asciidoctor is well maintained,
  written in Ruby, and reasonably portable. It depends on how much we
  want to support. I do not know whether Fedora is still an obstacle.

* Peff: Who would object to moving, and how strongly?

* Junio: We could include it in Git 3.0 and add it to BreakingChanges.

* Josh: Some documentation already renders poorly with old versions of
  AsciiDoc.

* Peff: Send those bugs to the list; somebody may be interested in
  fixing them.

* Josh: We could use this to fix the build pipeline and move away from
  AsciiDoc.

* Patrick: Fedora does have Asciidoctor, version 2.0.26.

* Peff: I tried Asciidoctor on Debian, and it works well. There are some
  rendering issues, though it mostly gets things right. Julia, would you
  be interested in using doc-diff to compare the outputs?

* [Patrick created an issue during the discussion.]

* Emily: Do we have traffic metrics for git-scm.com?

* Taylor: Some high-level metrics in Cloudflare.

* Peff: We had Google Analytics, but were not comfortable with it and
  removed it.

* Emily: It would be useful to know how many users read the
  documentation.

* brian: It would be useful to know which manpages people read, while
  being mindful of privacy as an open-source project.

* Taylor: Could we self-host metrics, or use a third party that supports
  this?

* Mark: Fathom is one privacy-focused option:
  https://usefathom.com/

* brian: Even webserver logs would be useful for getting some numbers.

* Peff: On Heroku, the caching layer meant we did not see accurate
  numbers.

* Patrick: Will AI scrapers drown out the useful signal?

* Toon: I opened an issue about this some time ago:
  https://github.com/git/git-scm.com/issues/2054

* Taylor: We enabled it, but did not see useful information.

Thank you for the nice summaries Taylor.

Taylor Blau wrote:

The Fedora packages have used Asciidoctor by default since e942c8d (use Asciidoctor to build documentation when possible, 2020-02-25).

    https://src.fedoraproject.org/rpms/git/c/e942c8d

That hasn't changed since I stopped maintaining the git package, so Fedora hasn't had an issue with a switch to Asciidoctor for quite a long time.

CentOS Stream / RHEL uses AsciiDoc (with the odd exception of 9). They _could_ use Asciidoctor relatively easily; it is maintained for EPEL already.

But if Red Hat really dislike requiring Asciidoctor for git builds in RHEL, they could ship the pre-built docs, as I used to do for EL-5 builds due to an unsupported (read: ancient) AsciiDoc version.

If we switched to Asciidoctor, it _might_ open the door to replacing the docbook/xmlto dependencies and having Asciidoctor directly generate the man pages.

I haven't thought about or looked at that in a long, long time, so I don't know if that would be a worthwhile change or not. I don't recall if we need the XML step for other outputs, like info or PDF (neither of which I ever spent much time trying to build).

Todd Zullinger <tmz@pobox.com> writes:

FYI.

The prebuilt docs I publish, which I presume is the one you are referring to here, switched to use Asciidoctor in mid 2024.

Topic: Outreachy sponsorship

* Chris: We want three interns, at $10k per intern. Are any companies
  interested in helping? The session starts in early December. GitLab or
  GitHub sponsored this in the past, but as of last year neither wanted
  to, so Git has had to pay.

* Patrick: Talk to GitLab's contributor success person.

* Elijah: We need to identify the right person to ask.

* Emily: I can ask Google's OSPO whether there is interest, though I am
  not expecting much.

Git Merge 2027:

* [There was some interest in holding Git Merge in Canada, given the
  political climate.]

* [Announcing the location early would help Outreachy and GSoC interns
  who want to attend.]

Topic: What can we do next with pluggable ODB?

* Emily: We saw this working in Patrick's talk. What do we want to do
  with it next?

* Patrick: Most things work, but we are not all the way there yet;
  commit-graph and MIDX are examples. The plan is to add a repository
  extension in 2.57.

* Peff: From the Mercurial talk, you can convince Git to make good
  deltas, but doing so has a cost. I do not think the ODB API is at a
  level where deltas can be created on the fly.

* Patrick: I think we can do that. They have information we do not have.
  Renames are tricky.

* Peff: The ODB does not know anything beyond the content. Could we give
  it more information?

* Patrick: We may want to evolve this based on the representation. We
  could pass a `struct commit *` into the ODB API instead of just
  content.

* Peff: What we have now is a reasonable stopgap.

* Patrick: Content-defined chunking is another possibility.

* Taylor: Would that be at the object layer, or a property of a
  particular ODB store implementation?

* Patrick: I would like to do it natively, but that seems like a large
  change.

* brian: It could be part of a new pack/index format. I am very much in
  favor of content-defined chunking.

* Peff: There is a logical object model. Would this be a new object
  type, where a chunked object and a blob have different hashes, or
  something below that?

* Patrick: We could start at the storage layer and eventually move it to
  the object layer.

* Taylor: Perhaps, but perhaps not. This may be easier than we are
  thinking.

* Patrick: Moving the ecosystem may be difficult.

* brian: We could have a compatibility fallback.

* Peff: Then we would have two equivalent representations of an object
  which do not hash to the same thing.

* brian: We could introduce a pack-only object type.

* Peff: Which OID would I refer to?

* brian: The blob's OID.

* Taylor: That is analogous to REF_DELTA and OFS_DELTA: multiple
  representations of the same thing.

* brian: We would need a format extension, because we are out of bits.

* Patrick: Would we still want to put it in a pack?

* brian: Yes.

* Patrick: Start with the storage layer, then see where it goes.

* Patrick: Would this only be for blobs?

* Taylor: Is "chunked" a refinement of a blob, or an attribute
  independent of object type?

* brian: Trees are not currently binary-searchable. It would be nice to
  fix that too.

* Patrick: Perhaps reftable could provide inspiration there.

* Emily: After Patrick's talk, my skip-level manager asked whether we
  could build a commit cloud with Git. What else could we do that is
  totally wild?

Topic: AI contribution policy

* Josh: What is the current AI policy?

* Elijah: [Reading from SubmittingPatches.] The DCO requires
  contributors to certify their contributions, and it is not clear
  whether they can do that for AI-generated output.

* Taylor: If we take AI out of the picture, is any of that inconsistent
  with how we already treat patches?

* brian: It often has a distinct character. It may get better, but
  currently it can be noticeable and awkward to read.

* Elijah: It is often useful for proofreading and improving writing.

* Emily: One thing missing from the policy is attribution. Johannes sent
  something with an Assisted-by trailer, which helps us understand
  whether and how a tool was used.

* Taylor: Would I review Johannes's patches differently if I knew AI was
  used?

* Emily: It is different for new contributors and people with whom we
  have established trust.

* Patrick: Sometimes knowing helps us avoid reading complete garbage.

* Emily: Having the policy in SubmittingPatches helps because people and
  agents will read it.

* brian: Many people do not read SubmittingPatches often, but honesty
  about where code came from is useful. Using AI for language cleanup is
  useful too.

* Taylor: The policy effectively says we cannot do anything significant
  with these tools.

* Peff: We are seeing more contributions where an agent makes the
  changes and a person acts as a "meat proxy".

* Emily: Those proxies are getting thinner.

* brian: The Linux kernel requires people to state that they have
  authority to submit the code.

* Peff: What is the rest of the open-source world doing? Are we missing
  useful tools by being conservative?

* brian: Some people will no longer trust us if we accept AI-generated
  code.

* Taylor: The Linux kernel is much more permissive than we are.

* Peff: We imagine that we will be sued, while the rest of the world
  does not seem to.

* Patrick: Opening the policy further would open the door to an even
  greater influx of contributions.

* Emily: That is why I want more attribution.

* brian: When I contribute to open source, I am attributed as the
  author. With AI-written code, I am implicitly using other people's
  code.

* Taylor: When I read code from a project with a license incompatible
  with Git's, I learn from it, and that knowledge may implicitly
  influence my work on Git.

* brian: That is a coherent position, but not everybody agrees. The
  project has to decide.

* Emily: Have we used a voting process for something like this before?

* Patrick: We need proposals and a vote. Who would be allowed to vote?

* Peff: Active developers with a track record; perhaps a threshold such
  as 50 merged patches.

* Taylor: We asked the SFC lawyers, and the result is what is in
  SubmittingPatches.

* brian: SFC is very American in its legal approach.

* Peff: We should give SFC more credit; it is more worldwide than that.

* Emily: This was a problem with GSoC. There was a record amount of
  contributions, but the quality was poor.

* Peff: We need to agree on a policy. Do we accept AI at all, and to
  what degree?

* Taylor: One possibility is a process similar to Debian's, with
  proposals and voting.

* Patrick: We need to follow legal counsel, and we do not need to use
  the same proposals as Debian.

* Peff: We got legal advice on the current text. We should work out the
  voting options, take them through SFC counsel, communicate the risks
  and concerns, and then hold the vote.

* Emily: I am happy to set this up. I have been doing something similar
  with Jujutsu.

* Peff: We depend on Junio. If people disagree with the policy, they
  could fork into Git-AI.

* Josh: Let a few key people put forward their opinions and see how much
  they differ.

* Patrick: Let us do that on the mailing list.

* Peff: brian, would you champion one position?

* brian: Sure. I will take some things from the Debian project.

* Peff: Taylor, would you put forward another position?

* Taylor: Sure, though I am not yet sure what it would be.

* Patrick: Then we need to decide what the vote would be.

* Martin: If there is a vote, how would the result be enforced?

* Peff: Junio is the source of authority, and usually follows the crowd.

* Peff: Emily, are you leading the voting procedure?

* Emily: Yes.

Topic: Protocol v2 for pushes
Notetaker: Emily

* brian: Some customers have millions of refs. Reftable has helped us
  push up to 100k at a time, which was a big increase. AI means more
  branches and refs, so the problem keeps getting worse. One customer
  was unhappy about an 896 MB ref advertisement. Protocol v2 for pushes
  would help. Much of the code already exists and needs wiring up.

* Peff: We were waiting for somebody with a use case they care about.
  Protocol v2 has a capability advertisement that leaves room for
  further extensions.

* Elijah: With fetch v2, it would be useful to request only a handful of
  heads rather than advertise all refs and tags.

* Jonathan Tan: We have prefix filtering for fetch v2. A client can
  request refs/heads/somename, and the server sends refs matching that
  prefix.

* Peff: The client needs a better refspec, and the user interface is
  hard. How do we specify the mainline? Even excluding HEAD can speed
  things up. This is an optimization; a push is correct as long as the
  objects are reachable.

* Peff: Could we use multiple passes, trying a smaller set and falling
  back to a larger one if some objects are still unreachable? Many
  advertised refs are not useful, such as abandoned development
  branches.

* [There was a related discussion about showing fewer refs in GitHub's
  UI.]

* Peff: Could a server-side configuration limit the advertisement and UI
  to a smaller set of refs, with the client ignoring the others?

* brian: It is useful to control what the client requests. During a
  push, we want to say that we care about only a handful of branches.

* Peff: That still sounds like a refspec problem; the default asks for
  too much.

* Jonathan Tan: This is push, though.

* Peff: The client could suggest useful branches more intelligently.
  Guessing the main branches is a heuristic, but upstream tracking
  branches might be useful.

* brian: A project setup script, perhaps linked from its documentation,
  could provide useful initial configuration.

* Jonathan Tan: Instead of a ref advertisement during push, it would be
  useful to negotiate. Restricting the advertised refs may cause the
  client to send everything if the optimization does not work. Relying
  on the remote to know what matters is error-prone. We would be happier
  with a few round trips: advertise capabilities, exchange haves and
  acknowledgments, negotiate the push, and send the pack.

* Elijah: During a repack, the server might give a false negative. This
  may be relevant to shallow clones.

* Peff: We could race and miss a common commit, then be unable to look
  further back because the client is shallow.

* Elijah: Geometric repacking may help because it is less likely to miss
  something. A push to the wrong place should fail quickly. Let us leave
  shallow clones to develop their own story.

* Peff: Successful negotiation could also make connectivity checks
  easier. We could cache information in receive-pack and pass it to
  check-connected.

* brian: Shallow clones can spend much more time trying to minimize the
  wire transfer. One push went from two seconds to 35 seconds because of
  that optimization. `objects-edge-aggressive` is relevant here.

* Jonathan Tan: We might get substantial savings from simply disabling
  ref advertisements with a configuration option.

* Peff: Even without a protocol change, the server could decide which
  refs are interesting and limit its advertisement. That might be easier
  than introducing v2 for pushes.

* Jonathan Tan: The client needs to tell the server that it wants to
  negotiate.

* Peff: It might not need to negotiate.

* Jonathan Tan: Would that not be bad?

* Peff: In practice the drawback may be small, though completely
  unrelated histories would be a bad case.

* Elijah: That can happen when appending a shallow commit.

* brian: I have seen that happen too.

* Peff: In that degenerate case, do these optimizations already have
  problems?

* Jonathan Tan: Negotiation does not have as much trouble because it
  starts at the tip the client is pushing.

* [General agreement that putting unrelated histories into one
  repository is best avoided.]

* Peff: Nobody objects to push v2. We have the hooks and the fetch-v2
  infrastructure. There may be an easier place to start, though.

* brian: Another benefit of push v2 is interoperability. Currently a
  client must push using the server's hash algorithm; it cannot
  negotiate a different one. Fetch can do some negotiation.

* Peff: If v2 makes interoperability easier, go for it.

* Emily: What is the failure mode?

* brian: Without it, the client must know the server's main hash
  algorithm and the mapping from object IDs in that algorithm to
  content.

* Martin Fick: I would like push v2 for automated replication, where a
  forge pushes to mirrors. Gerrit does this with thousands of targets.
  Ref advertisements are expensive when checking all of them. We need a
  way to know whether an advertisement differs from ours, so we can skip
  targets that are already up to date.

* Emily: Push negotiation?

* Martin Fick: The ref advertisement happens before negotiation.

* Peff: You want an answer in tens of bytes rather than thousands. A
  checksum could provide a small initial step.

* brian: With reftable, generation numbers make this easy.

* Martin Fick: That might work for this case, but assumes the
  repositories are in lockstep and covers fewer cases than a full
  protocol change.

* Peff: Would the rest of the push not fix it?

* Martin Fick: Parallelism makes that assumption harder.

* Peff: We discussed an ETag-style approach with reftable at GitHub
  years ago. It would be useful to see an implementation, and it could
  fit as an option in the existing protocol.

* Martin Fick: The server could also send a diff or a leaner pack.

* [Caching was also mentioned.]

* Patrick: Should we shrink the advertisement format?

* Peff: Perhaps compress it with zlib.

* Patrick: Let us explore options and benchmark them. We need v2 on the
  push side. We also proposed sending reftable directly.

* Martin Fick: A reftable could contain extra information.

* Patrick: A compressed format may be simpler.

* brian: We also do not want to send hidden refs.

* Patrick: I mean using the reftable format, rather than sending the
  whole reftable.