{"thread":{"id":"66477","subject":"Notes from the Git Contributor's Summit, 2026","startedAt":"2026-10-06T18:05:36Z","lastAt":"2026-10-07T17:38:11Z","messageCount":10,"participants":["Taylor Blau","Todd Zullinger","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"554314","messageId":"summit-2026.94e33e9ddf234334.00@ttaylorr.com","threadId":"66477","inReplyTo":null,"subject":"Notes from the Git Contributor's Summit, 2026","fromName":"Taylor Blau","fromEmail":"ttaylorr@openai.com","sentAt":"2026-10-06T18:05:36Z","receivedAt":"2026-10-06T18:05:36Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Thanks to everybody who participated in this year's Contributor's\nSummit, and to the folks who took notes during the discussions.\n\nI'm sharing the notes here so that people who could not attend can catch\nup, and so we can continue the discussions on the list. The shared notes\nare also in Google Docs:\n\n  https://docs.google.com/document/d/15gDNTjCh9-aQ1ES2MDot5_Qnxj6vRMGwxbH7eixxT84/edit\n\nThe topics covered in the replies below are:\n\n - Security mailing list and security process\n - Git 3.0\n - Documentation\n - Outreachy sponsorship\n - What can we do next with pluggable ODB?\n - AI contribution policy\n - Protocol v2 for pushes\n\nI've lightly edited the notes for readability and kept the speaker\nattributions. These are discussion notes, rather than a verbatim\ntranscript; please reply with corrections or anything the notes missed.\nRelease dates and reports of work in progress reflect the discussion at\nthe summit.\n\nEach topic has its own reply to this message so that follow-up\ndiscussion can stay with the relevant notes.\n\nIf you have feedback about the summit itself, please share it here or\nwith me off-list.\n\nThanks,\nTaylor\n\n"},{"id":"554315","messageId":"summit-2026.94e33e9ddf234334.01@ttaylorr.com","threadId":"66477","inReplyTo":"summit-2026.94e33e9ddf234334.00@ttaylorr.com","subject":"[NOTES 01/07] Security mailing list and security process","fromName":"Taylor Blau","fromEmail":"ttaylorr@openai.com","sentAt":"2026-10-06T18:06:12Z","receivedAt":"2026-10-06T18:06:12Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Topic: Security mailing list and security process\nLeader: Toon Claes\nNotetaker: Peff\n\n* Toon: We have a high influx of reports on the security list from\n  outside the community, probably from people using AI. There are many\n  unaddressed reports. We need a better process for addressing them, and\n  to figure out who will do the work.\n\n* Emily: How are we cutting security releases now? Are we waiting for\n  the reports to stop before cutting a release?\n\n* Taylor: There are many reports we still need to triage and determine\n  which are important.\n\n* Toon: I have been organizing the reports, and some patches have been\n  sitting around for months.\n\n* Patrick: Eventually we have to cut a release, because the influx will\n  not stop.\n\n* Peff: We should act on what we have triaged once we have enough for a\n  release.\n\n* Patrick: We get many duplicate reports from AI findings. We should be\n  more willing to cut releases, with a well-defined timeline. We should\n  document the process, perhaps in terms of a number of weeks after a\n  report.\n\n* Peff: I am hesitant to promise a response to reports within a fixed\n  number of weeks.\n\n* Patrick: We should try to rely on companies investing in fixes,\n  without forcing volunteers to work on them.\n\n* brian: We should document our security model. Many reports are not\n  vulnerabilities, but explaining why takes work.\n\n* Patrick: Documenting the model might also help AI tools respect it.\n\n* Emily: Are we interested in following the Linux kernel's approach of\n  not embargoing AI-found vulnerabilities?\n\n* Patrick: I am worried about that because of vulnerabilities affecting\n  forges.\n\n* Taylor: It depends on the models; some are better than others.\n\n* Patrick: We should fix non-security issues on the public mailing list,\n  and be more proactive about moving reports there when nobody else\n  replies.\n\n* brian: Sometimes there is pushback about whether something is a\n  vulnerability.\n\n* Patrick: There should probably be a period after which it is assumed\n  that a report can go public.\n\n* Patrick: GitLab has put some resources into this, but I would like to\n  see more from other companies.\n\n* Emily: It has been difficult to get resources from companies. The\n  response is often that AI could help with triage, but putting\n  non-public knowledge into public AI systems feels risky.\n\n* Taylor: We could consider using AI to help with triage and writing\n  patches. It might be easier to get companies to sponsor the work if it\n  is less arduous.\n\n* brian: There are DCO questions, which I would like to leave for the AI\n  discussion. At GitHub, Elijah is our only person in git-contrib. There\n  is more work than we have staff for, and corporate email requirements\n  make list work difficult.\n\n* Peff: We can coordinate in the cabal repository.\n\n* Patrick: Could we put money into a fund to pay somebody to work on\n  security, perhaps using AI, and get ahead of the findings?\n\n* Martin: The project has a bucket of money.\n\n* Taylor: I do not have the exact figure, but probably around $100k.\n  Would we hire a third party, or somebody from one of the companies?\n\n* Patrick: We probably need somebody from the project.\n\n* Emily: Why is there resistance to hiring a third party?\n\n* Peff: I am skeptical because the onboarding cost and time might be\n  substantial.\n\n* Emily: There are contracting firms suited to open source. We have been\n  happy with Collabora, and I am happy to explore similar options,\n  though it costs a bit more.\n\n* Adrian: Such projects are hard to pitch internally. We do address\n  security issues in other projects, but at a normal rate of $200/hour,\n  a $100k project is difficult to pitch.\n\n* Peff: Toon has already made a list, and we have fixes. Can we make a\n  release with what we have? The list may not be as long as we think.\n\n* Patrick: Can we write down the process, and perhaps automate it?\n\n* Taylor: It is not primarily a scripting issue. We need to assemble the\n  required tags and have the confidence to say we have enough to cut a\n  release. We should discuss it on the list. The list of reports is long\n  enough that we may never get through all of it.\n\n* Patrick: We should get more comfortable with faster releases.\n\n* brian: Anyone should be able to propose a new release.\n\n* Patrick: We can try to accommodate different release schedules, but\n  eventually we should put our foot down.\n\n* Taylor: Microsoft needs around seven weeks for a release.\n\n* brian: Microsoft needs to provide staffing if it wants a particular\n  schedule.\n\n* Taylor: Does anybody object to telling Microsoft that we will not\n  follow its schedule?\n\n* [No objections recorded.]\n\n* Patrick: Agreed. Who wants to tell them?\n\n* Taylor: I do not want to make an ultimatum about adding resources.\n  They might add a third party that does not work well with us and still\n  stick with Patch Tuesday.\n\n* Peff: I had hoped to goad Toon into handling a release.\n\n* Toon: OK, but I mostly do not know how.\n\n* Patrick: That is a general problem: the process is not documented, and\n  we need to figure it out.\n\n* Peff: I will see if I can dig up the resources I remember. Is it OK to\n  discuss the process on the public list?\n\n* [General agreement that discussion on the public list is OK.]\n\n* Peff: I will write an email to the public list to start the process\n  discussion.\n\n* Taylor: Johannes, Junio, and I should contribute our experience.\n\n* Patrick: Would scripting make it easier?\n\n* Taylor: No, it is the work of merging fixes up through the versions.\n\n* Junio: Fixes do not always apply to both old and new code.\n\n* Peff: There is also the work of writing security advisories and\n  obtaining CVEs.\n\n"},{"id":"554316","messageId":"summit-2026.94e33e9ddf234334.02@ttaylorr.com","threadId":"66477","inReplyTo":"summit-2026.94e33e9ddf234334.00@ttaylorr.com","subject":"[NOTES 02/07] Git 3.0","fromName":"Taylor Blau","fromEmail":"ttaylorr@openai.com","sentAt":"2026-10-06T18:06:17Z","receivedAt":"2026-10-06T18:06:17Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Topic: Git 3.0\nLeader: Patrick Steinhardt\nNotetaker: Justin\n\n* Patrick: The blocker was GitHub not having SHA-256 support. When will\n  GitHub fully support it?\n\n* brian: GitHub has shipped it experimentally, with general availability\n  probably in November.\n\n* Patrick: GitLab already has public, non-experimental support. We are\n  looking at spring next year for Git 3.0. libgit2 has support; JGit\n  does not.\n\n* Emily: Google will not fund SHA-256 support in JGit.\n\n* brian: It does not look like Bitbucket will support it.\n\n* Emily: Gitoxide may have funding for SHA-256 support.\n\n* brian: There will be a couple more releases: 2.56, then 2.9x, and so\n  on.\n\n* Taylor: We could use 2.99 and then 2.999 if needed.\n\n* Patrick: 2.99 would be a stronger signal than 2.95.\n\n* Peff: Why might users not want to jump to 3.0? Rust support will be\n  mandatory.\n\n* Patrick: A possible schedule is 2.56 in September 2026, 2.98 in\n  December 2026, and 2.99 and 3.0 in March 2027. We need to find out\n  whether anybody is interested in an LTS release.\n\n* brian: Gentoo would be interested in a 2.99 LTS release.\n\n* Patrick: We could potentially cut out one of the releases.\n\n* Peff: We could make one of the cycles shorter.\n\n* Taylor: The 3.0 release could be small, containing only the changes to\n  the defaults.\n\n* Patrick: The counterargument is that we want to use 2.99 as a signal.\n\n* Peff: We should release 2.99.1 and 3.0 at the same time, with only the\n  BREAKING_CHANGES defaults flipped in 3.0.\n\n* [Consensus among the attendees.]\n\n* brian: Are there any objections to Rust in 3.0?\n\n* [No objections recorded.]\n\n* Peff: Are there timing concerns around distribution release cycles? We\n  might want to synchronize with them.\n\n* brian: If we do 2.99 and 3.0 back to back, that puts us in the April\n  timeframe.\n\n* Patrick: Do we want to drop 2.57?\n\n* [The notes record dropping 2.57 in favor of an earlier 2.98.]\n\n* Peff: GitHub might encounter bugs once users start using SHA-256.\n  Would we see similar bugs in Git?\n\n* brian: Codeberg exposes this in its UI, and has a decent number of\n  users.\n\n* Patrick: GitLab has test suites covering this, and we have upstreamed\n  a few fixes. I am confident there are very few bugs.\n\n* Patrick: Should we migrate?\n\n* Taylor: I may be a little behind on the interoperability work. Would\n  it also handle historical tags?\n\n* brian: Yes. The work is done, but not on the list. You can clone a\n  normal SHA-1 repository and get interoperability with SHA-256.\n\n"},{"id":"554317","messageId":"summit-2026.94e33e9ddf234334.03@ttaylorr.com","threadId":"66477","inReplyTo":"summit-2026.94e33e9ddf234334.00@ttaylorr.com","subject":"[NOTES 03/07] Documentation","fromName":"Taylor Blau","fromEmail":"ttaylorr@openai.com","sentAt":"2026-10-06T18:06:21Z","receivedAt":"2026-10-06T18:06:21Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Topic: Documentation\n\n* Julia: There is a big gap between contributors who know Git's concepts\n  and users who do not know what objects or the index are. I have been\n  working on a website to bridge that gap. We do not explain some basic\n  terms, such as \"upstream\". Some documentation receives hundreds of\n  comments. How can we bring that feedback to the mailing list without\n  overwhelming it, and improve the documentation with very little\n  funding?\n\n* Patrick: Could we expand the funding? This work is important, and we\n  are not technical writers.\n\n* brian: We have gitglossary and the Pro Git book, but it would be good\n  to have beginner documentation. Many users arrive from university\n  without knowing these concepts. I have submitted some documentation in\n  this area.\n\n* Patrick: Pro Git may be outdated in places. Scott wants a new version\n  and could fund somebody to work on it.\n\n* Emily: We can suggest a huge book to somebody who is new and just\n  wants to use Git.\n\n* Peff: The manpages are reference material, so they should be terse.\n  Most users also need something less terse. If somebody is interested\n  in working on this, we should consider replacing outdated\n  documentation rather than preserving it for its own sake.\n\n* Patrick: We should allow iterative work. Review can be nitpicky, but\n  perhaps we can be more accommodating so this can move faster.\n\n* Julia: Being able to merge quickly and iterate would help.\n  Mailing-list feedback is useful.\n\n* brian: Thank you for working on the documentation. Bad documentation,\n  or no documentation, makes software hard to use.\n\n* Patrick: Terse does not necessarily mean accessible. We could learn\n  from TLDR and include examples.\n\n* Julia: Examples are useful, and we should update the existing ones.\n\n* Josh: We could consider Diataxis, which separates tutorials, guides,\n  explanations, and reference material:\n  https://diataxis.fr/\n\n* Julia: The format of the reference manpages makes sense.\n\n* Peff: I did not mean to defend the manpages. New-user documentation\n  and manpages are two separate things, and both need work.\n\n* Julia: Git has guides and manpages, which is a useful separation. The\n  guides are harder to discover; the manpages are more accessible.\n\n* Patrick: How much time do you have funding for?\n\n* Julia: We have 100 hours split between two people.\n\n* Patrick and others: Perhaps we could use the Git fund.\n\n* Peff: Other companies might also be interested in funding the work.\n\n* [OpenAI, GitHub, and GitButler were mentioned as possibilities.]\n\n* brian / Emily / Mark: We can ask about funding.\n\n* Mark: We have both machine-readable and human-readable material.\n\n* Toon: We are only discussing written documentation.\n\n* Peff: Costs can escalate with video. I am biased toward written\n  documentation.\n\n* Patrick: GitButler has resources, and younger users may prefer videos.\n\n* Julia: We could link good Git videos from the website.\n\n* Emily: There are links on Discord that we could include.\n\n* Julia: We do not have a good entry point on the Git website explaining\n  how to learn Git.\n\n* Peff: The site had one, but it gets outdated. We should refresh it as\n  we go.\n\n* Julia: Some documentation says \"see section XYZ\" without linking it.\n  We cannot link to subsections of manpages.\n\n* Peff: I spent some time generating subsection links.\n\n* Julia: We have links to other pages, but not to subsections.\n\n* Peff: References in the text need the linkgit markup. This could be an\n  incremental project.\n\n* Julia: I added a cheatsheet to the website. Do we want to move away\n  from ASCII diagrams?\n\n* Patrick: Could we use different sources for different outputs, with\n  SVG for HTML and ASCII for manpages?\n\n* brian: We could do that.\n\n* Patrick: Perhaps Mermaid would let us keep a plain-text source and\n  choose the output format.\n\n* Julia: It should be possible. We have CI scripts that Johannes worked\n  on, and we used Graphviz.\n\n* brian: There are extensions, but they are not packaged for\n  distributions.\n\n* Peff: We support both AsciiDoc and Asciidoctor. Would it help to get\n  out of that dual world?\n\n* Patrick: Traditionally this was for migration. AsciiDoc was thought to\n  be unmaintained, but it is maintained now.\n\n* Peff: We could move to Asciidoctor.\n\n* brian: Fedora still uses AsciiDoc. Asciidoctor is well maintained,\n  written in Ruby, and reasonably portable. It depends on how much we\n  want to support. I do not know whether Fedora is still an obstacle.\n\n* Peff: Who would object to moving, and how strongly?\n\n* Junio: We could include it in Git 3.0 and add it to BreakingChanges.\n\n* Josh: Some documentation already renders poorly with old versions of\n  AsciiDoc.\n\n* Peff: Send those bugs to the list; somebody may be interested in\n  fixing them.\n\n* Josh: We could use this to fix the build pipeline and move away from\n  AsciiDoc.\n\n* Patrick: Fedora does have Asciidoctor, version 2.0.26.\n\n* Peff: I tried Asciidoctor on Debian, and it works well. There are some\n  rendering issues, though it mostly gets things right. Julia, would you\n  be interested in using doc-diff to compare the outputs?\n\n* [Patrick created an issue during the discussion.]\n\n* Emily: Do we have traffic metrics for git-scm.com?\n\n* Taylor: Some high-level metrics in Cloudflare.\n\n* Peff: We had Google Analytics, but were not comfortable with it and\n  removed it.\n\n* Emily: It would be useful to know how many users read the\n  documentation.\n\n* brian: It would be useful to know which manpages people read, while\n  being mindful of privacy as an open-source project.\n\n* Taylor: Could we self-host metrics, or use a third party that supports\n  this?\n\n* Mark: Fathom is one privacy-focused option:\n  https://usefathom.com/\n\n* brian: Even webserver logs would be useful for getting some numbers.\n\n* Peff: On Heroku, the caching layer meant we did not see accurate\n  numbers.\n\n* Patrick: Will AI scrapers drown out the useful signal?\n\n* Toon: I opened an issue about this some time ago:\n  https://github.com/git/git-scm.com/issues/2054\n\n* Taylor: We enabled it, but did not see useful information.\n\n"},{"id":"554318","messageId":"summit-2026.94e33e9ddf234334.04@ttaylorr.com","threadId":"66477","inReplyTo":"summit-2026.94e33e9ddf234334.00@ttaylorr.com","subject":"[NOTES 04/07] Outreachy sponsorship","fromName":"Taylor Blau","fromEmail":"ttaylorr@openai.com","sentAt":"2026-10-06T18:06:27Z","receivedAt":"2026-10-06T18:06:27Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Topic: Outreachy sponsorship\n\n* Chris: We want three interns, at $10k per intern. Are any companies\n  interested in helping? The session starts in early December. GitLab or\n  GitHub sponsored this in the past, but as of last year neither wanted\n  to, so Git has had to pay.\n\n* Patrick: Talk to GitLab's contributor success person.\n\n* Elijah: We need to identify the right person to ask.\n\n* Emily: I can ask Google's OSPO whether there is interest, though I am\n  not expecting much.\n\nGit Merge 2027:\n\n* [There was some interest in holding Git Merge in Canada, given the\n  political climate.]\n\n* [Announcing the location early would help Outreachy and GSoC interns\n  who want to attend.]\n\n"},{"id":"554319","messageId":"summit-2026.94e33e9ddf234334.05@ttaylorr.com","threadId":"66477","inReplyTo":"summit-2026.94e33e9ddf234334.00@ttaylorr.com","subject":"[NOTES 05/07] What can we do next with pluggable ODB?","fromName":"Taylor Blau","fromEmail":"ttaylorr@openai.com","sentAt":"2026-10-06T18:06:31Z","receivedAt":"2026-10-06T18:06:31Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Topic: What can we do next with pluggable ODB?\n\n* Emily: We saw this working in Patrick's talk. What do we want to do\n  with it next?\n\n* Patrick: Most things work, but we are not all the way there yet;\n  commit-graph and MIDX are examples. The plan is to add a repository\n  extension in 2.57.\n\n* Peff: From the Mercurial talk, you can convince Git to make good\n  deltas, but doing so has a cost. I do not think the ODB API is at a\n  level where deltas can be created on the fly.\n\n* Patrick: I think we can do that. They have information we do not have.\n  Renames are tricky.\n\n* Peff: The ODB does not know anything beyond the content. Could we give\n  it more information?\n\n* Patrick: We may want to evolve this based on the representation. We\n  could pass a `struct commit *` into the ODB API instead of just\n  content.\n\n* Peff: What we have now is a reasonable stopgap.\n\n* Patrick: Content-defined chunking is another possibility.\n\n* Taylor: Would that be at the object layer, or a property of a\n  particular ODB store implementation?\n\n* Patrick: I would like to do it natively, but that seems like a large\n  change.\n\n* brian: It could be part of a new pack/index format. I am very much in\n  favor of content-defined chunking.\n\n* Peff: There is a logical object model. Would this be a new object\n  type, where a chunked object and a blob have different hashes, or\n  something below that?\n\n* Patrick: We could start at the storage layer and eventually move it to\n  the object layer.\n\n* Taylor: Perhaps, but perhaps not. This may be easier than we are\n  thinking.\n\n* Patrick: Moving the ecosystem may be difficult.\n\n* brian: We could have a compatibility fallback.\n\n* Peff: Then we would have two equivalent representations of an object\n  which do not hash to the same thing.\n\n* brian: We could introduce a pack-only object type.\n\n* Peff: Which OID would I refer to?\n\n* brian: The blob's OID.\n\n* Taylor: That is analogous to REF_DELTA and OFS_DELTA: multiple\n  representations of the same thing.\n\n* brian: We would need a format extension, because we are out of bits.\n\n* Patrick: Would we still want to put it in a pack?\n\n* brian: Yes.\n\n* Patrick: Start with the storage layer, then see where it goes.\n\n* Patrick: Would this only be for blobs?\n\n* Taylor: Is \"chunked\" a refinement of a blob, or an attribute\n  independent of object type?\n\n* brian: Trees are not currently binary-searchable. It would be nice to\n  fix that too.\n\n* Patrick: Perhaps reftable could provide inspiration there.\n\n* Emily: After Patrick's talk, my skip-level manager asked whether we\n  could build a commit cloud with Git. What else could we do that is\n  totally wild?\n\n"},{"id":"554320","messageId":"summit-2026.94e33e9ddf234334.06@ttaylorr.com","threadId":"66477","inReplyTo":"summit-2026.94e33e9ddf234334.00@ttaylorr.com","subject":"[NOTES 06/07] AI contribution policy","fromName":"Taylor Blau","fromEmail":"ttaylorr@openai.com","sentAt":"2026-10-06T18:06:35Z","receivedAt":"2026-10-06T18:06:35Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Topic: AI contribution policy\n\n* Josh: What is the current AI policy?\n\n* Elijah: [Reading from SubmittingPatches.] The DCO requires\n  contributors to certify their contributions, and it is not clear\n  whether they can do that for AI-generated output.\n\n* Taylor: If we take AI out of the picture, is any of that inconsistent\n  with how we already treat patches?\n\n* brian: It often has a distinct character. It may get better, but\n  currently it can be noticeable and awkward to read.\n\n* Elijah: It is often useful for proofreading and improving writing.\n\n* Emily: One thing missing from the policy is attribution. Johannes sent\n  something with an Assisted-by trailer, which helps us understand\n  whether and how a tool was used.\n\n* Taylor: Would I review Johannes's patches differently if I knew AI was\n  used?\n\n* Emily: It is different for new contributors and people with whom we\n  have established trust.\n\n* Patrick: Sometimes knowing helps us avoid reading complete garbage.\n\n* Emily: Having the policy in SubmittingPatches helps because people and\n  agents will read it.\n\n* brian: Many people do not read SubmittingPatches often, but honesty\n  about where code came from is useful. Using AI for language cleanup is\n  useful too.\n\n* Taylor: The policy effectively says we cannot do anything significant\n  with these tools.\n\n* Peff: We are seeing more contributions where an agent makes the\n  changes and a person acts as a \"meat proxy\".\n\n* Emily: Those proxies are getting thinner.\n\n* brian: The Linux kernel requires people to state that they have\n  authority to submit the code.\n\n* Peff: What is the rest of the open-source world doing? Are we missing\n  useful tools by being conservative?\n\n* brian: Some people will no longer trust us if we accept AI-generated\n  code.\n\n* Taylor: The Linux kernel is much more permissive than we are.\n\n* Peff: We imagine that we will be sued, while the rest of the world\n  does not seem to.\n\n* Patrick: Opening the policy further would open the door to an even\n  greater influx of contributions.\n\n* Emily: That is why I want more attribution.\n\n* brian: When I contribute to open source, I am attributed as the\n  author. With AI-written code, I am implicitly using other people's\n  code.\n\n* Taylor: When I read code from a project with a license incompatible\n  with Git's, I learn from it, and that knowledge may implicitly\n  influence my work on Git.\n\n* brian: That is a coherent position, but not everybody agrees. The\n  project has to decide.\n\n* Emily: Have we used a voting process for something like this before?\n\n* Patrick: We need proposals and a vote. Who would be allowed to vote?\n\n* Peff: Active developers with a track record; perhaps a threshold such\n  as 50 merged patches.\n\n* Taylor: We asked the SFC lawyers, and the result is what is in\n  SubmittingPatches.\n\n* brian: SFC is very American in its legal approach.\n\n* Peff: We should give SFC more credit; it is more worldwide than that.\n\n* Emily: This was a problem with GSoC. There was a record amount of\n  contributions, but the quality was poor.\n\n* Peff: We need to agree on a policy. Do we accept AI at all, and to\n  what degree?\n\n* Taylor: One possibility is a process similar to Debian's, with\n  proposals and voting.\n\n* Patrick: We need to follow legal counsel, and we do not need to use\n  the same proposals as Debian.\n\n* Peff: We got legal advice on the current text. We should work out the\n  voting options, take them through SFC counsel, communicate the risks\n  and concerns, and then hold the vote.\n\n* Emily: I am happy to set this up. I have been doing something similar\n  with Jujutsu.\n\n* Peff: We depend on Junio. If people disagree with the policy, they\n  could fork into Git-AI.\n\n* Josh: Let a few key people put forward their opinions and see how much\n  they differ.\n\n* Patrick: Let us do that on the mailing list.\n\n* Peff: brian, would you champion one position?\n\n* brian: Sure. I will take some things from the Debian project.\n\n* Peff: Taylor, would you put forward another position?\n\n* Taylor: Sure, though I am not yet sure what it would be.\n\n* Patrick: Then we need to decide what the vote would be.\n\n* Martin: If there is a vote, how would the result be enforced?\n\n* Peff: Junio is the source of authority, and usually follows the crowd.\n\n* Peff: Emily, are you leading the voting procedure?\n\n* Emily: Yes.\n\n"},{"id":"554321","messageId":"summit-2026.94e33e9ddf234334.07@ttaylorr.com","threadId":"66477","inReplyTo":"summit-2026.94e33e9ddf234334.00@ttaylorr.com","subject":"[NOTES 07/07] Protocol v2 for pushes","fromName":"Taylor Blau","fromEmail":"ttaylorr@openai.com","sentAt":"2026-10-06T18:06:38Z","receivedAt":"2026-10-06T18:06:38Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Topic: Protocol v2 for pushes\nNotetaker: Emily\n\n* brian: Some customers have millions of refs. Reftable has helped us\n  push up to 100k at a time, which was a big increase. AI means more\n  branches and refs, so the problem keeps getting worse. One customer\n  was unhappy about an 896 MB ref advertisement. Protocol v2 for pushes\n  would help. Much of the code already exists and needs wiring up.\n\n* Peff: We were waiting for somebody with a use case they care about.\n  Protocol v2 has a capability advertisement that leaves room for\n  further extensions.\n\n* Elijah: With fetch v2, it would be useful to request only a handful of\n  heads rather than advertise all refs and tags.\n\n* Jonathan Tan: We have prefix filtering for fetch v2. A client can\n  request refs/heads/somename, and the server sends refs matching that\n  prefix.\n\n* Peff: The client needs a better refspec, and the user interface is\n  hard. How do we specify the mainline? Even excluding HEAD can speed\n  things up. This is an optimization; a push is correct as long as the\n  objects are reachable.\n\n* Peff: Could we use multiple passes, trying a smaller set and falling\n  back to a larger one if some objects are still unreachable? Many\n  advertised refs are not useful, such as abandoned development\n  branches.\n\n* [There was a related discussion about showing fewer refs in GitHub's\n  UI.]\n\n* Peff: Could a server-side configuration limit the advertisement and UI\n  to a smaller set of refs, with the client ignoring the others?\n\n* brian: It is useful to control what the client requests. During a\n  push, we want to say that we care about only a handful of branches.\n\n* Peff: That still sounds like a refspec problem; the default asks for\n  too much.\n\n* Jonathan Tan: This is push, though.\n\n* Peff: The client could suggest useful branches more intelligently.\n  Guessing the main branches is a heuristic, but upstream tracking\n  branches might be useful.\n\n* brian: A project setup script, perhaps linked from its documentation,\n  could provide useful initial configuration.\n\n* Jonathan Tan: Instead of a ref advertisement during push, it would be\n  useful to negotiate. Restricting the advertised refs may cause the\n  client to send everything if the optimization does not work. Relying\n  on the remote to know what matters is error-prone. We would be happier\n  with a few round trips: advertise capabilities, exchange haves and\n  acknowledgments, negotiate the push, and send the pack.\n\n* Elijah: During a repack, the server might give a false negative. This\n  may be relevant to shallow clones.\n\n* Peff: We could race and miss a common commit, then be unable to look\n  further back because the client is shallow.\n\n* Elijah: Geometric repacking may help because it is less likely to miss\n  something. A push to the wrong place should fail quickly. Let us leave\n  shallow clones to develop their own story.\n\n* Peff: Successful negotiation could also make connectivity checks\n  easier. We could cache information in receive-pack and pass it to\n  check-connected.\n\n* brian: Shallow clones can spend much more time trying to minimize the\n  wire transfer. One push went from two seconds to 35 seconds because of\n  that optimization. `objects-edge-aggressive` is relevant here.\n\n* Jonathan Tan: We might get substantial savings from simply disabling\n  ref advertisements with a configuration option.\n\n* Peff: Even without a protocol change, the server could decide which\n  refs are interesting and limit its advertisement. That might be easier\n  than introducing v2 for pushes.\n\n* Jonathan Tan: The client needs to tell the server that it wants to\n  negotiate.\n\n* Peff: It might not need to negotiate.\n\n* Jonathan Tan: Would that not be bad?\n\n* Peff: In practice the drawback may be small, though completely\n  unrelated histories would be a bad case.\n\n* Elijah: That can happen when appending a shallow commit.\n\n* brian: I have seen that happen too.\n\n* Peff: In that degenerate case, do these optimizations already have\n  problems?\n\n* Jonathan Tan: Negotiation does not have as much trouble because it\n  starts at the tip the client is pushing.\n\n* [General agreement that putting unrelated histories into one\n  repository is best avoided.]\n\n* Peff: Nobody objects to push v2. We have the hooks and the fetch-v2\n  infrastructure. There may be an easier place to start, though.\n\n* brian: Another benefit of push v2 is interoperability. Currently a\n  client must push using the server's hash algorithm; it cannot\n  negotiate a different one. Fetch can do some negotiation.\n\n* Peff: If v2 makes interoperability easier, go for it.\n\n* Emily: What is the failure mode?\n\n* brian: Without it, the client must know the server's main hash\n  algorithm and the mapping from object IDs in that algorithm to\n  content.\n\n* Martin Fick: I would like push v2 for automated replication, where a\n  forge pushes to mirrors. Gerrit does this with thousands of targets.\n  Ref advertisements are expensive when checking all of them. We need a\n  way to know whether an advertisement differs from ours, so we can skip\n  targets that are already up to date.\n\n* Emily: Push negotiation?\n\n* Martin Fick: The ref advertisement happens before negotiation.\n\n* Peff: You want an answer in tens of bytes rather than thousands. A\n  checksum could provide a small initial step.\n\n* brian: With reftable, generation numbers make this easy.\n\n* Martin Fick: That might work for this case, but assumes the\n  repositories are in lockstep and covers fewer cases than a full\n  protocol change.\n\n* Peff: Would the rest of the push not fix it?\n\n* Martin Fick: Parallelism makes that assumption harder.\n\n* Peff: We discussed an ETag-style approach with reftable at GitHub\n  years ago. It would be useful to see an implementation, and it could\n  fit as an option in the existing protocol.\n\n* Martin Fick: The server could also send a diff or a leaner pack.\n\n* [Caching was also mentioned.]\n\n* Patrick: Should we shrink the advertisement format?\n\n* Peff: Perhaps compress it with zlib.\n\n* Patrick: Let us explore options and benchmark them. We need v2 on the\n  push side. We also proposed sending reftable directly.\n\n* Martin Fick: A reftable could contain extra information.\n\n* Patrick: A compressed format may be simpler.\n\n* brian: We also do not want to send hidden refs.\n\n* Patrick: I mean using the reftable format, rather than sending the\n  whole reftable.\n\n"},{"id":"554347","messageId":"20261007044944.PjN-Ln9E@teonanacatl.net","threadId":"66477","inReplyTo":"summit-2026.94e33e9ddf234334.03@ttaylorr.com","subject":"Re: [NOTES 03/07] Documentation","fromName":"Todd Zullinger","fromEmail":"tmz@pobox.com","sentAt":"2026-10-07T04:49:44Z","receivedAt":"2026-10-07T04:49:44Z","isPatch":false,"sender":{"key":"tmz@pobox.com","avatar":"https://avatars.githubusercontent.com/u/806319?v=4"},"body":"Thank you for the nice summaries Taylor.\n\nTaylor Blau wrote:\n> Topic: Documentation\n> * Peff: We support both AsciiDoc and Asciidoctor. Would it help to get\n>   out of that dual world?\n> \n> * Patrick: Traditionally this was for migration. AsciiDoc was thought to\n>   be unmaintained, but it is maintained now.\n> \n> * Peff: We could move to Asciidoctor.\n> \n> * brian: Fedora still uses AsciiDoc. Asciidoctor is well maintained,\n>   written in Ruby, and reasonably portable. It depends on how much we\n>   want to support. I do not know whether Fedora is still an obstacle.\n\nThe Fedora packages have used Asciidoctor by default since\ne942c8d (use Asciidoctor to build documentation when\npossible, 2020-02-25).\n\n    https://src.fedoraproject.org/rpms/git/c/e942c8d\n\nThat hasn't changed since I stopped maintaining the git\npackage, so Fedora hasn't had an issue with a switch to\nAsciidoctor for quite a long time.\n\nCentOS Stream / RHEL uses AsciiDoc (with the odd exception\nof 9).  They _could_ use Asciidoctor relatively easily; it\nis maintained for EPEL already.\n\nBut if Red Hat really dislike requiring Asciidoctor for git\nbuilds in RHEL, they could ship the pre-built docs, as I\nused to do for EL-5 builds due to an unsupported (read:\nancient) AsciiDoc version.\n\nIf we switched to Asciidoctor, it _might_ open the door to\nreplacing the docbook/xmlto dependencies and having\nAsciidoctor directly generate the man pages.\n\nI haven't thought about or looked at that in a long, long\ntime, so I don't know if that would be a worthwhile change\nor not.  I don't recall if we need the XML step for other\noutputs, like info or PDF (neither of which I ever spent\nmuch time trying to build).\n\n-- \nTodd\n\n"},{"id":"554397","messageId":"xmqqqzi18l8c.fsf@gitster.g","threadId":"66477","inReplyTo":"20261007044944.PjN-Ln9E@teonanacatl.net","subject":"Re: [NOTES 03/07] Documentation","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-10-07T17:38:11Z","receivedAt":"2026-10-07T17:38:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Todd Zullinger <tmz@pobox.com> writes:\n\n> But if Red Hat really dislike requiring Asciidoctor for git\n> builds in RHEL, they could ship the pre-built docs, as I\n> used to do for EL-5 builds due to an unsupported (read:\n> ancient) AsciiDoc version.\n\nFYI.\n\nThe prebuilt docs I publish, which I presume is the one you are\nreferring to here, switched to use Asciidoctor in mid 2024.\n\n"}]}