* Re: My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)
2026-09-22 18:44 ` My summary of the Git Contributors' Summit 2026, was " Johannes Schindelin
@ 2026-09-23 11:55 ` Daniele Sassoli
2026-09-24 12:31 ` Johannes Schindelin
2026-09-25 9:53 ` Luca Milanesio
2026-09-23 12:52 ` D. Ben Knoble
` (3 subsequent siblings)
4 siblings, 2 replies; 22+ messages in thread
From: Daniele Sassoli @ 2026-09-23 11:55 UTC (permalink / raw)
To: Johannes Schindelin, Junio C Hamano; +Cc: git
Hi Johannes,
Thanks so much for this summary, I didn't participate at the contributor
summit
as I was leading one of the breakout sessions in the morning and had a
plane to
catch in the afternoon, so I'm very grateful of your summary.
On 22/09/2026 19:44, Johannes Schindelin wrote:
> Hi Junio,
>
> On Tue, 22 Sep 2026, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>>> On Mon, 21 Sep 2026, Junio C Hamano wrote:
>>>
>>>> Git 2.56-rc1 has been tagged. We may merge last-minute fixes before
>>>> the final Git 2.56 release, but otherwise I do not expect any new
>>>> feature topics to be ready before the final, so most of the
>>>> in-flight topics will stay cooking in 'next' until then. As
>>>> discussed at the Git Contributors' Summit, the version after the
>>>> upcoming Git 2.56 will be Git 2.98, scheduled near the end of this
>>>> year.
>>> Would you say that the following is an accurate characterization of the
>>> timeline, so that people who need to plan dependent projects can rely on
>>> it?
>> My outline was deliberately limited up to end of this year as I am
>> hesitant to say beyond that point before the meeting notes are made
>> public.
> I originally wrote this summary of the Git Contributor Summit only for my
> own records, but since you hinted at wanting some meeting notes, figured
> it might be interesting to other people, too. So here goes my distillation
> of the breakout-sessions from this year's Contributors' Summit. Many of
> these ideas still need discussion on the list; proposals below are not
> project-wide decisions.
>
> Security mailing list and process
>
> The security list is seeing a large influx of outside reports, apparently
> often AI-assisted or generated. Duplicates and reports outside Git's
> security model consume triage time, while some patches have waited for
> months. Waiting for an empty queue is not a workable release criterion: we
> need to release the fixes we have, rather than hold them indefinitely
> while more reports arrive. No fixed release cadence or guaranteed response
> time was settled.
>
> Documenting Git's security model would save repeated explanations of what
> does and does not constitute a vulnerability. (Personal note, not
> discussed at the Summit: Stolee had tried to start a conversation about
> Git's security boundary a long time ago, but nobody replied. Maybe the AI
> onslaught will provide enough motivation to get that discussion going.)
> Moving non-security bugs to the public list more readily was also
> encouraged. A timeout after which public discussion would be presumed OK
> was proposed, but not agreed.
>
> More company staffing would help, without turning this into an obligation
> for volunteers. Paying for dedicated help was discussed, with onboarding
> costs a concern. Using AI for triage or fixes raises confidentiality and
> DCO questions of its own. (Personal note: There seemed to be some
> sentiment in the room that contradicted the earlier agreed-on finding on
> the mailing list that using AI for triaging and for investigating wasn't a
> copyright concern and should therefore be considered permissible.)
>
> The release bottleneck is not really tag automation. Merging and
> backporting fixes, preparing advisories, and handling CVEs take work, and
> too much of that knowledge lives in people's heads. Peff volunteered to
> start a public discussion of the process and dig up existing resources.
> (Personal note: I have done that merging, backporting, etc plenty of
> times, and I don't think that it is the bottleneck, and I was rather
> surprised to hear that it is complicated. Sure, there are the expected
> merge conflicts when merging `maint-*` branches, and running -- and
> fixing! -- CI on all of the tags in a private repository should go without
> saying, but that's all craft of the trade. Rather, the indecision and lack
> of engagement on the git-security mailing list is what I see as the
> blocker. I'd happily volunteer to juggle those branch thickets if that was
> truly the make-or-break issue here.)
>
> Microsoft's release process reportedly needs about seven weeks. There were
> no objections in the room to proceeding without waiting for that schedule.
> (Personal note: That release process was misrepresented, which is
> surprising, as I coordinated two or three Git for Windows security bugfix
> releases _on the git-security list_ since the most recent Git security
> bugfix release, it's always the same thing: release on a second Tuesday of
> the month, three weeks before that the patches need to have settled,
> everybody goes home with a dependable timeline. It's not really that big
> of a deal. Testing patches, constructive feedback, these are the things
> that are missing and therefore blocking the process. I sensed a lot of
> finger-pointing in this discussion. I mean, I don't blame anybody for
> avoiding security work: it is stressful and intense. The responsibility
> for getting things wrong is enormous. I know that because I've done my
> share of that, probably more than most in the Git project, and I will do
> even more in the future. But when I don't have the time, or the energy, I
> am aware that I, myself, am the bottleneck; I don't need to blame others.)
>
> Git v3.0
>
> The proposed target is spring 2027: v2.56 in September 2026, v2.98 in
> December, then v2.99 and v3.0 next spring. The jump in version numbers is
> intended to signal the approaching breaking changes. March and April were
> both mentioned; the precise timing is not settled.
>
> There was agreement on releasing v2.99.1 and v3.0 together, differing only
> in the BREAKING_CHANGES (v3.0 switches them on). That keeps the transition
> separate from another round of feature development. Nobody in the room
> objected to Rust becoming mandatory in v3.0. (Personal note: probably
> because Randall wasn't there, to say that NonStop support would be a
> blocker and that Git please wait.) A v2.x LTS remains an open question,
> with Gentoo mentioned as an interested party. (Personal note: I am still
> advocating for an in-tree Long Term Support branch, and since Junio
> indicated that he's less than eager to take care of that, I would love for
> Patrick Steinhardt to be the "LTS lieutenant", I vaguely remember that he
> said he'd do it if asked, and I trust his judgement, so I'd ask.)
>
> SHA-256 support across the ecosystem had been a blocker. GitHub reported
> experimental support, with general availability expected around November.
> GitLab already had public, non-experimental support, and libgit2 supports
> it, too. JGit remains a gap; Google was not planning to fund that work.
>
> The SHA-1/SHA-256 interoperability work, including historical tags, was
> reported to be implemented but not yet sent to the list. (Personal note: I
> think that the room seriously "mis-underestimated" the real-world impact
> of this. The code is not even on the Git mailing list, and the
> ramifications of not having a robust plan how to deal with partial clones
> or submodules or even signed tags strikes me as a dealbreaker. I would not
> be surprised if the decision to enforce SHA-256 as default would have to
> be revisited before v3.0, and possibly overturned.)
>
> Documentation
>
> Julia's work highlights the gap between documentation written by people
> who know Git inside out and users who do not yet know what objects, the
> index, or upstream mean. We need approachable learning material as well as
> reference documentation. Both need work; keeping manpages concise does not
> mean they cannot have better explanations and examples. (Personal note: I
> am beyond excited that Julia, whose work I have always admired, got
> interested in improving Git's documentation, which is in dear need of
> being improved, mainly because it does not cater to the majority of Git
> users out there who are unlikely to wander onto the Git mailing list,
> ever. I just hope that old-timers who really do not need the documentation
> nor understand the need of those who do need it show enough appreciation
> for the fresh views and for Julia's understanding of the target audience.)
>
> Discoverability matters, too. The website (https://git-scm.com/) needs
> clearer entry points for learning Git, and existing guides are harder to
> find than manpages. Missing subsection links are another improvement we
> could make incrementally. (Personal note: Judging by the history of that
> site, I do wonder whether the core Git contributors are interested in
> helping this effort at all. For example, there are a growing number of PRs
> suggesting to add new UIs to the growing list, but I gave up reviewing
> them because I was the only one doing so.)
>
> There was support for replacing outdated material and for merging useful
> improvements, then iterating, rather than trying to perfect everything
> before it lands. Bringing user feedback to the list without flooding it
> remains a challenge.
>
> The current funding covers only 100 hours split between two people.
> Additional project and company funding was encouraged; brian, Emily, and
> Mark offered to explore company support. (Personal note: I had tried, back
> when GitHub still funded my team, to start something like that, without
> any success. To the contrary, even Git for Windows and Git Credential
> Manager got defunded.)
>
> On the tooling side, using only Asciidoctor instead of maintaining both
> AsciiDoc and Asciidoctor support was proposed as a possible Git v3.0
> change. Distribution support and rendering differences need checking, with
> doc-diff suggested for comparing the outputs. Patrick filed an issue
> during the discussion. (Personal note: AFAIU the AsciiDoc spec is now
> maintained by Asciidoctor, and I am aware already of one change that was
> made to the spec without adapting AsciiDoc accordingly. So the entire
> discussion might be quite moot already.)
>
> Other ideas included richer diagrams for HTML while retaining text
> versions for manpages, and privacy-respecting traffic measurements to help
> prioritize documentation work. No diagram format was chosen, and caching
> and AI scraping complicate getting useful traffic data. Mermaid was
> proposed, and even GraphViz. (Personal note: I added support for Mermaid
> diagrams to https://git-scm.com/, but it turned out to be too limited, so
> I added GraphViz support. The support code for this is a bit of a beast,
> having a wasm version of GraphViz for development, pre-rendering the
> diagrams as SVG and as PDF during deployment of the site; it was quite a
> bit of fun to implement all that.)
>
> Outreachy sponsoring
>
> The goal is to support three interns in the round starting in early
> December, at $10,000 each. The corporate sponsorship previously provided
> by GitLab and GitHub has dried up, leaving Git itself to pay. There are
> company contacts to follow up with; Emily offered to ask Google's OSPO,
> without high expectations. No new sponsorship commitments were made.
> (Personal note: I don't think that these internships provide enough
> publicity to give companies much of an incentive to fund this. Which I
> find a bit of a shame, Outreachy in particular does a lot of important,
> good work, and if I wasn't so constantly overworked, I would want to
> mentor again; I always found it rewarding, even if I hold myself to a
> quite high bar which is quite draining.)
>
> A related point for Git Merge 2027: announcing the location early would
> help Outreachy and GSoC interns plan attendance. No location was selected.
>
> Pluggable object database
>
> Patrick's pluggable object database is working, but it is not complete:
> commit-graph and multi-pack-index integration are still outstanding, and a
> repository extension is planned. (Personal note: It might be interesting
> to see whether implementing a storage backend is easier in core Git or in
> another Git-compatible implementation. JGit should be a natural target,
> having originated within BigTable-sized constraints, i.e. a different
> storage system, but funding seems to have dried up, there's not even
> SHA-256 support, so JGit might not be as hackable as it once was.)
Pluggable backend implementations for JGit have been possible for quite some
time, although, admittedly, I don't think any made it to production.
Maybe at
the time when this was introduced(16 years ago!!) by Shawn[1] in JGit it
wasn't
fashionable yet and so the project was never carried forward. I know Luca
submitted a talk for the Gerrit User Summit to present a Cassandra
back-end, for
which I can see conversation started 10 years ago[2].
Regarding JGit support's for SHA256, I know some corporations have had
interest
in sponsoring this work and have discussed potentially implementing
together it
with GerritForge, but, as far as I know, work isn't ongoing yet. JGit is
still
very much developed and kept up to date with great effort from the
community, so
I believe it to still be as hackable as it was, there just hasn't been
enough
interest for SHA-256 yet, which I agree is a shame, hopefully in the
near future
this gets remediated.
[1] https://github.com/spearce/jgit_cassandra
[2] https://groups.google.com/g/repo-discuss/c/IekVPmow0yE
>
> Content-defined chunking prompted an important distinction between
> changing how objects are stored and changing the logical object model.
> Starting at the storage layer would let us preserve existing blob OIDs
> rather than require ecosystem-wide changes. A new pack/index format could
> provide another representation of the same object, much as deltas do
> today. No particular representation was agreed. (Personal note: It is
> curious to me why nobody tought about inventing a "meta blob", i.e. an
> object much like a tree object, except that it stitches together a larger
> blob. This would allow for the content-defined chunking that `rsync`
> already championed, way before Git was born! It would have allowed a Git
> native large file support worth writing home about, and could have
> replaced Git LFS. Xet (https://huggingface.co/docs/hub/xet/index) would
> not have had to be invented, and it would have allowed game development to
> move to Git. I can only imagine that the time it would cost to get even
> the first patches of this into core Git would be seen as prohibitive by
> any company who may have considered the effort.)
>
> There is also an API question: does a backend seeing only object content
> have enough context to make good storage and delta choices, or should it
> receive richer information? More searchable tree storage and a Git "commit
> cloud" were other possibilities raised, not committed plans. (Personal
> note: At a previous GitMerge, Facebook presented their work, see e.g.
> https://github.com/facebook/sapling/blob/main/eden/mononoke/blobstore/packblob/README.md,
> which includes separating actual storage from transport. That is, already
> at push time, derived metadata is computed in async jobs which provide
> several potential deltas ready-to-go when a client clones or fetches. They
> reported clones with regular Git clients that are twice as fast, just
> because the server doesn't need to spend much compute on the data it
> sends. So there is a lot to be learned out there already.)
>
> AI
>
> The current SubmittingPatches policy is rooted in DCO certification and
> advice from SFC lawyers. The unresolved question is whether, and to what
> extent, contributors can certify AI-generated code. There was substantial
> disagreement about acceptable use, provenance and legal risks, community
> trust, review burden, and whether the current caution excludes useful
> tools. No policy change was agreed. (Personal note: You'd think that the
> opinion of lawyers is taken at face value, but no, it seems that some core
> Git contributors seem to disagree with the lawyers in favor of their own
> opinion...)
>
> Several participants found language and proofreading assistance useful. A
> particular concern was submissions where the human does little more than
> relay agent output, leaving reviewers to deal with the consequences. The
> influx of poor GSoC contributions was one example. Attribution such as
> Assisted-by was suggested to make tool use clearer, but attribution alone
> does not answer the quality or DCO questions. (Personal note: my precedent
> of "Assisted-by" was called out as helpful, and I do think it is. I make a
> difference between AI-generated and AI-assisted. I'm not a fast typer, so
> I benefit a lot from being able to tell an LLM to please refactor out
> these four lines with the appropriate signature. There's not much
> creativity in there. I also like to let AI present me the call graphs for
> certain code locations, because due to the choice of C, which thanks to
> the C preprocessor is not easy to analyze statically, there are no
> competent tools other than LLMs that I can use for the task. I was highly
> surprised, though, to see how much enmity against AI in general was
> voiced, not by many, but many, many times, and how that contrasts with the
> Linux project which I hitherto had not considered to be as particularly
> open to modern practices.)
>
> brian and Taylor agreed to put differing policy proposals on the list. The
> suggested process is to have alternatives examined by SFC counsel, make
> the risks clear, and then consider a vote. Emily volunteered to organize
> the voting procedure. Eligibility and the details remain open; Junio's
> authority as maintainer remains central. (Personal note: Since Taylor
> works for OpenAI now, I was not surprised by his stance, but brian works
> at GitHub, home of GitHub Copilot, and I am not sure how favorable their
> employer would look at their semi-public utterings about AI...)
>
> Protocol v2 for pushes
>
> There are concrete use cases now: repositories with millions of refs,
> including a reported 896 MB ref advertisement. Reftable improves ref
> update throughput, but does not by itself solve the advertisement problem.
> Nobody objected to push protocol v2, and the fetch-v2 infrastructure
> already provides much of the foundation.
>
> The discussion covered advertising fewer refs, letting clients identify
> useful branches, and replacing large advertisements with a few rounds of
> push negotiation. Negotiation results could also help optimize the
> server's connectivity checks. Some improvements might be possible in the
> existing protocol before introducing v2.
>
> We need to measure the tradeoffs rather than assume fewer bytes means
> faster pushes. One example involved a shallow push taking 35 seconds
> instead of two because of work to minimize the transfer. Shallow
> boundaries and unrelated histories complicate the proposed heuristics.
>
> SHA-256 interoperability is another reason to want push v2: the current
> push protocol requires using the server's primary hash algorithm.
> Negotiation could make that more flexible.
>
> Forge replication to thousands of mirrors would benefit from finding out
> cheaply whether refs have changed, rather than downloading full
> advertisements from every target. Checksums, ETag-like values, and
> reftable generation numbers were discussed, with concurrent updates
> complicating the picture.
>
> Compact or compressed advertisements are also worth exploring and
> benchmarking, possibly reusing reftable's format. That does not mean
> sending the server's actual reftable, including hidden refs. There are
> several promising directions here, but no final design yet.
>
> Some breakout sessions were planned, but apparently had to be cut.
>
> Personal notes: I wasn't present for all of the sessions, in the afternoon
> I had other commitments; Therefore these notes (which AI assisted me in
> distilling) came partially from what I dictated and partially from the
> shared Google Document in which a few volunteers gracefully wrote notes. I
> found it challenging to connect as a remote participant. The link to the
> Google Meet, as well as control over the lobby thereof, seems to have been
> restricted to at most a few people, which might have contributed to the
> long waiting time before I was allowed in, and it definitely contributed
> to my comments not reaching the discussion in time to have an impact. I
> would have loved for Junio or the other two brave souls who also
> participated remotedly to have had more "air time". I am still a fan of
> the idea to have more frequent, smaller, virtual Contributor Summits,
> organized by a rotating cast. (Maybe I can get Emily to host the next
> one.) I was very happy that Junio was participating, as he _is_ the
> project lead, and in past Contributor Summits decisions were taken without
> him, which I found odd. Timing was really challenging for him, though, it
> was way past midnight for him. I'm all the more grateful that he
> did participate.
>
> Final remark: This summary is obviously biased. I lightly edited it to
> separate better between my personal views and a hopefully unbiased account
> of what was discussed, and how, and by who. Nevertheless, I am but human.
> As a consequence, I would be delighted if other participants would share
> their summaries, so that my bias can be balanced out.
>
> Ciao,
> Johannes
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)
2026-09-23 11:55 ` Daniele Sassoli
@ 2026-09-24 12:31 ` Johannes Schindelin
2026-09-25 9:53 ` Luca Milanesio
1 sibling, 0 replies; 22+ messages in thread
From: Johannes Schindelin @ 2026-09-24 12:31 UTC (permalink / raw)
To: Daniele Sassoli; +Cc: Junio C Hamano, git
Hi Daniele,
On Wed, 23 Sep 2026, Daniele Sassoli wrote:
> Thanks so much for this summary, I didn't participate at the contributor
> summit as I was leading one of the breakout sessions in the morning and
> had a plane to catch in the afternoon, so I'm very grateful of your
> summary.
I'm glad it was helpful!
> On 22/09/2026 19:44, Johannes Schindelin wrote:
>
> [... snip ...]
> > Pluggable object database
> >
> > Patrick's pluggable object database is working, but it is not
> > complete: commit-graph and multi-pack-index integration are still
> > outstanding, and a repository extension is planned. (Personal note: It
> > might be interesting to see whether implementing a storage backend is
> > easier in core Git or in another Git-compatible implementation. JGit
> > should be a natural target, having originated within BigTable-sized
> > constraints, i.e. a different storage system, but funding seems to
> > have dried up, there's not even SHA-256 support, so JGit might not be
> > as hackable as it once was.)
>
> Pluggable backend implementations for JGit have been possible for quite
> some time, although, admittedly, I don't think any made it to
> production. Maybe at the time when this was introduced(16 years ago!!)
> by Shawn[1] in JGit it wasn't fashionable yet and so the project was
> never carried forward. I know Luca submitted a talk for the Gerrit User
> Summit to present a Cassandra back-end, for which I can see conversation
> started 10 years ago[2].
>
> Regarding JGit support's for SHA256, I know some corporations have had
> interest in sponsoring this work and have discussed potentially
> implementing together it with GerritForge, but, as far as I know, work
> isn't ongoing yet. JGit is still very much developed and kept up to date
> with great effort from the community, so I believe it to still be as
> hackable as it was, there just hasn't been enough interest for SHA-256
> yet, which I agree is a shame, hopefully in the near future this gets
> remediated.
>
> [1] https://github.com/spearce/jgit_cassandra
> [2] https://groups.google.com/g/repo-discuss/c/IekVPmow0yE
I'm glad to hear that JGit isn't stalled, even though I doubt that the
SHA-256 support could be done without any corporate support.
Ciao,
Johannes
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)
2026-09-23 11:55 ` Daniele Sassoli
2026-09-24 12:31 ` Johannes Schindelin
@ 2026-09-25 9:53 ` Luca Milanesio
1 sibling, 0 replies; 22+ messages in thread
From: Luca Milanesio @ 2026-09-25 9:53 UTC (permalink / raw)
To: git
Thanks Johannes for the detailed summary,
See below some additions on the storage backend in JGit below.
> On 23 Sep 2026, at 12:55, Daniele Sassoli <danielesassoli@gmail.com> wrote:
>
> Hi Johannes,
>
> Thanks so much for this summary, I didn't participate at the contributor summit
> as I was leading one of the breakout sessions in the morning and had a plane to
> catch in the afternoon, so I'm very grateful of your summary.
>
> On 22/09/2026 19:44, Johannes Schindelin wrote:
>> Hi Junio,
>>
>> On Tue, 22 Sep 2026, Junio C Hamano wrote:
>>
>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>>
>>>> On Mon, 21 Sep 2026, Junio C Hamano wrote:
>>>>
>>>>> Git 2.56-rc1 has been tagged. We may merge last-minute fixes before
>>>>> the final Git 2.56 release, but otherwise I do not expect any new
>>>>> feature topics to be ready before the final, so most of the
>>>>> in-flight topics will stay cooking in 'next' until then. As
>>>>> discussed at the Git Contributors' Summit, the version after the
>>>>> upcoming Git 2.56 will be Git 2.98, scheduled near the end of this
>>>>> year.
>>>> Would you say that the following is an accurate characterization of the
>>>> timeline, so that people who need to plan dependent projects can rely on
>>>> it?
>>> My outline was deliberately limited up to end of this year as I am
>>> hesitant to say beyond that point before the meeting notes are made
>>> public.
>> I originally wrote this summary of the Git Contributor Summit only for my
>> own records, but since you hinted at wanting some meeting notes, figured
>> it might be interesting to other people, too. So here goes my distillation
>> of the breakout-sessions from this year's Contributors' Summit. Many of
>> these ideas still need discussion on the list; proposals below are not
>> project-wide decisions.
>>
>> Security mailing list and process
>>
>> The security list is seeing a large influx of outside reports, apparently
>> often AI-assisted or generated. Duplicates and reports outside Git's
>> security model consume triage time, while some patches have waited for
>> months. Waiting for an empty queue is not a workable release criterion: we
>> need to release the fixes we have, rather than hold them indefinitely
>> while more reports arrive. No fixed release cadence or guaranteed response
>> time was settled.
>>
>> Documenting Git's security model would save repeated explanations of what
>> does and does not constitute a vulnerability. (Personal note, not
>> discussed at the Summit: Stolee had tried to start a conversation about
>> Git's security boundary a long time ago, but nobody replied. Maybe the AI
>> onslaught will provide enough motivation to get that discussion going.)
>> Moving non-security bugs to the public list more readily was also
>> encouraged. A timeout after which public discussion would be presumed OK
>> was proposed, but not agreed.
>>
>> More company staffing would help, without turning this into an obligation
>> for volunteers. Paying for dedicated help was discussed, with onboarding
>> costs a concern. Using AI for triage or fixes raises confidentiality and
>> DCO questions of its own. (Personal note: There seemed to be some
>> sentiment in the room that contradicted the earlier agreed-on finding on
>> the mailing list that using AI for triaging and for investigating wasn't a
>> copyright concern and should therefore be considered permissible.)
>>
>> The release bottleneck is not really tag automation. Merging and
>> backporting fixes, preparing advisories, and handling CVEs take work, and
>> too much of that knowledge lives in people's heads. Peff volunteered to
>> start a public discussion of the process and dig up existing resources.
>> (Personal note: I have done that merging, backporting, etc plenty of
>> times, and I don't think that it is the bottleneck, and I was rather
>> surprised to hear that it is complicated. Sure, there are the expected
>> merge conflicts when merging `maint-*` branches, and running -- and
>> fixing! -- CI on all of the tags in a private repository should go without
>> saying, but that's all craft of the trade. Rather, the indecision and lack
>> of engagement on the git-security mailing list is what I see as the
>> blocker. I'd happily volunteer to juggle those branch thickets if that was
>> truly the make-or-break issue here.)
>>
>> Microsoft's release process reportedly needs about seven weeks. There were
>> no objections in the room to proceeding without waiting for that schedule.
>> (Personal note: That release process was misrepresented, which is
>> surprising, as I coordinated two or three Git for Windows security bugfix
>> releases _on the git-security list_ since the most recent Git security
>> bugfix release, it's always the same thing: release on a second Tuesday of
>> the month, three weeks before that the patches need to have settled,
>> everybody goes home with a dependable timeline. It's not really that big
>> of a deal. Testing patches, constructive feedback, these are the things
>> that are missing and therefore blocking the process. I sensed a lot of
>> finger-pointing in this discussion. I mean, I don't blame anybody for
>> avoiding security work: it is stressful and intense. The responsibility
>> for getting things wrong is enormous. I know that because I've done my
>> share of that, probably more than most in the Git project, and I will do
>> even more in the future. But when I don't have the time, or the energy, I
>> am aware that I, myself, am the bottleneck; I don't need to blame others.)
>>
>> Git v3.0
>>
>> The proposed target is spring 2027: v2.56 in September 2026, v2.98 in
>> December, then v2.99 and v3.0 next spring. The jump in version numbers is
>> intended to signal the approaching breaking changes. March and April were
>> both mentioned; the precise timing is not settled.
>>
>> There was agreement on releasing v2.99.1 and v3.0 together, differing only
>> in the BREAKING_CHANGES (v3.0 switches them on). That keeps the transition
>> separate from another round of feature development. Nobody in the room
>> objected to Rust becoming mandatory in v3.0. (Personal note: probably
>> because Randall wasn't there, to say that NonStop support would be a
>> blocker and that Git please wait.) A v2.x LTS remains an open question,
>> with Gentoo mentioned as an interested party. (Personal note: I am still
>> advocating for an in-tree Long Term Support branch, and since Junio
>> indicated that he's less than eager to take care of that, I would love for
>> Patrick Steinhardt to be the "LTS lieutenant", I vaguely remember that he
>> said he'd do it if asked, and I trust his judgement, so I'd ask.)
>>
>> SHA-256 support across the ecosystem had been a blocker. GitHub reported
>> experimental support, with general availability expected around November.
>> GitLab already had public, non-experimental support, and libgit2 supports
>> it, too. JGit remains a gap; Google was not planning to fund that work.
>>
>> The SHA-1/SHA-256 interoperability work, including historical tags, was
>> reported to be implemented but not yet sent to the list. (Personal note: I
>> think that the room seriously "mis-underestimated" the real-world impact
>> of this. The code is not even on the Git mailing list, and the
>> ramifications of not having a robust plan how to deal with partial clones
>> or submodules or even signed tags strikes me as a dealbreaker. I would not
>> be surprised if the decision to enforce SHA-256 as default would have to
>> be revisited before v3.0, and possibly overturned.)
>>
>> Documentation
>>
>> Julia's work highlights the gap between documentation written by people
>> who know Git inside out and users who do not yet know what objects, the
>> index, or upstream mean. We need approachable learning material as well as
>> reference documentation. Both need work; keeping manpages concise does not
>> mean they cannot have better explanations and examples. (Personal note: I
>> am beyond excited that Julia, whose work I have always admired, got
>> interested in improving Git's documentation, which is in dear need of
>> being improved, mainly because it does not cater to the majority of Git
>> users out there who are unlikely to wander onto the Git mailing list,
>> ever. I just hope that old-timers who really do not need the documentation
>> nor understand the need of those who do need it show enough appreciation
>> for the fresh views and for Julia's understanding of the target audience.)
>>
>> Discoverability matters, too. The website (https://git-scm.com/) needs
>> clearer entry points for learning Git, and existing guides are harder to
>> find than manpages. Missing subsection links are another improvement we
>> could make incrementally. (Personal note: Judging by the history of that
>> site, I do wonder whether the core Git contributors are interested in
>> helping this effort at all. For example, there are a growing number of PRs
>> suggesting to add new UIs to the growing list, but I gave up reviewing
>> them because I was the only one doing so.)
>>
>> There was support for replacing outdated material and for merging useful
>> improvements, then iterating, rather than trying to perfect everything
>> before it lands. Bringing user feedback to the list without flooding it
>> remains a challenge.
>>
>> The current funding covers only 100 hours split between two people.
>> Additional project and company funding was encouraged; brian, Emily, and
>> Mark offered to explore company support. (Personal note: I had tried, back
>> when GitHub still funded my team, to start something like that, without
>> any success. To the contrary, even Git for Windows and Git Credential
>> Manager got defunded.)
>>
>> On the tooling side, using only Asciidoctor instead of maintaining both
>> AsciiDoc and Asciidoctor support was proposed as a possible Git v3.0
>> change. Distribution support and rendering differences need checking, with
>> doc-diff suggested for comparing the outputs. Patrick filed an issue
>> during the discussion. (Personal note: AFAIU the AsciiDoc spec is now
>> maintained by Asciidoctor, and I am aware already of one change that was
>> made to the spec without adapting AsciiDoc accordingly. So the entire
>> discussion might be quite moot already.)
>>
>> Other ideas included richer diagrams for HTML while retaining text
>> versions for manpages, and privacy-respecting traffic measurements to help
>> prioritize documentation work. No diagram format was chosen, and caching
>> and AI scraping complicate getting useful traffic data. Mermaid was
>> proposed, and even GraphViz. (Personal note: I added support for Mermaid
>> diagrams to https://git-scm.com/, but it turned out to be too limited, so
>> I added GraphViz support. The support code for this is a bit of a beast,
>> having a wasm version of GraphViz for development, pre-rendering the
>> diagrams as SVG and as PDF during deployment of the site; it was quite a
>> bit of fun to implement all that.)
>>
>> Outreachy sponsoring
>>
>> The goal is to support three interns in the round starting in early
>> December, at $10,000 each. The corporate sponsorship previously provided
>> by GitLab and GitHub has dried up, leaving Git itself to pay. There are
>> company contacts to follow up with; Emily offered to ask Google's OSPO,
>> without high expectations. No new sponsorship commitments were made.
>> (Personal note: I don't think that these internships provide enough
>> publicity to give companies much of an incentive to fund this. Which I
>> find a bit of a shame, Outreachy in particular does a lot of important,
>> good work, and if I wasn't so constantly overworked, I would want to
>> mentor again; I always found it rewarding, even if I hold myself to a
>> quite high bar which is quite draining.)
>>
>> A related point for Git Merge 2027: announcing the location early would
>> help Outreachy and GSoC interns plan attendance. No location was selected.
>>
>> Pluggable object database
>>
>> Patrick's pluggable object database is working, but it is not complete:
>> commit-graph and multi-pack-index integration are still outstanding, and a
>> repository extension is planned. (Personal note: It might be interesting
>> to see whether implementing a storage backend is easier in core Git or in
>> another Git-compatible implementation. JGit should be a natural target,
>> having originated within BigTable-sized constraints, i.e. a different
>> storage system, but funding seems to have dried up, there's not even
>> SHA-256 support, so JGit might not be as hackable as it once was.)
> Pluggable backend implementations for JGit have been possible for quite some
> time, although, admittedly, I don't think any made it to production.
I'd like to provide some context here, as several pluggable JGit storage
implementations are actually running in highly demanding production
environments today.
First, the Git servers at Google (including gerrit.googlesource.com) are
powered by a custom, pluggable JGit storage backend built on top of Google's
internal data-center storage. While the backend implementation itself is
proprietary, it relies entirely on the exact same JGit classes and pluggable
interfaces available in the open-source project. It has been operating
smoothly at a massive scale for over a decade.
Second, there is a highly successful open-source implementation focusing on the
ref-db layer of Git storage. Developed by GerritForge over six years ago and
donated to the AOSP project (see the GitHub mirror at [3]), this backend is
used daily in several large, multi-site Gerrit deployments worldwide. It allows
for globally consistent updates of Git repository refs across distributed
remote sites.
Third, regarding the implementation mentioned by Dani [2]: while it captured
attention 10 years ago, without seeing immediate adoption, I suspect the timing simply
preceded the current appetite for AI-generated code. The demand is entirely
different now. The architectural foundation Google built into JGit over 16
years ago is perfectly positioned to support these kinds of modern innovations.
It is genuinely exciting to see the core Git project moving in this same
direction with Patrick's work. Pluggability has always been a core strength of
JGit's design, and seeing the broader ecosystem embrace this abstraction is a
huge win for all of us.
[3] (github.com/GerritCodeReview/modules_global-refdb)
Luca
> Maybe at
> the time when this was introduced(16 years ago!!) by Shawn[1] in JGit it wasn't
> fashionable yet and so the project was never carried forward. I know Luca
> submitted a talk for the Gerrit User Summit to present a Cassandra back-end, for
> which I can see conversation started 10 years ago[2].
>
> Regarding JGit support's for SHA256, I know some corporations have had interest
> in sponsoring this work and have discussed potentially implementing together it
> with GerritForge, but, as far as I know, work isn't ongoing yet. JGit is still
> very much developed and kept up to date with great effort from the community, so
> I believe it to still be as hackable as it was, there just hasn't been enough
> interest for SHA-256 yet, which I agree is a shame, hopefully in the near future
> this gets remediated.
>
> [1] https://github.com/spearce/jgit_cassandra
> [2] https://groups.google.com/g/repo-discuss/c/IekVPmow0yE
>>
>> Content-defined chunking prompted an important distinction between
>> changing how objects are stored and changing the logical object model.
>> Starting at the storage layer would let us preserve existing blob OIDs
>> rather than require ecosystem-wide changes. A new pack/index format could
>> provide another representation of the same object, much as deltas do
>> today. No particular representation was agreed. (Personal note: It is
>> curious to me why nobody tought about inventing a "meta blob", i.e. an
>> object much like a tree object, except that it stitches together a larger
>> blob. This would allow for the content-defined chunking that `rsync`
>> already championed, way before Git was born! It would have allowed a Git
>> native large file support worth writing home about, and could have
>> replaced Git LFS. Xet (https://huggingface.co/docs/hub/xet/index) would
>> not have had to be invented, and it would have allowed game development to
>> move to Git. I can only imagine that the time it would cost to get even
>> the first patches of this into core Git would be seen as prohibitive by
>> any company who may have considered the effort.)
>>
>> There is also an API question: does a backend seeing only object content
>> have enough context to make good storage and delta choices, or should it
>> receive richer information? More searchable tree storage and a Git "commit
>> cloud" were other possibilities raised, not committed plans. (Personal
>> note: At a previous GitMerge, Facebook presented their work, see e.g.
>> https://github.com/facebook/sapling/blob/main/eden/mononoke/blobstore/packblob/README.md,
>> which includes separating actual storage from transport. That is, already
>> at push time, derived metadata is computed in async jobs which provide
>> several potential deltas ready-to-go when a client clones or fetches. They
>> reported clones with regular Git clients that are twice as fast, just
>> because the server doesn't need to spend much compute on the data it
>> sends. So there is a lot to be learned out there already.)
>>
>> AI
>>
>> The current SubmittingPatches policy is rooted in DCO certification and
>> advice from SFC lawyers. The unresolved question is whether, and to what
>> extent, contributors can certify AI-generated code. There was substantial
>> disagreement about acceptable use, provenance and legal risks, community
>> trust, review burden, and whether the current caution excludes useful
>> tools. No policy change was agreed. (Personal note: You'd think that the
>> opinion of lawyers is taken at face value, but no, it seems that some core
>> Git contributors seem to disagree with the lawyers in favor of their own
>> opinion...)
>>
>> Several participants found language and proofreading assistance useful. A
>> particular concern was submissions where the human does little more than
>> relay agent output, leaving reviewers to deal with the consequences. The
>> influx of poor GSoC contributions was one example. Attribution such as
>> Assisted-by was suggested to make tool use clearer, but attribution alone
>> does not answer the quality or DCO questions. (Personal note: my precedent
>> of "Assisted-by" was called out as helpful, and I do think it is. I make a
>> difference between AI-generated and AI-assisted. I'm not a fast typer, so
>> I benefit a lot from being able to tell an LLM to please refactor out
>> these four lines with the appropriate signature. There's not much
>> creativity in there. I also like to let AI present me the call graphs for
>> certain code locations, because due to the choice of C, which thanks to
>> the C preprocessor is not easy to analyze statically, there are no
>> competent tools other than LLMs that I can use for the task. I was highly
>> surprised, though, to see how much enmity against AI in general was
>> voiced, not by many, but many, many times, and how that contrasts with the
>> Linux project which I hitherto had not considered to be as particularly
>> open to modern practices.)
>>
>> brian and Taylor agreed to put differing policy proposals on the list. The
>> suggested process is to have alternatives examined by SFC counsel, make
>> the risks clear, and then consider a vote. Emily volunteered to organize
>> the voting procedure. Eligibility and the details remain open; Junio's
>> authority as maintainer remains central. (Personal note: Since Taylor
>> works for OpenAI now, I was not surprised by his stance, but brian works
>> at GitHub, home of GitHub Copilot, and I am not sure how favorable their
>> employer would look at their semi-public utterings about AI...)
>>
>> Protocol v2 for pushes
>>
>> There are concrete use cases now: repositories with millions of refs,
>> including a reported 896 MB ref advertisement. Reftable improves ref
>> update throughput, but does not by itself solve the advertisement problem.
>> Nobody objected to push protocol v2, and the fetch-v2 infrastructure
>> already provides much of the foundation.
>>
>> The discussion covered advertising fewer refs, letting clients identify
>> useful branches, and replacing large advertisements with a few rounds of
>> push negotiation. Negotiation results could also help optimize the
>> server's connectivity checks. Some improvements might be possible in the
>> existing protocol before introducing v2.
>>
>> We need to measure the tradeoffs rather than assume fewer bytes means
>> faster pushes. One example involved a shallow push taking 35 seconds
>> instead of two because of work to minimize the transfer. Shallow
>> boundaries and unrelated histories complicate the proposed heuristics.
>>
>> SHA-256 interoperability is another reason to want push v2: the current
>> push protocol requires using the server's primary hash algorithm.
>> Negotiation could make that more flexible.
>>
>> Forge replication to thousands of mirrors would benefit from finding out
>> cheaply whether refs have changed, rather than downloading full
>> advertisements from every target. Checksums, ETag-like values, and
>> reftable generation numbers were discussed, with concurrent updates
>> complicating the picture.
>>
>> Compact or compressed advertisements are also worth exploring and
>> benchmarking, possibly reusing reftable's format. That does not mean
>> sending the server's actual reftable, including hidden refs. There are
>> several promising directions here, but no final design yet.
>>
>> Some breakout sessions were planned, but apparently had to be cut.
>>
>> Personal notes: I wasn't present for all of the sessions, in the afternoon
>> I had other commitments; Therefore these notes (which AI assisted me in
>> distilling) came partially from what I dictated and partially from the
>> shared Google Document in which a few volunteers gracefully wrote notes. I
>> found it challenging to connect as a remote participant. The link to the
>> Google Meet, as well as control over the lobby thereof, seems to have been
>> restricted to at most a few people, which might have contributed to the
>> long waiting time before I was allowed in, and it definitely contributed
>> to my comments not reaching the discussion in time to have an impact. I
>> would have loved for Junio or the other two brave souls who also
>> participated remotedly to have had more "air time". I am still a fan of
>> the idea to have more frequent, smaller, virtual Contributor Summits,
>> organized by a rotating cast. (Maybe I can get Emily to host the next
>> one.) I was very happy that Junio was participating, as he _is_ the
>> project lead, and in past Contributor Summits decisions were taken without
>> him, which I found odd. Timing was really challenging for him, though, it
>> was way past midnight for him. I'm all the more grateful that he
>> did participate.
>>
>> Final remark: This summary is obviously biased. I lightly edited it to
>> separate better between my personal views and a hopefully unbiased account
>> of what was discussed, and how, and by who. Nevertheless, I am but human.
>> As a consequence, I would be delighted if other participants would share
>> their summaries, so that my bias can be balanced out.
>>
>> Ciao,
>> Johannes
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)
2026-09-22 18:44 ` My summary of the Git Contributors' Summit 2026, was " Johannes Schindelin
2026-09-23 11:55 ` Daniele Sassoli
@ 2026-09-23 12:52 ` D. Ben Knoble
2026-09-23 14:22 ` Security mailing list & process, was Re: My summary of the Git Contributors' Summit 2026 Toon Claes
` (2 subsequent siblings)
4 siblings, 0 replies; 22+ messages in thread
From: D. Ben Knoble @ 2026-09-23 12:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
On Tue, Sep 22, 2026 at 2:45 PM Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> I originally wrote this summary of the Git Contributor Summit only for my
> own records, but since you hinted at wanting some meeting notes, figured
> it might be interesting to other people, too. So here goes my distillation
> of the breakout-sessions from this year's Contributors' Summit. Many of
> these ideas still need discussion on the list; proposals below are not
> project-wide decisions.
Thanks for this!
> Git v3.0
>
> The proposed target is spring 2027: v2.56 in September 2026, v2.98 in
> December, then v2.99 and v3.0 next spring. The jump in version numbers is
> intended to signal the approaching breaking changes. March and April were
> both mentioned; the precise timing is not settled.
>
> There was agreement on releasing v2.99.1 and v3.0 together, differing only
> in the BREAKING_CHANGES (v3.0 switches them on). That keeps the transition
> separate from another round of feature development. Nobody in the room
> objected to Rust becoming mandatory in v3.0. (Personal note: probably
> because Randall wasn't there, to say that NonStop support would be a
> blocker and that Git please wait.) A v2.x LTS remains an open question,
> with Gentoo mentioned as an interested party. (Personal note: I am still
> advocating for an in-tree Long Term Support branch, and since Junio
> indicated that he's less than eager to take care of that, I would love for
> Patrick Steinhardt to be the "LTS lieutenant", I vaguely remember that he
> said he'd do it if asked, and I trust his judgement, so I'd ask.)
If you are able/willing to point me towards the [relevant] Gentoo
folks, I'd love to chat
with them. It's been my distribution of choice for the last year and, while I've
helped some on the "packaging Git" side, I have to imagine the 2.x request comes
more from thinking about the surrounding things Git is used for (both developing
the system and running it, such as the 3rd-party repository syncs or live
package installs that use Git).
Anyway, I'd like to help them out :)
> Documentation
>
> Julia's work highlights the gap between documentation written by people
> who know Git inside out and users who do not yet know what objects, the
> index, or upstream mean. We need approachable learning material as well as
> reference documentation. Both need work; keeping manpages concise does not
> mean they cannot have better explanations and examples. (Personal note: I
> am beyond excited that Julia, whose work I have always admired, got
> interested in improving Git's documentation, which is in dear need of
> being improved, mainly because it does not cater to the majority of Git
> users out there who are unlikely to wander onto the Git mailing list,
> ever. I just hope that old-timers who really do not need the documentation
> nor understand the need of those who do need it show enough appreciation
> for the fresh views and for Julia's understanding of the target audience.)
Don't forget that Julia received a grant to continue working on docs!
https://www.sovereign.tech/news/meet-the-2026-sovereign-tech-fellows
> Protocol v2 for pushes
Did I understand correctly from a recent discussion that v2 also requires more
"setup" and is thus not easy to use for smaller "local" hosts? If so, making it
more accessible might also be nice.
> I am still a fan of the idea to have more frequent, smaller, virtual
> Contributor Summits, organized by a rotating cast. (Maybe I can get Emily to
> host the next one.)
In other projects I've participated in, more frequent smaller check-ins have
been helpful. It also feels less icky to miss one for whatever reason, since the
next one is not too far off!
--
D. Ben Knoble
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Security mailing list & process, was Re: My summary of the Git Contributors' Summit 2026
2026-09-22 18:44 ` My summary of the Git Contributors' Summit 2026, was " Johannes Schindelin
2026-09-23 11:55 ` Daniele Sassoli
2026-09-23 12:52 ` D. Ben Knoble
@ 2026-09-23 14:22 ` Toon Claes
2026-09-24 12:38 ` Johannes Schindelin
2026-09-23 14:40 ` Git Contributor' summit: Documentation, was: Re: My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08) Toon Claes
2026-10-17 9:11 ` My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08) Luca Milanesio
4 siblings, 1 reply; 22+ messages in thread
From: Toon Claes @ 2026-09-23 14:22 UTC (permalink / raw)
To: Johannes Schindelin, Junio C Hamano; +Cc: git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Security mailing list and process
(I decided to split up this topic into a separate mail thread)
> The security list is seeing a large influx of outside reports, apparently
> often AI-assisted or generated. Duplicates and reports outside Git's
> security model consume triage time, while some patches have waited for
> months. Waiting for an empty queue is not a workable release criterion: we
> need to release the fixes we have, rather than hold them indefinitely
> while more reports arrive.
I think we agreed on that. Because we realize the influx will not stop
any time soon.
> No fixed release cadence or guaranteed response time was settled.
>
> Documenting Git's security model would save repeated explanations of what
> does and does not constitute a vulnerability.
This is something I was planning to drive after the summit, so I agree.
> (Personal note, not discussed at the Summit: Stolee had tried to start
> a conversation about Git's security boundary a long time ago, but
> nobody replied.
I was not aware of that, maybe that happened before I started
participating there. But I'm happy to get that conversation going again.
I'll try to digg up that discussion.
> Maybe the AI onslaught will provide enough motivation to get that
> discussion going.)
Yes.
> Moving non-security bugs to the public list more readily was also
> encouraged.
That is true, but then still someone has to do the work. We're already
lacking people to work on /real/ reports, so having people to fix bugs
reported is also a staffing issue.
> A timeout after which public discussion would be presumed OK was
> proposed, but not agreed.
I'm against that, but I don't think we need to agree on that already. We
can think about this after settling the other stuff.
> More company staffing would help, without turning this into an obligation
> for volunteers. Paying for dedicated help was discussed, with onboarding
> costs a concern.
All I can say for now, we at GitLab plan to invest more people power
into dealing with security reports.
> Using AI for triage or fixes raises confidentiality and DCO questions
> of its own. (Personal note: There seemed to be some sentiment in the
> room that contradicted the earlier agreed-on finding on the mailing
> list that using AI for triaging and for investigating wasn't a
> copyright concern and should therefore be considered permissible.)
Yeah, no consensus here. The concern wasn't as much copyright, but
passing vulnerabilities to a model, making it possibly train on that
exposing that information to who-knows-where.
> The release bottleneck is not really tag automation. Merging and
> backporting fixes, preparing advisories, and handling CVEs take work, and
> too much of that knowledge lives in people's heads. Peff volunteered to
> start a public discussion of the process and dig up existing resources.
As I pointed out during the conversation, I just don't know how to do
this.
> (Personal note: I have done that merging, backporting, etc plenty of
> times, and I don't think that it is the bottleneck, and I was rather
> surprised to hear that it is complicated.
It's complicated, because we (or I at least) doesn't know how.
> Sure, there are the expected merge conflicts when merging `maint-*`
> branches, and running -- and fixing! -- CI on all of the tags in a
> private repository should go without saying, but that's all craft of
> the trade.
I'd love to learn more about this.
> Rather, the indecision and lack of engagement on the
> git-security mailing list is what I see as the blocker. I'd happily
> volunteer to juggle those branch thickets if that was truly the
> make-or-break issue here.)
I'm very grateful for that. As I mentioned (not sure that made it into
the notes), I'd love to shadow someone doing this to learn from. This
can help me get this going myself and that would distribute the load and
knowledge among more people, for which seems to be a real need.
> Microsoft's release process reportedly needs about seven weeks. There were
> no objections in the room to proceeding without waiting for that schedule.
> (Personal note: That release process was misrepresented, which is
> surprising
I wouldn't say this is surprising, I think most people just don't know
the details.
> as I coordinated two or three Git for Windows security bugfix
> releases _on the git-security list_ since the most recent Git security
> bugfix release, it's always the same thing: release on a second Tuesday of
> the month, three weeks before that the patches need to have settled,
> everybody goes home with a dependable timeline.
Well, thanks, that's clear.
Personally I think we can try to follow that schedule, if possible. We
currently have a few patches waiting for months to be released, and
that's not because of the Git for Windows release schedule, but more
because the lack of call to action. Those easily can get out with the
GfW cadence.
But some other cases, like the 0day Elijah has been working on this
month, I'm not sure that can wait for GfW?
> It's not really that big of a deal. Testing patches, constructive
> feedback, these are the things that are missing and therefore blocking
> the process. I sensed a lot of finger-pointing in this discussion.
I wouldn't say so, I would blame it on the lack knowledge about the
process. Or maybe that's only me speaking.
> I mean, I don't blame anybody for avoiding security work: it is
> stressful and intense. The responsibility for getting things wrong is
> enormous. I know that because I've done my share of that, probably
> more than most in the Git project, and I will do even more in the
> future.
That's why I'd like to learn from you.
> But when I don't have the time, or the energy, I am aware that
> I, myself, am the bottleneck; I don't need to blame others.)
You are not the bottleneck, or at least, you don't need to be the
bottleneck, we should set up things to spread out the load.
So I would like to suggest you and me collaborate closely to get a next
security release out and then we can go from there.
--
Laters,
Toon
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Security mailing list & process, was Re: My summary of the Git Contributors' Summit 2026
2026-09-23 14:22 ` Security mailing list & process, was Re: My summary of the Git Contributors' Summit 2026 Toon Claes
@ 2026-09-24 12:38 ` Johannes Schindelin
0 siblings, 0 replies; 22+ messages in thread
From: Johannes Schindelin @ 2026-09-24 12:38 UTC (permalink / raw)
To: Toon Claes; +Cc: Junio C Hamano, git
Hi Toon,
On Wed, 23 Sep 2026, Toon Claes wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Security mailing list and process
> >
> > [...]
> >
> > Microsoft's release process reportedly needs about seven weeks. There
> > were no objections in the room to proceeding without waiting for that
> > schedule. (Personal note: That release process was misrepresented,
> > which is surprising
>
> I wouldn't say this is surprising, I think most people just don't know
> the details.
>
> > as I coordinated two or three Git for Windows security bugfix releases
> > _on the git-security list_ since the most recent Git security bugfix
> > release, it's always the same thing: release on a second Tuesday of
> > the month, three weeks before that the patches need to have settled,
> > everybody goes home with a dependable timeline.
>
> Well, thanks, that's clear.
>
> Personally I think we can try to follow that schedule, if possible. We
> currently have a few patches waiting for months to be released, and
> that's not because of the Git for Windows release schedule, but more
> because the lack of call to action. Those easily can get out with the
> GfW cadence.
I'm glad that you agree that Patch Tuesday isn't all _that_ much of a
friction point, this will allow some of my colleagues to relax visibly.
> [...]
>
> So I would like to suggest you and me collaborate closely to get a next
> security release out and then we can go from there.
Excellent! Let's continue this conversation in a more private setting ;-)
Ciao,
Johannes
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Git Contributor' summit: Documentation, was: Re: My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)
2026-09-22 18:44 ` My summary of the Git Contributors' Summit 2026, was " Johannes Schindelin
` (2 preceding siblings ...)
2026-09-23 14:22 ` Security mailing list & process, was Re: My summary of the Git Contributors' Summit 2026 Toon Claes
@ 2026-09-23 14:40 ` Toon Claes
2026-09-23 15:15 ` Git Contributor' summit: Documentation, Junio C Hamano
2026-10-17 9:11 ` My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08) Luca Milanesio
4 siblings, 1 reply; 22+ messages in thread
From: Toon Claes @ 2026-09-23 14:40 UTC (permalink / raw)
To: Johannes Schindelin, Junio C Hamano; +Cc: git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Documentation
>
> Julia's work highlights the gap between documentation written by people
> who know Git inside out and users who do not yet know what objects, the
> index, or upstream mean. We need approachable learning material as well as
> reference documentation. Both need work; keeping manpages concise does not
> mean they cannot have better explanations and examples. (Personal note: I
> am beyond excited that Julia, whose work I have always admired,
I've expressed myself multiple times as well how excited I am to have
Julia working on this, but it cannot be expressed enough.
> got interested in improving Git's documentation, which is in dear need
> of being improved, mainly because it does not cater to the majority of
> Git users out there who are unlikely to wander onto the Git mailing
> list, ever. I just hope that old-timers who really do not need the
> documentation nor understand the need of those who do need it show
> enough appreciation for the fresh views and for Julia's understanding
> of the target audience.)
I think the old-timers do, but it takes skills to have a very deep
understanding and still being able to explain things to newbies.
> Discoverability matters, too. The website (https://git-scm.com/) needs
> clearer entry points for learning Git, and existing guides are harder to
> find than manpages. Missing subsection links are another improvement we
> could make incrementally. (Personal note: Judging by the history of that
> site, I do wonder whether the core Git contributors are interested in
> helping this effort at all. For example, there are a growing number of PRs
> suggesting to add new UIs to the growing list, but I gave up reviewing
> them because I was the only one doing so.)
I share the blame here. Some time ago I volunteered to step in to do
maintainance work on git-scm.com, but I haven't been devoting as much
time as I would like.
Talking about the UI list, that's a problem which I'm not sure worth
discussing here, but to folks interested, there is some context in the
PR[1] you created.
[1]: https://github.com/git/git-scm.com/pull/2179
> There was support for replacing outdated material and for merging useful
> improvements, then iterating, rather than trying to perfect everything
> before it lands. Bringing user feedback to the list without flooding it
> remains a challenge.
Iteration will be key here, and I would say some steps have been taken
already. Very tiny steps though.
Finding a medium to gather user feedback is the problem. I think Discord
is a better place than the mailing list (assuming that's what you mean
by "list"?).
> The current funding covers only 100 hours split between two people.
> Additional project and company funding was encouraged; brian, Emily, and
> Mark offered to explore company support. (Personal note: I had tried, back
> when GitHub still funded my team, to start something like that, without
> any success. To the contrary, even Git for Windows and Git Credential
> Manager got defunded.)
>
> On the tooling side, using only Asciidoctor instead of maintaining both
> AsciiDoc and Asciidoctor support was proposed as a possible Git v3.0
> change. Distribution support and rendering differences need checking, with
> doc-diff suggested for comparing the outputs. Patrick filed an issue
> during the discussion. (Personal note: AFAIU the AsciiDoc spec is now
> maintained by Asciidoctor, and I am aware already of one change that was
> made to the spec without adapting AsciiDoc accordingly. So the entire
> discussion might be quite moot already.)
>
> Other ideas included richer diagrams for HTML while retaining text
> versions for manpages
This feels feasible. I think brian suggested to use Open Blocks[2] and
have a man-page ASCII version next to /something else/.
[2]: https://docs.asciidoctor.org/asciidoc/latest/blocks/open-blocks/
> and privacy-respecting traffic measurements to help prioritize
> documentation work.
For the record, we have been talking about this[3] in the past.
[3]: https://github.com/git/git-scm.com/issues/2054
> No diagram format was chosen
Yeah, that's the issue.
> and caching and AI scraping complicate getting useful traffic data.
> Mermaid was proposed, and even GraphViz. (Personal note: I added
> support for Mermaid diagrams to https://git-scm.com/, but it turned
> out to be too limited, so I added GraphViz support. The support code
> for this is a bit of a beast, having a wasm version of GraphViz for
> development, pre-rendering the diagrams as SVG and as PDF during
> deployment of the site; it was quite a bit of fun to implement all
> that.)
Thanks for that! They don't look bad on the cheat sheet[4].
[4]: https://git-scm.com/cheat-sheet#combine-diverged-branches
--
Laters,
Toon
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Git Contributor' summit: Documentation,
2026-09-23 14:40 ` Git Contributor' summit: Documentation, was: Re: My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08) Toon Claes
@ 2026-09-23 15:15 ` Junio C Hamano
0 siblings, 0 replies; 22+ messages in thread
From: Junio C Hamano @ 2026-09-23 15:15 UTC (permalink / raw)
To: Toon Claes; +Cc: Johannes Schindelin, git
Toon Claes <toon@iotcl.com> writes:
> I've expressed myself multiple times as well how excited I am to have
> Julia working on this, but it cannot be expressed enough.
;-)
>> list, ever. I just hope that old-timers who really do not need the
>> documentation nor understand the need of those who do need it show
>> enough appreciation for the fresh views and for Julia's understanding
>> of the target audience.)
>
> I think the old-timers do, but it takes skills to have a very deep
> understanding and still being able to explain things to newbies.
Not just these two skills, but you need to know what are the points
new people find hard to get when they are starting, and that is the
weakest spot for our old-timers.
>> There was support for replacing outdated material and for merging useful
>> improvements, then iterating, rather than trying to perfect everything
>> before it lands. Bringing user feedback to the list without flooding it
>> remains a challenge.
>
> Iteration will be key here, and I would say some steps have been taken
> already. Very tiny steps though.
IIRC, the view in the room was in favor of keeping and incrementally
improving the manual pages and reference material while rewriting
tutorials and material on concepts from scratch. I very much agree
with the "rewrite from scratch" part, because the concepts have
evolved and the world view have been updated even if the concepts at
the very core of the system may have not changed.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)
2026-09-22 18:44 ` My summary of the Git Contributors' Summit 2026, was " Johannes Schindelin
` (3 preceding siblings ...)
2026-09-23 14:40 ` Git Contributor' summit: Documentation, was: Re: My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08) Toon Claes
@ 2026-10-17 9:11 ` Luca Milanesio
2026-10-17 16:41 ` Junio C Hamano
4 siblings, 1 reply; 22+ messages in thread
From: Luca Milanesio @ 2026-10-17 9:11 UTC (permalink / raw)
To: git; +Cc: Luca Milanesio, Junio C Hamano, Johannes Schindelin
> On 22 Sep 2026, at 19:44, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> Hi Junio,
>
> On Tue, 22 Sep 2026, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>>> On Mon, 21 Sep 2026, Junio C Hamano wrote:
>>>
>>>> Git 2.56-rc1 has been tagged. We may merge last-minute fixes before
>>>> the final Git 2.56 release, but otherwise I do not expect any new
>>>> feature topics to be ready before the final, so most of the
>>>> in-flight topics will stay cooking in 'next' until then. As
>>>> discussed at the Git Contributors' Summit, the version after the
>>>> upcoming Git 2.56 will be Git 2.98, scheduled near the end of this
>>>> year.
>>>
>>> Would you say that the following is an accurate characterization of the
>>> timeline, so that people who need to plan dependent projects can rely on
>>> it?
>>
>> My outline was deliberately limited up to end of this year as I am
>> hesitant to say beyond that point before the meeting notes are made
>> public.
>
> I originally wrote this summary of the Git Contributor Summit only for my
> own records, but since you hinted at wanting some meeting notes, figured
> it might be interesting to other people, too. So here goes my distillation
> of the breakout-sessions from this year's Contributors' Summit. Many of
> these ideas still need discussion on the list; proposals below are not
> project-wide decisions.
>
> Security mailing list and process
>
> The security list is seeing a large influx of outside reports, apparently
> often AI-assisted or generated. Duplicates and reports outside Git's
> security model consume triage time, while some patches have waited for
> months. Waiting for an empty queue is not a workable release criterion: we
> need to release the fixes we have, rather than hold them indefinitely
> while more reports arrive. No fixed release cadence or guaranteed response
> time was settled.
>
> Documenting Git's security model would save repeated explanations of what
> does and does not constitute a vulnerability. (Personal note, not
> discussed at the Summit: Stolee had tried to start a conversation about
> Git's security boundary a long time ago, but nobody replied. Maybe the AI
> onslaught will provide enough motivation to get that discussion going.)
> Moving non-security bugs to the public list more readily was also
> encouraged. A timeout after which public discussion would be presumed OK
> was proposed, but not agreed.
>
> More company staffing would help, without turning this into an obligation
> for volunteers. Paying for dedicated help was discussed, with onboarding
> costs a concern. Using AI for triage or fixes raises confidentiality and
> DCO questions of its own. (Personal note: There seemed to be some
> sentiment in the room that contradicted the earlier agreed-on finding on
> the mailing list that using AI for triaging and for investigating wasn't a
> copyright concern and should therefore be considered permissible.)
>
> The release bottleneck is not really tag automation. Merging and
> backporting fixes, preparing advisories, and handling CVEs take work, and
> too much of that knowledge lives in people's heads. Peff volunteered to
> start a public discussion of the process and dig up existing resources.
> (Personal note: I have done that merging, backporting, etc plenty of
> times, and I don't think that it is the bottleneck, and I was rather
> surprised to hear that it is complicated. Sure, there are the expected
> merge conflicts when merging `maint-*` branches, and running -- and
> fixing! -- CI on all of the tags in a private repository should go without
> saying, but that's all craft of the trade. Rather, the indecision and lack
> of engagement on the git-security mailing list is what I see as the
> blocker. I'd happily volunteer to juggle those branch thickets if that was
> truly the make-or-break issue here.)
>
> Microsoft's release process reportedly needs about seven weeks. There were
> no objections in the room to proceeding without waiting for that schedule.
> (Personal note: That release process was misrepresented, which is
> surprising, as I coordinated two or three Git for Windows security bugfix
> releases _on the git-security list_ since the most recent Git security
> bugfix release, it's always the same thing: release on a second Tuesday of
> the month, three weeks before that the patches need to have settled,
> everybody goes home with a dependable timeline. It's not really that big
> of a deal. Testing patches, constructive feedback, these are the things
> that are missing and therefore blocking the process. I sensed a lot of
> finger-pointing in this discussion. I mean, I don't blame anybody for
> avoiding security work: it is stressful and intense. The responsibility
> for getting things wrong is enormous. I know that because I've done my
> share of that, probably more than most in the Git project, and I will do
> even more in the future. But when I don't have the time, or the energy, I
> am aware that I, myself, am the bottleneck; I don't need to blame others.)
>
> Git v3.0
>
> The proposed target is spring 2027: v2.56 in September 2026, v2.98 in
> December, then v2.99 and v3.0 next spring. The jump in version numbers is
> intended to signal the approaching breaking changes. March and April were
> both mentioned; the precise timing is not settled.
>
> There was agreement on releasing v2.99.1 and v3.0 together, differing only
> in the BREAKING_CHANGES (v3.0 switches them on). That keeps the transition
> separate from another round of feature development. Nobody in the room
> objected to Rust becoming mandatory in v3.0. (Personal note: probably
> because Randall wasn't there, to say that NonStop support would be a
> blocker and that Git please wait.) A v2.x LTS remains an open question,
> with Gentoo mentioned as an interested party. (Personal note: I am still
> advocating for an in-tree Long Term Support branch, and since Junio
> indicated that he's less than eager to take care of that, I would love for
> Patrick Steinhardt to be the "LTS lieutenant", I vaguely remember that he
> said he'd do it if asked, and I trust his judgement, so I'd ask.)
>
> SHA-256 support across the ecosystem had been a blocker. GitHub reported
> experimental support, with general availability expected around November.
> GitLab already had public, non-experimental support, and libgit2 supports
> it, too. JGit remains a gap; Google was not planning to fund that work.
It looks like the above statement needs amending, see:
https://gus26.gerritforge.com/schedule.html
Google will present their plans for SHA-256 at the forthcoming Gerrit User Summit
and jj Mini-Summit at the Google Campus in Sunnyvale CA.
The talk is at 2:00 PM PDT: "SHA-256 in JGit: Why, What, and When (Xing Huang - Google)”
Anyone joining from the Git community?
Luca.
>
> The SHA-1/SHA-256 interoperability work, including historical tags, was
> reported to be implemented but not yet sent to the list. (Personal note: I
> think that the room seriously "mis-underestimated" the real-world impact
> of this. The code is not even on the Git mailing list, and the
> ramifications of not having a robust plan how to deal with partial clones
> or submodules or even signed tags strikes me as a dealbreaker. I would not
> be surprised if the decision to enforce SHA-256 as default would have to
> be revisited before v3.0, and possibly overturned.)
>
> Documentation
>
> Julia's work highlights the gap between documentation written by people
> who know Git inside out and users who do not yet know what objects, the
> index, or upstream mean. We need approachable learning material as well as
> reference documentation. Both need work; keeping manpages concise does not
> mean they cannot have better explanations and examples. (Personal note: I
> am beyond excited that Julia, whose work I have always admired, got
> interested in improving Git's documentation, which is in dear need of
> being improved, mainly because it does not cater to the majority of Git
> users out there who are unlikely to wander onto the Git mailing list,
> ever. I just hope that old-timers who really do not need the documentation
> nor understand the need of those who do need it show enough appreciation
> for the fresh views and for Julia's understanding of the target audience.)
>
> Discoverability matters, too. The website (https://git-scm.com/) needs
> clearer entry points for learning Git, and existing guides are harder to
> find than manpages. Missing subsection links are another improvement we
> could make incrementally. (Personal note: Judging by the history of that
> site, I do wonder whether the core Git contributors are interested in
> helping this effort at all. For example, there are a growing number of PRs
> suggesting to add new UIs to the growing list, but I gave up reviewing
> them because I was the only one doing so.)
>
> There was support for replacing outdated material and for merging useful
> improvements, then iterating, rather than trying to perfect everything
> before it lands. Bringing user feedback to the list without flooding it
> remains a challenge.
>
> The current funding covers only 100 hours split between two people.
> Additional project and company funding was encouraged; brian, Emily, and
> Mark offered to explore company support. (Personal note: I had tried, back
> when GitHub still funded my team, to start something like that, without
> any success. To the contrary, even Git for Windows and Git Credential
> Manager got defunded.)
>
> On the tooling side, using only Asciidoctor instead of maintaining both
> AsciiDoc and Asciidoctor support was proposed as a possible Git v3.0
> change. Distribution support and rendering differences need checking, with
> doc-diff suggested for comparing the outputs. Patrick filed an issue
> during the discussion. (Personal note: AFAIU the AsciiDoc spec is now
> maintained by Asciidoctor, and I am aware already of one change that was
> made to the spec without adapting AsciiDoc accordingly. So the entire
> discussion might be quite moot already.)
>
> Other ideas included richer diagrams for HTML while retaining text
> versions for manpages, and privacy-respecting traffic measurements to help
> prioritize documentation work. No diagram format was chosen, and caching
> and AI scraping complicate getting useful traffic data. Mermaid was
> proposed, and even GraphViz. (Personal note: I added support for Mermaid
> diagrams to https://git-scm.com/, but it turned out to be too limited, so
> I added GraphViz support. The support code for this is a bit of a beast,
> having a wasm version of GraphViz for development, pre-rendering the
> diagrams as SVG and as PDF during deployment of the site; it was quite a
> bit of fun to implement all that.)
>
> Outreachy sponsoring
>
> The goal is to support three interns in the round starting in early
> December, at $10,000 each. The corporate sponsorship previously provided
> by GitLab and GitHub has dried up, leaving Git itself to pay. There are
> company contacts to follow up with; Emily offered to ask Google's OSPO,
> without high expectations. No new sponsorship commitments were made.
> (Personal note: I don't think that these internships provide enough
> publicity to give companies much of an incentive to fund this. Which I
> find a bit of a shame, Outreachy in particular does a lot of important,
> good work, and if I wasn't so constantly overworked, I would want to
> mentor again; I always found it rewarding, even if I hold myself to a
> quite high bar which is quite draining.)
>
> A related point for Git Merge 2027: announcing the location early would
> help Outreachy and GSoC interns plan attendance. No location was selected.
>
> Pluggable object database
>
> Patrick's pluggable object database is working, but it is not complete:
> commit-graph and multi-pack-index integration are still outstanding, and a
> repository extension is planned. (Personal note: It might be interesting
> to see whether implementing a storage backend is easier in core Git or in
> another Git-compatible implementation. JGit should be a natural target,
> having originated within BigTable-sized constraints, i.e. a different
> storage system, but funding seems to have dried up, there's not even
> SHA-256 support, so JGit might not be as hackable as it once was.)
>
> Content-defined chunking prompted an important distinction between
> changing how objects are stored and changing the logical object model.
> Starting at the storage layer would let us preserve existing blob OIDs
> rather than require ecosystem-wide changes. A new pack/index format could
> provide another representation of the same object, much as deltas do
> today. No particular representation was agreed. (Personal note: It is
> curious to me why nobody tought about inventing a "meta blob", i.e. an
> object much like a tree object, except that it stitches together a larger
> blob. This would allow for the content-defined chunking that `rsync`
> already championed, way before Git was born! It would have allowed a Git
> native large file support worth writing home about, and could have
> replaced Git LFS. Xet (https://huggingface.co/docs/hub/xet/index) would
> not have had to be invented, and it would have allowed game development to
> move to Git. I can only imagine that the time it would cost to get even
> the first patches of this into core Git would be seen as prohibitive by
> any company who may have considered the effort.)
>
> There is also an API question: does a backend seeing only object content
> have enough context to make good storage and delta choices, or should it
> receive richer information? More searchable tree storage and a Git "commit
> cloud" were other possibilities raised, not committed plans. (Personal
> note: At a previous GitMerge, Facebook presented their work, see e.g.
> https://github.com/facebook/sapling/blob/main/eden/mononoke/blobstore/packblob/README.md,
> which includes separating actual storage from transport. That is, already
> at push time, derived metadata is computed in async jobs which provide
> several potential deltas ready-to-go when a client clones or fetches. They
> reported clones with regular Git clients that are twice as fast, just
> because the server doesn't need to spend much compute on the data it
> sends. So there is a lot to be learned out there already.)
>
> AI
>
> The current SubmittingPatches policy is rooted in DCO certification and
> advice from SFC lawyers. The unresolved question is whether, and to what
> extent, contributors can certify AI-generated code. There was substantial
> disagreement about acceptable use, provenance and legal risks, community
> trust, review burden, and whether the current caution excludes useful
> tools. No policy change was agreed. (Personal note: You'd think that the
> opinion of lawyers is taken at face value, but no, it seems that some core
> Git contributors seem to disagree with the lawyers in favor of their own
> opinion...)
>
> Several participants found language and proofreading assistance useful. A
> particular concern was submissions where the human does little more than
> relay agent output, leaving reviewers to deal with the consequences. The
> influx of poor GSoC contributions was one example. Attribution such as
> Assisted-by was suggested to make tool use clearer, but attribution alone
> does not answer the quality or DCO questions. (Personal note: my precedent
> of "Assisted-by" was called out as helpful, and I do think it is. I make a
> difference between AI-generated and AI-assisted. I'm not a fast typer, so
> I benefit a lot from being able to tell an LLM to please refactor out
> these four lines with the appropriate signature. There's not much
> creativity in there. I also like to let AI present me the call graphs for
> certain code locations, because due to the choice of C, which thanks to
> the C preprocessor is not easy to analyze statically, there are no
> competent tools other than LLMs that I can use for the task. I was highly
> surprised, though, to see how much enmity against AI in general was
> voiced, not by many, but many, many times, and how that contrasts with the
> Linux project which I hitherto had not considered to be as particularly
> open to modern practices.)
>
> brian and Taylor agreed to put differing policy proposals on the list. The
> suggested process is to have alternatives examined by SFC counsel, make
> the risks clear, and then consider a vote. Emily volunteered to organize
> the voting procedure. Eligibility and the details remain open; Junio's
> authority as maintainer remains central. (Personal note: Since Taylor
> works for OpenAI now, I was not surprised by his stance, but brian works
> at GitHub, home of GitHub Copilot, and I am not sure how favorable their
> employer would look at their semi-public utterings about AI...)
>
> Protocol v2 for pushes
>
> There are concrete use cases now: repositories with millions of refs,
> including a reported 896 MB ref advertisement. Reftable improves ref
> update throughput, but does not by itself solve the advertisement problem.
> Nobody objected to push protocol v2, and the fetch-v2 infrastructure
> already provides much of the foundation.
>
> The discussion covered advertising fewer refs, letting clients identify
> useful branches, and replacing large advertisements with a few rounds of
> push negotiation. Negotiation results could also help optimize the
> server's connectivity checks. Some improvements might be possible in the
> existing protocol before introducing v2.
>
> We need to measure the tradeoffs rather than assume fewer bytes means
> faster pushes. One example involved a shallow push taking 35 seconds
> instead of two because of work to minimize the transfer. Shallow
> boundaries and unrelated histories complicate the proposed heuristics.
>
> SHA-256 interoperability is another reason to want push v2: the current
> push protocol requires using the server's primary hash algorithm.
> Negotiation could make that more flexible.
>
> Forge replication to thousands of mirrors would benefit from finding out
> cheaply whether refs have changed, rather than downloading full
> advertisements from every target. Checksums, ETag-like values, and
> reftable generation numbers were discussed, with concurrent updates
> complicating the picture.
>
> Compact or compressed advertisements are also worth exploring and
> benchmarking, possibly reusing reftable's format. That does not mean
> sending the server's actual reftable, including hidden refs. There are
> several promising directions here, but no final design yet.
>
> Some breakout sessions were planned, but apparently had to be cut.
>
> Personal notes: I wasn't present for all of the sessions, in the afternoon
> I had other commitments; Therefore these notes (which AI assisted me in
> distilling) came partially from what I dictated and partially from the
> shared Google Document in which a few volunteers gracefully wrote notes. I
> found it challenging to connect as a remote participant. The link to the
> Google Meet, as well as control over the lobby thereof, seems to have been
> restricted to at most a few people, which might have contributed to the
> long waiting time before I was allowed in, and it definitely contributed
> to my comments not reaching the discussion in time to have an impact. I
> would have loved for Junio or the other two brave souls who also
> participated remotedly to have had more "air time". I am still a fan of
> the idea to have more frequent, smaller, virtual Contributor Summits,
> organized by a rotating cast. (Maybe I can get Emily to host the next
> one.) I was very happy that Junio was participating, as he _is_ the
> project lead, and in past Contributor Summits decisions were taken without
> him, which I found odd. Timing was really challenging for him, though, it
> was way past midnight for him. I'm all the more grateful that he
> did participate.
>
> Final remark: This summary is obviously biased. I lightly edited it to
> separate better between my personal views and a hopefully unbiased account
> of what was discussed, and how, and by who. Nevertheless, I am but human.
> As a consequence, I would be delighted if other participants would share
> their summaries, so that my bias can be balanced out.
>
> Ciao,
> Johannes
>
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)
2026-10-17 9:11 ` My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08) Luca Milanesio
@ 2026-10-17 16:41 ` Junio C Hamano
2026-10-17 20:58 ` Luca Milanesio
0 siblings, 1 reply; 22+ messages in thread
From: Junio C Hamano @ 2026-10-17 16:41 UTC (permalink / raw)
To: Luca Milanesio; +Cc: git, Johannes Schindelin
Luca Milanesio <luca.milanesio@gmail.com> writes:
[Administrivia: PLEASE TRIM YOUR QUOTES. Most parts of what you
quoted from the long message are irrelevant and did not help giving
context to your comments below].
>> SHA-256 support across the ecosystem had been a blocker. GitHub reported
>> experimental support, with general availability expected around November.
>> GitLab already had public, non-experimental support, and libgit2 supports
>> it, too. JGit remains a gap; Google was not planning to fund that work.
>
> It looks like the above statement needs amending, see:
> https://gus26.gerritforge.com/schedule.html
>
> Google will present their plans for SHA-256 at the forthcoming Gerrit User Summit
> and jj Mini-Summit at the Google Campus in Sunnyvale CA.
>
> The talk is at 2:00 PM PDT: "SHA-256 in JGit: Why, What, and When (Xing Huang - Google)”
>
> Anyone joining from the Git community?
You forgot to mention that the talk is scheduled for Tuesday,
November 10th.
The home page at https://gus26.gerritforge.com/ has a registration
link "Register - it's free". I have registered, as I expect to be
within walking distance of the venue on that day.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: My summary of the Git Contributors' Summit 2026, was Re: Git v3.0 timeline, was Re: What's cooking in git.git (Sep 2026, #08)
2026-10-17 16:41 ` Junio C Hamano
@ 2026-10-17 20:58 ` Luca Milanesio
0 siblings, 0 replies; 22+ messages in thread
From: Luca Milanesio @ 2026-10-17 20:58 UTC (permalink / raw)
To: git; +Cc: Luca Milanesio, Johannes Schindelin, Junio C Hamano
> On 17 Oct 2026, at 17:41, Junio C Hamano <gitster@pobox.com> wrote:
>
> Luca Milanesio <luca.milanesio@gmail.com> writes:
>
> [Administrivia: PLEASE TRIM YOUR QUOTES. Most parts of what you
> quoted from the long message are irrelevant and did not help giving
> context to your comments below].
>
>>> SHA-256 support across the ecosystem had been a blocker. GitHub reported
>>> experimental support, with general availability expected around November.
>>> GitLab already had public, non-experimental support, and libgit2 supports
>>> it, too. JGit remains a gap; Google was not planning to fund that work.
>>
>> It looks like the above statement needs amending, see:
>> https://gus26.gerritforge.com/schedule.html
>>
>> Google will present their plans for SHA-256 at the forthcoming Gerrit User Summit
>> and jj Mini-Summit at the Google Campus in Sunnyvale CA.
>>
>> The talk is at 2:00 PM PDT: "SHA-256 in JGit: Why, What, and When (Xing Huang - Google)”
>>
>> Anyone joining from the Git community?
>
> You forgot to mention that the talk is scheduled for Tuesday,
> November 10th.
>
> The home page at https://gus26.gerritforge.com/ has a registration
> link "Register - it's free". I have registered, as I expect to be
> within walking distance of the venue on that day.
Cool, see you there in November!
Luca.
^ permalink raw reply [flat|nested] 22+ messages in thread