{"thread":{"id":"64229","subject":"When should we release Git 3.0?","startedAt":"2025-09-30T23:07:50Z","lastAt":"2025-10-16T21:42:16Z","messageCount":33,"participants":["brian m. carlson","Luca Milanesio","Taylor Blau","Michal Suchánek","rsbecker@nexbridge.com","Junio C Hamano","Patrick Steinhardt","Ben Knoble","SZEDER Gábor"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"527666","messageId":"aNxivuJEnSHbQNdr@fruit.crustytoothpaste.net","threadId":"64229","inReplyTo":null,"subject":"When should we release Git 3.0?","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-09-30T23:07:42Z","receivedAt":"2025-09-30T23:07:50Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"There's been discussion at the Contributor Summit about when we should\nrelease Git 3.0. The original plan that was discussed was to release in\nabout a year, which is about 4 releases away.\n\nAlmost all of the functionality that we had wanted in Git 3.0 has been\nimplemented. The two major things we may want to consider as blockers\nfor Git 3.0 are the following:\n\n* The SHA-256 interoperability work is not done yet. My estimate of\n this work is 200–400 patches, of which about 100 are done. If the\n original schedule is maintained, this would require writing up to 75\n patches and sending in 100 patches per cycle, which is unrealistic\n without additional contributors.\n* Some forges and other projects do not yet have full SHA-256 support.\n It's my understanding that all of the major forges are undertaking or\n have undertaken this work and are at various levels of completion, but\n it's not clear that other projects have appropriate support.\n\nWe may also wish to stick to a stricter timeframe for this release\nregardless and make four releases from now or the next release a year\naway Git 3.0 regardless of whether those items above are completed.\n\nDiscussions at the Contributor Summit did mention the advantage of\nhaving a hard deadline would be that it would make projects and forges\nspend the time to implement SHA-256 support if they're lacking it.\n\nI personally do not want the interoperability work to be a blocker. I\nhaven't really heard other commitments of contributors who want to work\non it and I don't really want to have to run full tilt trying to get it\nout. However, some other people may feel differently, in which I case I\nencourage their participation in the project.\n\nWhat do others think about this?\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"527672","messageId":"E03F997F-1738-4CF6-B7D5-206183FA5BD1@gmail.com","threadId":"64229","inReplyTo":"aNxivuJEnSHbQNdr@fruit.crustytoothpaste.net","subject":"Re: When should we release Git 3.0?","fromName":"Luca Milanesio","fromEmail":"luca.milanesio@gmail.com","sentAt":"2025-10-01T07:13:12Z","receivedAt":"2025-10-01T07:13:25Z","isPatch":false,"sender":{"key":"luca.milanesio@gmail.com","avatar":"https://gravatar.com/avatar/64e45570bb8baaba9a566592150e6c7341a300e314501a944cb95b0bc1380f49?d=mp&s=160"},"body":"\n\n> On 1 Oct 2025, at 00:07, brian m. carlson wrote:\n> \n> There's been discussion at the Contributor Summit about when we should\n> release Git 3.0. The original plan that was discussed was to release in\n> about a year, which is about 4 releases away.\n> \n> Almost all of the functionality that we had wanted in Git 3.0 has been\n> implemented. The two major things we may want to consider as blockers\n> for Git 3.0 are the following:\n> \n> * The SHA-256 interoperability work is not done yet. My estimate of\n> this work is 200–400 patches, of which about 100 are done. If the\n> original schedule is maintained, this would require writing up to 75\n> patches and sending in 100 patches per cycle, which is unrealistic\n> without additional contributors.\n> * Some forges and other projects do not yet have full SHA-256 support.\n> It's my understanding that all of the major forges are undertaking or\n> have undertaken this work and are at various levels of completion, but\n> it's not clear that other projects have appropriate support.\n> \n> We may also wish to stick to a stricter timeframe for this release\n> regardless and make four releases from now or the next release a year\n> away Git 3.0 regardless of whether those items above are completed.\n\nI apologise to not have participated to the Contributor Summit, I just joined the Git Mini-Summit in Amsterdam and we discussed briefly Gerrit 3.0 over dinner, but not with such a detail.\nDo you have the notes or recording of the discussion?\n\nI am worried that if we rush into Git 3.0 with breaking changes that would make other “forges” (e.g. JGit) incompatible, we would be in a difficult situation with the other Git ecosystem that isn’t based on the C-Git implementation.\n\n> Discussions at the Contributor Summit did mention the advantage of\n> having a hard deadline would be that it would make projects and forges\n> spend the time to implement SHA-256 support if they're lacking it.\n\nHappy to spend more time on it, I believe Nasser and Martin from the JGit project attended in-person yesterday.\nAny commitment from your side? Do you have budget from your $DAY_JOB?\n\n> I personally do not want the interoperability work to be a blocker. I\n> haven't really heard other commitments of contributors who want to work\n> on it and I don't really want to have to run full tilt trying to get it\n> out. However, some other people may feel differently, in which I case I\n> encourage their participation in the project.\n\nSure, happy to participate.\n\nLuca."},{"id":"527697","messageId":"aN1QUDzYli0GsGy9@nand.local","threadId":"64229","inReplyTo":"aNxivuJEnSHbQNdr@fruit.crustytoothpaste.net","subject":"Re: When should we release Git 3.0?","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2025-10-01T16:01:20Z","receivedAt":"2025-10-01T16:01:27Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Tue, Sep 30, 2025 at 11:07:42PM +0000, brian m. carlson wrote:\n> Almost all of the functionality that we had wanted in Git 3.0 has been\n> implemented. The two major things we may want to consider as blockers\n> for Git 3.0 are the following:\n>\n> * The SHA-256 interoperability work is not done yet. My estimate of\n> this work is 200–400 patches, of which about 100 are done. If the\n> original schedule is maintained, this would require writing up to 75\n> patches and sending in 100 patches per cycle, which is unrealistic\n> without additional contributors.\n\nI need to polish up the notes from the Contributor's Summit and share\nthem with the list, but my general feeling at the end of the discussion\non the SHA-256 interoperability work was that it wasn't clear whether or\nnot it should be a blocker for Git 3.0.\n\nIf post-3.0 repositories are using SHA-256, then either their post-Git\n3.0 clients will also use SHA-256, or the pre-3.0 clients (without\ninterop support) will be unable to interact with them. I don't think\nthere would be any reason to have a interop-capable client use a SHA-256\nrepository in SHA-1 mode.\n\nOn the other side of the coin, if a repository is still using SHA-1,\nthen both pre-3.0 and post-3.0 clients will be able to interact with it\nwithout interop support.\n\nBut you have thought about the interop work far more than I (or anybody\nelse) has, so I am very likely missing some obvious use-case here.\n\n> * Some forges and other projects do not yet have full SHA-256 support.\n> It's my understanding that all of the major forges are undertaking or\n> have undertaken this work and are at various levels of completion, but\n> it's not clear that other projects have appropriate support.\n>\n> We may also wish to stick to a stricter timeframe for this release\n> regardless and make four releases from now or the next release a year\n> away Git 3.0 regardless of whether those items above are completed.\n>\n> Discussions at the Contributor Summit did mention the advantage of\n> having a hard deadline would be that it would make projects and forges\n> spend the time to implement SHA-256 support if they're lacking it.\n\nMy feeling on this portion of the discussion was that we should take\ninto account the readiness of the ecosystem as a whole in deciding when\nto release Git 3.0.\n\nI agree that not having a deadline can lead to forges delaying the work\nnecessary to support SHA-256 repositories, so I agree that we shouldn't\npush it off into the future indefinitely.\n\nOn the other side of the coin, I don't think we should rush Git 3.0 out\nthe door before the ecosystem is broadly ready for it. If we do that,\nwe're creating a worse experience for a significant portion of Git users\nthat use popular forges who may not have complete SHA-256 support at the\ntime of the release.\n\nThanks,\nTaylor\n"},{"id":"527698","messageId":"aN1RFvz7uGPnepxe@nand.local","threadId":"64229","inReplyTo":"E03F997F-1738-4CF6-B7D5-206183FA5BD1@gmail.com","subject":"Re: When should we release Git 3.0?","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2025-10-01T16:04:38Z","receivedAt":"2025-10-01T16:04:42Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Wed, Oct 01, 2025 at 08:13:12AM +0100, Luca Milanesio wrote:\n> I am worried that if we rush into Git 3.0 with breaking changes that\n> would make other “forges” (e.g. JGit) incompatible, we would be in a\n> difficult situation with the other Git ecosystem that isn’t based on\n> the C-Git implementation.\n\nThat's a good point. I am not familiar enough with JGit (or really any\nnon-standard Git implementations) to know where SHA-256 support is in\nthose respective implementations.\n\nBut regardless of whether we're talking about a forge that is based on\ngit.git or some other implementation, there is very likely lots of other\nwork to be done to support SHA-256 outside of flipping the hash function\nwithin Git.\n\n(I'm thinking here about database migrations for columns that may store\n40-character SHA-1 hashes, for example, which can take a potentially\nsignificant amount of time to migrate depending on the size of the\ndatabase, etc.)\n\nSo my feeling here is that we should take into account not just the\nreadiness of the underlying Git implementation used by hosting providers\nin the Git ecosystem, but also the readiness of the hosting providers\nthemselves to do the work necessary to facilitate that transition\noutside of their Git implementation.\n\nThanks,\nTaylor\n"},{"id":"527700","messageId":"aN1UtbJRIhgvMmaF@kitsune.suse.cz","threadId":"64229","inReplyTo":"aN1QUDzYli0GsGy9@nand.local","subject":"Re: When should we release Git 3.0?","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2025-10-01T16:20:05Z","receivedAt":"2025-10-01T16:20:10Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"Hello,\n\nOn Wed, Oct 01, 2025 at 12:01:20PM -0400, Taylor Blau wrote:\n> On Tue, Sep 30, 2025 at 11:07:42PM +0000, brian m. carlson wrote:\n> > Almost all of the functionality that we had wanted in Git 3.0 has been\n> > implemented. The two major things we may want to consider as blockers\n> > for Git 3.0 are the following:\n> >\n> > * The SHA-256 interoperability work is not done yet. My estimate of\n> > this work is 200–400 patches, of which about 100 are done. If the\n> > original schedule is maintained, this would require writing up to 75\n> > patches and sending in 100 patches per cycle, which is unrealistic\n> > without additional contributors.\n\nFrom my very limited point of view as a user the interop is the major\nplanned feature currently missing in git, and I do not see much point\nwithout it. Then again I do not know how useful it will be in practice.\n\n> I need to polish up the notes from the Contributor's Summit and share\n> them with the list, but my general feeling at the end of the discussion\n> on the SHA-256 interoperability work was that it wasn't clear whether or\n> not it should be a blocker for Git 3.0.\n> \n> If post-3.0 repositories are using SHA-256, then either their post-Git\n> 3.0 clients will also use SHA-256, or the pre-3.0 clients (without\n> interop support) will be unable to interact with them. I don't think\n> there would be any reason to have a interop-capable client use a SHA-256\n> repository in SHA-1 mode.\n\nFlipping the default to sha256 would clearly break some things. I can\nuse sha256 repositories in gitea today (no interop whatsoever) but\ngithub rejects them.\n\nThen again cloning a repository uses the correct hash which means if I\ncreate the repository on the forge and clone it there is no problem\nwhatsoever regardless of hash used. Whill that break as well?\n\nThanks\n\nMichal\n"},{"id":"527718","messageId":"04f501dc330a$0ecd3010$2c679030$@nexbridge.com","threadId":"64229","inReplyTo":"aN1RFvz7uGPnepxe@nand.local","subject":"RE: When should we release Git 3.0?","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-10-01T19:31:54Z","receivedAt":"2025-10-01T19:32:09Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On October 1, 2025 12:05 PM, Taylor Blau wrote:\n>On Wed, Oct 01, 2025 at 08:13:12AM +0100, Luca Milanesio wrote:\n>> I am worried that if we rush into Git 3.0 with breaking changes that\n>> would make other “forges” (e.g. JGit) incompatible, we would be in a\n>> difficult situation with the other Git ecosystem that isn’t based on\n>> the C-Git implementation.\n>\n>That's a good point. I am not familiar enough with JGit (or really any non-standard\n>Git implementations) to know where SHA-256 support is in those respective\n>implementations.\n\nAFAIK, JGit still depends on some core git functions, including gc. It also depends on\nLFS for those functions. Interop it fairly important in that space.\n\n>But regardless of whether we're talking about a forge that is based on git.git or\n>some other implementation, there is very likely lots of other work to be done to\n>support SHA-256 outside of flipping the hash function within Git.\n>\n>(I'm thinking here about database migrations for columns that may store 40-\n>character SHA-1 hashes, for example, which can take a potentially significant\n>amount of time to migrate depending on the size of the database, etc.)\n>\n>So my feeling here is that we should take into account not just the readiness of the\n>underlying Git implementation used by hosting providers in the Git ecosystem, but\n>also the readiness of the hosting providers themselves to do the work necessary to\n>facilitate that transition outside of their Git implementation.\n\nRegards,\nRandall\n\n"},{"id":"527722","messageId":"xmqqecrm1hs1.fsf@gitster.g","threadId":"64229","inReplyTo":"aN1QUDzYli0GsGy9@nand.local","subject":"Re: When should we release Git 3.0?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-01T20:36:14Z","receivedAt":"2025-10-01T20:36:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Taylor Blau writes:\n\n> On Tue, Sep 30, 2025 at 11:07:42PM +0000, brian m. carlson wrote:\n>> Almost all of the functionality that we had wanted in Git 3.0 has been\n>> implemented. The two major things we may want to consider as blockers\n>> for Git 3.0 are the following:\n>>\n>> * The SHA-256 interoperability work is not done yet. My estimate of\n>> this work is 200–400 patches, of which about 100 are done. If the\n>> original schedule is maintained, this would require writing up to 75\n>> patches and sending in 100 patches per cycle, which is unrealistic\n>> without additional contributors.\n>\n> I need to polish up the notes from the Contributor's Summit and share\n> them with the list, but my general feeling at the end of the discussion\n> on the SHA-256 interoperability work was that it wasn't clear whether or\n> not it should be a blocker for Git 3.0.\n>\n> If post-3.0 repositories are using SHA-256, then either their post-Git\n> 3.0 clients will also use SHA-256, or the pre-3.0 clients (without\n> interop support) will be unable to interact with them. I don't think\n> there would be any reason to have a interop-capable client use a SHA-256\n> repository in SHA-1 mode.\n\nWhat is the recommended workflow if you have unpublished work,\nwritten back in your private SHA-1 clone of a project, meant to be\nsubmit someday to your project, that used to use SHA-1 but has\nmigrated to SHA-256? Convert locally your repository to SHA-256\nprimary with SHA-1 compat and then push to them?\n\nPresumably the server side _has_ already done most of the conversion\nwork so, provided if (and this is a huge if) we assume that the\nconversion done on the server side is trustable, we should be able\nto _clone_ from the server in SHA-256 primary SHA-1 compat mode, and\npush your unpublished changes from your SHA-1 private repository\ninto this clone using SHA-1 protocol (i.e. no conversion to the\noriginal repository)? And upon accepting such a push, the receiving\nrepository (which is still a local clone of the project, but the one\nyou recently made and is aware of SHA-256 world) would now have your\nunpublished work in SHA-256 (with SHA-1 compat) objects and everybody\nis happy?\n\n>> We may also wish to stick to a stricter timeframe for this release\n>> regardless and make four releases from now or the next release a year\n>> away Git 3.0 regardless of whether those items above are completed.\n>>\n>> Discussions at the Contributor Summit did mention the advantage of\n>> having a hard deadline would be that it would make projects and forges\n>> spend the time to implement SHA-256 support if they're lacking it.\n>\n> My feeling on this portion of the discussion was that we should take\n> into account the readiness of the ecosystem as a whole in deciding when\n> to release Git 3.0.\n>\n> I agree that not having a deadline can lead to forges delaying the work\n> necessary to support SHA-256 repositories, so I agree that we shouldn't\n> push it off into the future indefinitely.\n>\n> On the other side of the coin, I don't think we should rush Git 3.0 out\n> the door before the ecosystem is broadly ready for it. If we do that,\n> we're creating a worse experience for a significant portion of Git users\n> that use popular forges who may not have complete SHA-256 support at the\n> time of the release.\n\nYeah, I wouldn't exactly say \"we'll tag when the world is ready\",\nbut declaring 3.0 when nobody is ready would miss the opportunity to\nmake a big impact.\n"},{"id":"527735","messageId":"aN2oSBz8s_hSBMPq@fruit.crustytoothpaste.net","threadId":"64229","inReplyTo":"aN1UtbJRIhgvMmaF@kitsune.suse.cz","subject":"Re: When should we release Git 3.0?","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-10-01T22:16:40Z","receivedAt":"2025-10-01T22:16:43Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-10-01 at 16:20:05, Michal Suchánek wrote:\n> From my very limited point of view as a user the interop is the major\n> planned feature currently missing in git, and I do not see much point\n> without it. Then again I do not know how useful it will be in practice.\n\nIt is the major planned feature which was missing.\n\nThe primary use cases are converting repositories and working with\nrepositories using a different algorithm. The latter might be useful if\nyou're using a SHA-256 repository that someone else has created but your\ntooling cannot handle longer object IDs or otherwise has some limitation\nof that sort.\n\nIf you are happy working with SHA-1 repositories in SHA-1 and SHA-256\nrepositories in SHA-256, then you don't need the interoperability work.\nSHA-256 repositories have been supported in a compatible way since 2.29\nor 2.30.\n\n> Then again cloning a repository uses the correct hash which means if I\n> create the repository on the forge and clone it there is no problem\n> whatsoever regardless of hash used. Whill that break as well?\n\nCloning a repository always uses the existing algorithm. The default\nwould change to create _new_ repositories created with `git init` with\nSHA-256 (although you could change the settings to use SHA-1 instead),\nbut it wouldn't affect existing repositories.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"527740","messageId":"aN2uRCbajBhZT08V@fruit.crustytoothpaste.net","threadId":"64229","inReplyTo":"xmqqecrm1hs1.fsf@gitster.g","subject":"Re: When should we release Git 3.0?","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-10-01T22:42:12Z","receivedAt":"2025-10-01T22:42:14Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-10-01 at 20:36:14, Junio C Hamano wrote:\n> What is the recommended workflow if you have unpublished work,\n> written back in your private SHA-1 clone of a project, meant to be\n> submit someday to your project, that used to use SHA-1 but has\n> migrated to SHA-256? Convert locally your repository to SHA-256\n> primary with SHA-1 compat and then push to them?\n\nWe don't have support to add an algorithm to an existing repository\n(although that is a desired feature). If that existed, you could add\nSHA-256 as a compatibility algorithm to your SHA-1 repository and push,\nor in any interoperability scenario, you could create a SHA-1 main\nremote with SHA-256 compatibility, push your changes there, and then\npush from there to the server.\n\nThe interoperability work requires that the client support the server's\nmain algorithm for pushes. This is because with protocol v2, the client\ngets a capability advertisement with supported algorithms and can choose\none for the operation. With protocol v0, the server sends capabilities\nas a read-only (GET) operation along with the refs and doesn't allow the\nalgorithm to be chosen, so it's impossible to get a ref advertisement in\nanything but the main algorithm. Since protocol v2 doesn't support\npushes, we can only push things in the server's main algorithm.\n\nFor the avoidance of doubt, I have no intention of adding support for\nprotocol v2 for pushes. That would be a nice feature and it would allow\nlifting that restriction, but I also have a responsibility to myself to\nnot explode the scope of this project more than it already has.\n\n> Presumably the server side _has_ already done most of the conversion\n> work so, provided if (and this is a huge if) we assume that the\n> conversion done on the server side is trustable, we should be able\n> to _clone_ from the server in SHA-256 primary SHA-1 compat mode, and\n> push your unpublished changes from your SHA-1 private repository\n> into this clone using SHA-1 protocol (i.e. no conversion to the\n> original repository)? And upon accepting such a push, the receiving\n> repository (which is still a local clone of the project, but the one\n> you recently made and is aware of SHA-256 world) would now have your\n> unpublished work in SHA-256 (with SHA-1 compat) objects and everybody\n> is happy?\n\nWe always use only one algorithm in the protocol except when we need to\nmap shallows, objects missing in a partial clone, or submodules, in\nwhich case we offer a mapping of those objects only. The mapping is\nalways otherwise done on the client side if the client supports both\nalgorithms.\n\nYou can create a SHA-256/SHA-1 clone from the server (right now via\ninitializing a SHA-256 repo, adding SHA-1 manually, and then fetching)\nand _pull_ your changes from your SHA-1 repo, though. (Pushing from\nSHA-1 into a SHA-256/SHA-1 clone doesn't work as I mentioned above.) You\ncould then push to the SHA-256 server.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"527795","messageId":"aN5sVXNdW8-GSMAE@kitsune.suse.cz","threadId":"64229","inReplyTo":"aN2oSBz8s_hSBMPq@fruit.crustytoothpaste.net","subject":"Re: When should we release Git 3.0?","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2025-10-02T12:13:09Z","receivedAt":"2025-10-02T12:13:13Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Wed, Oct 01, 2025 at 10:16:40PM +0000, brian m. carlson wrote:\n> On 2025-10-01 at 16:20:05, Michal Suchánek wrote:\n> > From my very limited point of view as a user the interop is the major\n> > planned feature currently missing in git, and I do not see much point\n> > without it. Then again I do not know how useful it will be in practice.\n> \n> It is the major planned feature which was missing.\n> \n> The primary use cases are converting repositories and working with\n> repositories using a different algorithm. The latter might be useful if\n> you're using a SHA-256 repository that someone else has created but your\n> tooling cannot handle longer object IDs or otherwise has some limitation\n> of that sort.\n\nIt cannot, and the compat will not help with that because it's using\npygit which will not get that compat code. Presumably some baroque\nscheme that re-exports the repository as sha1 might be possible but it's\nnot clear if that would be practical.\n\nAnother problem people are comlaining about is that with a mix of sha1\nand sha256 repositories submodules and subtrees don't work. For that the\ncompat might actually help but the repository will then be\nunintelligible to tooling that does not have compat code, which probably\nincludes all forges at this point. Again, some baroque scheme that\nre-exports the repository in the other hash using the compat code might\nhelp but it's not clear if that would be practical.\n\nThanks\n\nMichal\n"},{"id":"527796","messageId":"aN55oCWX1l_VUuNh@kitsune.suse.cz","threadId":"64229","inReplyTo":"aN5sVXNdW8-GSMAE@kitsune.suse.cz","subject":"Re: When should we release Git 3.0?","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2025-10-02T13:09:52Z","receivedAt":"2025-10-02T13:09:55Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Thu, Oct 02, 2025 at 02:13:09PM +0200, Michal Suchánek wrote:\n> On Wed, Oct 01, 2025 at 10:16:40PM +0000, brian m. carlson wrote:\n> > On 2025-10-01 at 16:20:05, Michal Suchánek wrote:\n> > > From my very limited point of view as a user the interop is the major\n> > > planned feature currently missing in git, and I do not see much point\n> > > without it. Then again I do not know how useful it will be in practice.\n> > \n> > It is the major planned feature which was missing.\n> > \n> > The primary use cases are converting repositories and working with\n> > repositories using a different algorithm. The latter might be useful if\n> > you're using a SHA-256 repository that someone else has created but your\n> > tooling cannot handle longer object IDs or otherwise has some limitation\n> > of that sort.\n> \n> It cannot, and the compat will not help with that because it's using\n> pygit which will not get that compat code. Presumably some baroque\n> scheme that re-exports the repository as sha1 might be possible but it's\n> not clear if that would be practical.\n> \n> Another problem people are comlaining about is that with a mix of sha1\n> and sha256 repositories submodules and subtrees don't work. For that the\n> compat might actually help but the repository will then be\n> unintelligible to tooling that does not have compat code, which probably\n> includes all forges at this point. Again, some baroque scheme that\n> re-exports the repository in the other hash using the compat code might\n> help but it's not clear if that would be practical.\n\nI would assume the compat client could upload the same repository to\nboth sha256 forge repository and sha1 forge repository. With some\nscripting it's possible to publish twice making both hashes available.\nPeople that have a compat-capable client then would see the repositories\nas identical again on their end.\n\nNot usable in every situation but for cases when mirroring is already\ndone anyway plugging this in sounds fairly straightforward.\n\nThanks\n\nMichal\n"},{"id":"527797","messageId":"aN5-n_ArhQqaQZgt@pks.im","threadId":"64229","inReplyTo":"aN1RFvz7uGPnepxe@nand.local","subject":"Re: When should we release Git 3.0?","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-10-02T13:31:11Z","receivedAt":"2025-10-02T13:31:22Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Wed, Oct 01, 2025 at 12:04:38PM -0400, Taylor Blau wrote:\n> On Wed, Oct 01, 2025 at 08:13:12AM +0100, Luca Milanesio wrote:\n> > I am worried that if we rush into Git 3.0 with breaking changes that\n> > would make other “forges” (e.g. JGit) incompatible, we would be in a\n> > difficult situation with the other Git ecosystem that isn’t based on\n> > the C-Git implementation.\n> \n> That's a good point. I am not familiar enough with JGit (or really any\n> non-standard Git implementations) to know where SHA-256 support is in\n> those respective implementations.\n> \n> But regardless of whether we're talking about a forge that is based on\n> git.git or some other implementation, there is very likely lots of other\n> work to be done to support SHA-256 outside of flipping the hash function\n> within Git.\n> \n> (I'm thinking here about database migrations for columns that may store\n> 40-character SHA-1 hashes, for example, which can take a potentially\n> significant amount of time to migrate depending on the size of the\n> database, etc.)\n> \n> So my feeling here is that we should take into account not just the\n> readiness of the underlying Git implementation used by hosting providers\n> in the Git ecosystem, but also the readiness of the hosting providers\n> themselves to do the work necessary to facilitate that transition\n> outside of their Git implementation.\n\nWe definitely should take into account the readiness. But what I think\nwe'll need is a roadmap from impacted Git implementations and hosting\nproviders so that we can answer the question when they plan to have\nSHA256 support ready.\n\nWithout such a roadmap it's basically impossible for us to set up any\nrealistic date. In that case, we only have one of two options:\n\n - We just wait until eventually everyone has SHA256 support. This has\n the effect that there is no pressure on anybody, and thus it is more\n likely than not that it'll just never happen.\n\n - We set a strict, \"uninformed\" deadline that may be too ambitious and\n unrealistic.\n\nOnce we have roadmaps, we should set a strict deadline that takes them\ninto account. Any hosting provider or implementation of Git that doesn't\nprovide a roadmap will not be taken into account in our planning.\n\nWe should of course actively reach out to the projects that we're aware\nof so that they have a chance to provide such a roadmap in the first\nplace.\n\nPatrick\n"},{"id":"527804","messageId":"xmqqfrc1xqsp.fsf@gitster.g","threadId":"64229","inReplyTo":"aN5-n_ArhQqaQZgt@pks.im","subject":"Re: When should we release Git 3.0?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-02T15:32:38Z","receivedAt":"2025-10-02T15:32:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt writes:\n\n> Once we have roadmaps, we should set a strict deadline that takes them\n> into account. Any hosting provider or implementation of Git that doesn't\n> provide a roadmap will not be taken into account in our planning.\n\nWorks fine as long as we assume everybody that matters will\neventually want to move away from SHA-1.\n\n - If a stakeholder gives a roadmap that has no SHA-256 in their\n future, in other words, if they are content to serve only the\n SHA-1 projects, what's the impact to them? We are not dropping\n the support for SHA-1 in the sense that if you clone from an\n existing SHA-1 repository you'll get an SHA-1 repository and you\n can push and fetch between them just fine, so presumably that is\n fine as well.\n\n - If a stakeholder gives a roadmap with SHA-256 so far into the\n future that we cannot wait, what's the impact to them? Their\n customers that want SHA-256 earlier than they can supply could\n move to other hosting or implementation, but not really. Both\n hosting providers and Git implementations have components that\n are move than Git that are hard to migrate, like issue trackers,\n CI services, workflow tools, etc., that make their customers\n captive audience [*].\n\n - If a stakeholder has a roadmap with SHA-256 in line with our\n timeframe, do we still need to assess the impact to them, or as\n long as we and they work hard to stick to the plan, we all will\n be happy?\n\n> We should of course actively reach out to the projects that we're aware\n> of so that they have a chance to provide such a roadmap in the first\n> place.\n\n\n[Footnote]\n\n * Issue trackers and review logs that are federated, possibly using\n Git database for storage and transfer, may allow projects and\n users to freely roam across hosting sites, but there is no strong\n incentive for the hosting sites to fund such an effort X-<.\n"},{"id":"527809","messageId":"aN6j7giOosGreKUW@kitsune.suse.cz","threadId":"64229","inReplyTo":"xmqqfrc1xqsp.fsf@gitster.g","subject":"Re: When should we release Git 3.0?","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2025-10-02T16:10:22Z","receivedAt":"2025-10-02T16:10:26Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Thu, Oct 02, 2025 at 08:32:38AM -0700, Junio C Hamano wrote:\n> Patrick Steinhardt writes:\n> \n> > Once we have roadmaps, we should set a strict deadline that takes them\n> > into account. Any hosting provider or implementation of Git that doesn't\n> > provide a roadmap will not be taken into account in our planning.\n> \n> Works fine as long as we assume everybody that matters will\n> eventually want to move away from SHA-1.\n> \n> - If a stakeholder gives a roadmap that has no SHA-256 in their\n> future, in other words, if they are content to serve only the\n> SHA-1 projects, what's the impact to them? We are not dropping\n> the support for SHA-1 in the sense that if you clone from an\n> existing SHA-1 repository you'll get an SHA-1 repository and you\n> can push and fetch between them just fine, so presumably that is\n> fine as well.\n> \n> - If a stakeholder gives a roadmap with SHA-256 so far into the\n> future that we cannot wait, what's the impact to them? Their\n> customers that want SHA-256 earlier than they can supply could\n> move to other hosting or implementation, but not really. Both\n\nI suppose that's already the case to some extent. git does support\nsha256, some forges do as well, and some people want it to the point\nthat they install such forge, and create the sha256 repositories\nalthough it is not the default.\n\nThere is some tradeoff here. When it's nice to have but not required\npeople will use it when convenient. When it's really required people\nwill use even an obscure implementation to get the requested feature.\n\n> hosting providers and Git implementations have components that\n> are move than Git that are hard to migrate, like issue trackers,\n> CI services, workflow tools, etc., that make their customers\n> captive audience [*].\n> \n> - If a stakeholder has a roadmap with SHA-256 in line with our\n> timeframe, do we still need to assess the impact to them, or as\n> long as we and they work hard to stick to the plan, we all will\n> be happy?\n> \n> > We should of course actively reach out to the projects that we're aware\n> > of so that they have a chance to provide such a roadmap in the first\n> > place.\n> \n> \n> [Footnote]\n> \n> * Issue trackers and review logs that are federated, possibly using\n> Git database for storage and transfer, may allow projects and\n> users to freely roam across hosting sites, but there is no strong\n> incentive for the hosting sites to fund such an effort X-<.\n\nMany forges provide migration options for importing data from other\nforges for which there is incentive, with various level of completeness\nand reliability. Another thing that contributes to lock-in is network\neffect of popular forges.\n\nThanks\n\nMichal\n"},{"id":"527813","messageId":"D59D0576-63C9-4144-B49E-54D43A80E0B0@gmail.com","threadId":"64229","inReplyTo":"aN5-n_ArhQqaQZgt@pks.im","subject":"Re: When should we release Git 3.0?","fromName":"Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-10-02T16:54:13Z","receivedAt":"2025-10-02T16:54:25Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"\n> Le 2 oct. 2025 à 09:33, Patrick Steinhardt a écrit :\n> \n> On Wed, Oct 01, 2025 at 12:04:38PM -0400, Taylor Blau wrote:\n>> \n>> \n>> So my feeling here is that we should take into account not just the\n>> readiness of the underlying Git implementation used by hosting providers\n>> in the Git ecosystem, but also the readiness of the hosting providers\n>> themselves to do the work necessary to facilitate that transition\n>> outside of their Git implementation.\n> \n> We definitely should take into account the readiness. But what I think\n> we'll need is a roadmap from impacted Git implementations and hosting\n> providers so that we can answer the question when they plan to have\n> SHA256 support ready.\n> \n> Without such a roadmap it's basically impossible for us to set up any\n> realistic date. In that case, we only have one of two options:\n> \n> - We just wait until eventually everyone has SHA256 support. This has\n> the effect that there is no pressure on anybody, and thus it is more\n> likely than not that it'll just never happen.\n> \n> - We set a strict, \"uninformed\" deadline that may be too ambitious and\n> unrealistic.\n\nThis seems like a false dichotomy to me. Of course we can forever debate options to go forward, too, so at some point we must have a decision :)\n\nAnyway, what about establishing a strong but adjustable (“proposed”) timeline now, based on informed opinions from folks who have already provided estimates of what’s required? Then we can shop around for input on the proposed deadline while still taking into account new information. \n\nIt also provides impetus: “sans input, we will go forward with the proposal, so let us know if you need more time” might motivate folks to firm up their own timelines and provide said input.\n\n> Once we have roadmaps, we should set a strict deadline that takes them\n> into account. Any hosting provider or implementation of Git that doesn't\n> provide a roadmap will not be taken into account in our planning.\n\nBtw, I’ve often wondered since I see representatives from GitHub/GitLab (and JGit/Gerrit to a lesser extent) often prominently identified as such: do we have folks from GitTea/SourceHut/other smaller forges around on the mailing list to weigh in? I assume we’d also like to include their input."},{"id":"527841","messageId":"aN7917RSHBz3IV5o@fruit.crustytoothpaste.net","threadId":"64229","inReplyTo":"E03F997F-1738-4CF6-B7D5-206183FA5BD1@gmail.com","subject":"Re: When should we release Git 3.0?","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-10-02T22:33:59Z","receivedAt":"2025-10-02T22:34:01Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-10-01 at 07:13:12, Luca Milanesio wrote:\n> > I personally do not want the interoperability work to be a blocker. I\n> > haven't really heard other commitments of contributors who want to work\n> > on it and I don't really want to have to run full tilt trying to get it\n> > out. However, some other people may feel differently, in which I case I\n> > encourage their participation in the project.\n> \n> Sure, happy to participate.\n\nFantastic. If you're interested, you can get the current state of the\nproject from the `sha256-interop` branch at\nhttps://github.com/bk2204/git.git. This is frequently rebased, but\nmostly to squash down patches or add new features. It is based on v7 of\nPatrick Steinhardt's Rust series and will effectively require\n`WITH_RUST=1` to function.\n\nOne really valuable thing that you could work on if you like is a tool\nto do in-place migration of repositories to add a compatibility\nalgorithm, so SHA-1 repositories would have SHA-256 compatibility added\non top. That might look like this:\n\n* Recursively convert submodules, if any.\n* Build a loose object map for any submodule commits that exist in the\n history.\n* Repack all the loose objects into a pack (including using a cruft pack\n if necessary).\n* Regenerate the indexes for the pack using pack index v3.\n\nThis might be a good subcommand for something like a `git hash`\ncommand, maybe `git hash convert`. We'd probably want to anticipate\nmaybe in the future having a mode that converts the main algorithm, too,\nalthough that need not be implemented now.\n\nYou should be able to test this end-to-end with Git's repository, since\nit has submodules.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"528062","messageId":"aOTrBAXhKF4iYzQB@pks.im","threadId":"64229","inReplyTo":"D59D0576-63C9-4144-B49E-54D43A80E0B0@gmail.com","subject":"Re: When should we release Git 3.0?","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-10-07T10:27:16Z","receivedAt":"2025-10-07T10:27:22Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Thu, Oct 02, 2025 at 12:54:13PM -0400, Ben Knoble wrote:\n> \n> > Le 2 oct. 2025 à 09:33, Patrick Steinhardt a écrit :\n> > \n> > On Wed, Oct 01, 2025 at 12:04:38PM -0400, Taylor Blau wrote:\n> >> \n> >> \n> >> So my feeling here is that we should take into account not just the\n> >> readiness of the underlying Git implementation used by hosting providers\n> >> in the Git ecosystem, but also the readiness of the hosting providers\n> >> themselves to do the work necessary to facilitate that transition\n> >> outside of their Git implementation.\n> > \n> > We definitely should take into account the readiness. But what I think\n> > we'll need is a roadmap from impacted Git implementations and hosting\n> > providers so that we can answer the question when they plan to have\n> > SHA256 support ready.\n> > \n> > Without such a roadmap it's basically impossible for us to set up any\n> > realistic date. In that case, we only have one of two options:\n> > \n> > - We just wait until eventually everyone has SHA256 support. This has\n> > the effect that there is no pressure on anybody, and thus it is more\n> > likely than not that it'll just never happen.\n> > \n> > - We set a strict, \"uninformed\" deadline that may be too ambitious and\n> > unrealistic.\n> \n> This seems like a false dichotomy to me. Of course we can forever\n> debate options to go forward, too, so at some point we must have a\n> decision :)\n> \n> Anyway, what about establishing a strong but adjustable (“proposed”)\n> timeline now, based on informed opinions from folks who have already\n> provided estimates of what’s required? Then we can shop around for\n> input on the proposed deadline while still taking into account new\n> information. \n> \n> It also provides impetus: “sans input, we will go forward with the\n> proposal, so let us know if you need more time” might motivate folks\n> to firm up their own timelines and provide said input.\n\nYeah, it's definitely my goal here to do exactly that: reach out to\nfolks and take everyone's input into account. Once we've got it, propose\na timeline.\n\nI guess as part of that initial communication with the stakeholders we\ncan also mention that the current plan is to release roughly towards the\nend of next year, which may help to put things into perspective.\n\n> > Once we have roadmaps, we should set a strict deadline that takes them\n> > into account. Any hosting provider or implementation of Git that doesn't\n> > provide a roadmap will not be taken into account in our planning.\n> \n> Btw, I’ve often wondered since I see representatives from\n> GitHub/GitLab (and JGit/Gerrit to a lesser extent) often prominently\n> identified as such: do we have folks from GitTea/SourceHut/other\n> smaller forges around on the mailing list to weigh in? I assume we’d\n> also like to include their input.\n\nSuch smaller forges should definitely be included. My plan is to gather\na list of stakeholders for now and then send an email where we Cc\nmaintainers of such implementations.\n\nPatrick\n"},{"id":"528063","messageId":"aOTrC8CRZm5hERgr@pks.im","threadId":"64229","inReplyTo":"aN6j7giOosGreKUW@kitsune.suse.cz","subject":"Re: When should we release Git 3.0?","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-10-07T10:27:23Z","receivedAt":"2025-10-07T10:27:29Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Thu, Oct 02, 2025 at 06:10:22PM +0200, Michal Suchánek wrote:\n> On Thu, Oct 02, 2025 at 08:32:38AM -0700, Junio C Hamano wrote:\n> > Patrick Steinhardt writes:\n> > \n> > > Once we have roadmaps, we should set a strict deadline that takes them\n> > > into account. Any hosting provider or implementation of Git that doesn't\n> > > provide a roadmap will not be taken into account in our planning.\n> > \n> > Works fine as long as we assume everybody that matters will\n> > eventually want to move away from SHA-1.\n> > \n> > - If a stakeholder gives a roadmap that has no SHA-256 in their\n> > future, in other words, if they are content to serve only the\n> > SHA-1 projects, what's the impact to them? We are not dropping\n> > the support for SHA-1 in the sense that if you clone from an\n> > existing SHA-1 repository you'll get an SHA-1 repository and you\n> > can push and fetch between them just fine, so presumably that is\n> > fine as well.\n> > \n> > - If a stakeholder gives a roadmap with SHA-256 so far into the\n> > future that we cannot wait, what's the impact to them? Their\n> > customers that want SHA-256 earlier than they can supply could\n> > move to other hosting or implementation, but not really. Both\n> \n> I suppose that's already the case to some extent. git does support\n> sha256, some forges do as well, and some people want it to the point\n> that they install such forge, and create the sha256 repositories\n> although it is not the default.\n> \n> There is some tradeoff here. When it's nice to have but not required\n> people will use it when convenient. When it's really required people\n> will use even an obscure implementation to get the requested feature.\n\nTrue. In any case, I think that for now we should just wait how such\nroadmaps would look like and then discuss based on the findings.\n\nThe question of course is how to get such roadmaps. The easiest way to\ndo it is probably to gather a list of known projects that would be\nimpacted and just shoot maintainers or representatives of those an\nemail? From the top of my head, that would include:\n\n - Implementations\n - libgit2\n - JGit\n - Gitoxide\n - go-git\n - Forges\n - GitHub\n - GitLab\n - Bitbucket\n - Forgejo\n - SourceHut\n\nI probably missed some stakeholders here, so please help me fill in the\nblanks.\n\n> > hosting providers and Git implementations have components that\n> > are move than Git that are hard to migrate, like issue trackers,\n> > CI services, workflow tools, etc., that make their customers\n> > captive audience [*].\n> > \n> > - If a stakeholder has a roadmap with SHA-256 in line with our\n> > timeframe, do we still need to assess the impact to them, or as\n> > long as we and they work hard to stick to the plan, we all will\n> > be happy?\n\nWell, the impact in that case would be negligible, I assume, so everyone\nwoudl be happy. If plans change then we can of course also adapt our own\ntimeline a bit, at least as long as they would give us a notification\nwell ahead of the scheduled flag day.\n\nPatrick\n"},{"id":"528064","messageId":"aOTtPxsdzJLPCruk@kitsune.suse.cz","threadId":"64229","inReplyTo":"aOTrC8CRZm5hERgr@pks.im","subject":"Re: When should we release Git 3.0?","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2025-10-07T10:36:47Z","receivedAt":"2025-10-07T10:36:51Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Tue, Oct 07, 2025 at 12:27:23PM +0200, Patrick Steinhardt wrote:\n> On Thu, Oct 02, 2025 at 06:10:22PM +0200, Michal Suchánek wrote:\n> > On Thu, Oct 02, 2025 at 08:32:38AM -0700, Junio C Hamano wrote:\n> > > Patrick Steinhardt writes:\n> > > \n> > > > Once we have roadmaps, we should set a strict deadline that takes them\n> > > > into account. Any hosting provider or implementation of Git that doesn't\n> > > > provide a roadmap will not be taken into account in our planning.\n> > > \n> > > Works fine as long as we assume everybody that matters will\n> > > eventually want to move away from SHA-1.\n> > > \n> > > - If a stakeholder gives a roadmap that has no SHA-256 in their\n> > > future, in other words, if they are content to serve only the\n> > > SHA-1 projects, what's the impact to them? We are not dropping\n> > > the support for SHA-1 in the sense that if you clone from an\n> > > existing SHA-1 repository you'll get an SHA-1 repository and you\n> > > can push and fetch between them just fine, so presumably that is\n> > > fine as well.\n> > > \n> > > - If a stakeholder gives a roadmap with SHA-256 so far into the\n> > > future that we cannot wait, what's the impact to them? Their\n> > > customers that want SHA-256 earlier than they can supply could\n> > > move to other hosting or implementation, but not really. Both\n> > \n> > I suppose that's already the case to some extent. git does support\n> > sha256, some forges do as well, and some people want it to the point\n> > that they install such forge, and create the sha256 repositories\n> > although it is not the default.\n> > \n> > There is some tradeoff here. When it's nice to have but not required\n> > people will use it when convenient. When it's really required people\n> > will use even an obscure implementation to get the requested feature.\n> \n> True. In any case, I think that for now we should just wait how such\n> roadmaps would look like and then discuss based on the findings.\n> \n> The question of course is how to get such roadmaps. The easiest way to\n> do it is probably to gather a list of known projects that would be\n> impacted and just shoot maintainers or representatives of those an\n> email? From the top of my head, that would include:\n> \n> - Implementations\n> - libgit2\n - pygit2\n> - JGit\n> - Gitoxide\n> - go-git\n> - Forges\n> - GitHub\n> - GitLab\n> - Bitbucket\n> - Forgejo\n - Gitea\n> - SourceHut\n\nThanks\n\nMichal\n"},{"id":"528114","messageId":"aOUT2Phklc_ZDhy9@pks.im","threadId":"64229","inReplyTo":"aOTtPxsdzJLPCruk@kitsune.suse.cz","subject":"Re: When should we release Git 3.0?","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-10-07T13:21:28Z","receivedAt":"2025-10-07T13:21:34Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Tue, Oct 07, 2025 at 12:36:47PM +0200, Michal Suchánek wrote:\n> On Tue, Oct 07, 2025 at 12:27:23PM +0200, Patrick Steinhardt wrote:\n> > The question of course is how to get such roadmaps. The easiest way to\n> > do it is probably to gather a list of known projects that would be\n> > impacted and just shoot maintainers or representatives of those an\n> > email? From the top of my head, that would include:\n> > \n> > - Implementations\n> > - libgit2\n> - pygit2\n> > - JGit\n> > - Gitoxide\n> > - go-git\n\npygit2 is merely a binding for libgit2, so I didn't include it in this\nlist. Same for other bindings like git2go or git2-rs.\n\n> > - Forges\n> > - GitHub\n> > - GitLab\n> > - Bitbucket\n> > - Forgejo\n> - Gitea\n> > - SourceHut\n\nYup, this one should be included here indeed.\n\nThanks!\n\nPatrick\n"},{"id":"528117","messageId":"aOUYNPD1o2_d0xYy@kitsune.suse.cz","threadId":"64229","inReplyTo":"aOUT2Phklc_ZDhy9@pks.im","subject":"Re: When should we release Git 3.0?","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2025-10-07T13:40:04Z","receivedAt":"2025-10-07T13:40:06Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Tue, Oct 07, 2025 at 03:21:28PM +0200, Patrick Steinhardt wrote:\n> On Tue, Oct 07, 2025 at 12:36:47PM +0200, Michal Suchánek wrote:\n> > On Tue, Oct 07, 2025 at 12:27:23PM +0200, Patrick Steinhardt wrote:\n> > > The question of course is how to get such roadmaps. The easiest way to\n> > > do it is probably to gather a list of known projects that would be\n> > > impacted and just shoot maintainers or representatives of those an\n> > > email? From the top of my head, that would include:\n> > > \n> > > - Implementations\n> > > - libgit2\n> > - pygit2\n> > > - JGit\n> > > - Gitoxide\n> > > - go-git\n> \n> pygit2 is merely a binding for libgit2, so I didn't include it in this\n> list. Same for other bindings like git2go or git2-rs.\n\nUnfortunately, bindings do not automatically get the features of the\nlibrary they wrap. AFAIK libgit2 has experimental sha256 support and\npygit2 has none whatsoever. Altering the bindings to include sha256\nsupport may involve significant design work. The native API may differ\nsignificantly from the C API.\n\nBoth API may get broken as a result. That is pygit2 and libgit2 may\nnever get support, and we would need libgit3/pygit3 instead, or it may\nvary depending on the language.\n\nThanks\n\nMichal\n"},{"id":"528136","messageId":"xmqqv7kqk56r.fsf@gitster.g","threadId":"64229","inReplyTo":"aOUT2Phklc_ZDhy9@pks.im","subject":"Re: When should we release Git 3.0?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-07T17:11:24Z","receivedAt":"2025-10-07T17:11:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt writes:\n\n> On Tue, Oct 07, 2025 at 12:36:47PM +0200, Michal Suchánek wrote:\n>> On Tue, Oct 07, 2025 at 12:27:23PM +0200, Patrick Steinhardt wrote:\n>> > The question of course is how to get such roadmaps. The easiest way to\n>> > do it is probably to gather a list of known projects that would be\n>> > impacted and just shoot maintainers or representatives of those an\n>> > email? From the top of my head, that would include:\n>> > \n>> > - Implementations\n>> > - libgit2\n>> - pygit2\n>> > - JGit\n>> > - Gitoxide\n>> > - go-git\n>\n> pygit2 is merely a binding for libgit2, so I didn't include it in this\n> list. Same for other bindings like git2go or git2-rs.\n\nIs dulwich still alive?\n\n>\n>> > - Forges\n>> > - GitHub\n>> > - GitLab\n>> > - Bitbucket\n>> > - Forgejo\n>> - Gitea\n>> > - SourceHut\n>\n> Yup, this one should be included here indeed.\n>\n> Thanks!\n>\n> Patrick\n"},{"id":"528142","messageId":"aOVNozn-ycPoLf2p@kitsune.suse.cz","threadId":"64229","inReplyTo":"xmqqv7kqk56r.fsf@gitster.g","subject":"Re: When should we release Git 3.0?","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2025-10-07T17:28:03Z","receivedAt":"2025-10-07T17:28:06Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Tue, Oct 07, 2025 at 10:11:24AM -0700, Junio C Hamano wrote:\n> Patrick Steinhardt writes:\n> \n> > On Tue, Oct 07, 2025 at 12:36:47PM +0200, Michal Suchánek wrote:\n> >> On Tue, Oct 07, 2025 at 12:27:23PM +0200, Patrick Steinhardt wrote:\n> >> > The question of course is how to get such roadmaps. The easiest way to\n> >> > do it is probably to gather a list of known projects that would be\n> >> > impacted and just shoot maintainers or representatives of those an\n> >> > email? From the top of my head, that would include:\n> >> > \n> >> > - Implementations\n> >> > - libgit2\n> >> - pygit2\n> >> > - JGit\n> >> > - Gitoxide\n> >> > - go-git\n> >\n> > pygit2 is merely a binding for libgit2, so I didn't include it in this\n> > list. Same for other bindings like git2go or git2-rs.\n> \n> Is dulwich still alive?\n\nInteresting, did not know it exists (also abysmal SEO, not surprising).\n\nIts web page seems unmaintained but the git repository looks alive.\n\nThanks\n\nMichal\n\n> \n> >\n> >> > - Forges\n> >> > - GitHub\n> >> > - GitLab\n> >> > - Bitbucket\n> >> > - Forgejo\n> >> - Gitea\n> >> > - SourceHut\n> >\n> > Yup, this one should be included here indeed.\n> >\n> > Thanks!\n> >\n> > Patrick\n"},{"id":"528144","messageId":"00ff01dc37b0$e5bfb430$b13f1c90$@nexbridge.com","threadId":"64229","inReplyTo":"aOTrBAXhKF4iYzQB@pks.im","subject":"RE: When should we release Git 3.0?","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-10-07T17:36:16Z","receivedAt":"2025-10-07T17:36:33Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On October 7, 2025 6:27 AM, Patrick Steinhardt wrote:\n>On Thu, Oct 02, 2025 at 12:54:13PM -0400, Ben Knoble wrote:\n>>\n>> > Le 2 oct. 2025 à 09:33, Patrick Steinhardt a écrit :\n>> >\n>> > On Wed, Oct 01, 2025 at 12:04:38PM -0400, Taylor Blau wrote:\n>> >>\n>> >>\n>> >> So my feeling here is that we should take into account not just the\n>> >> readiness of the underlying Git implementation used by hosting\n>> >> providers in the Git ecosystem, but also the readiness of the\n>> >> hosting providers themselves to do the work necessary to facilitate\n>> >> that transition outside of their Git implementation.\n>> >\n>> > We definitely should take into account the readiness. But what I\n>> > think we'll need is a roadmap from impacted Git implementations and\n>> > hosting providers so that we can answer the question when they plan\n>> > to have\n>> > SHA256 support ready.\n>> >\n>> > Without such a roadmap it's basically impossible for us to set up\n>> > any realistic date. In that case, we only have one of two options:\n>> >\n>> > - We just wait until eventually everyone has SHA256 support. This has\n>> > the effect that there is no pressure on anybody, and thus it is more\n>> > likely than not that it'll just never happen.\n>> >\n>> > - We set a strict, \"uninformed\" deadline that may be too ambitious and\n>> > unrealistic.\n>>\n>> This seems like a false dichotomy to me. Of course we can forever\n>> debate options to go forward, too, so at some point we must have a\n>> decision :)\n>>\n>> Anyway, what about establishing a strong but adjustable (“proposed”)\n>> timeline now, based on informed opinions from folks who have already\n>> provided estimates of what’s required? Then we can shop around for\n>> input on the proposed deadline while still taking into account new\n>> information.\n>>\n>> It also provides impetus: “sans input, we will go forward with the\n>> proposal, so let us know if you need more time” might motivate folks\n>> to firm up their own timelines and provide said input.\n>\n>Yeah, it's definitely my goal here to do exactly that: reach out to folks and take\n>everyone's input into account. Once we've got it, propose a timeline.\n\nMy own blocking situation is a lack of Rust. This is being discussed by the OS\nvendor and I hope we get some progress soon. I do not control what \"soon\" is\nbut it is at least a year. This is HPE NonStop.\n\n>I guess as part of that initial communication with the stakeholders we can also\n>mention that the current plan is to release roughly towards the end of next year,\n>which may help to put things into perspective.\n>\n>> > Once we have roadmaps, we should set a strict deadline that takes\n>> > them into account. Any hosting provider or implementation of Git\n>> > that doesn't provide a roadmap will not be taken into account in our planning.\n>>\n>> Btw, I’ve often wondered since I see representatives from\n>> GitHub/GitLab (and JGit/Gerrit to a lesser extent) often prominently\n>> identified as such: do we have folks from GitTea/SourceHut/other\n>> smaller forges around on the mailing list to weigh in? I assume we’d\n>> also like to include their input.\n>\n>Such smaller forges should definitely be included. My plan is to gather a list of\n>stakeholders for now and then send an email where we Cc maintainers of such\n>implementations.\n\nMy own front-end implementation has been ready for SHA-256 for 2 years and\nhave been (im)patiently waiting. I have a distinct separation between git version\nand implementation so there is no direct dependency there. Only Rust availability\non the git built is holding my own situation back.\n--Randall\n\n"},{"id":"528311","messageId":"aObNPk8ily0EFNxM@szeder.dev","threadId":"64229","inReplyTo":"aOTrC8CRZm5hERgr@pks.im","subject":"Re: When should we release Git 3.0?","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2025-10-08T20:44:46Z","receivedAt":"2025-10-08T20:44:54Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Tue, Oct 07, 2025 at 12:27:23PM +0200, Patrick Steinhardt wrote:\n> The question of course is how to get such roadmaps. The easiest way to\n> do it is probably to gather a list of known projects that would be\n> impacted and just shoot maintainers or representatives of those an\n> email? From the top of my head, that would include:\n> \n> - Implementations\n> - libgit2\n> - JGit\n> - Gitoxide\n> - go-git\n> - Forges\n> - GitHub\n> - GitLab\n> - Bitbucket\n> - Forgejo\n> - SourceHut\n\ncodeberg.org\n\n"},{"id":"528332","messageId":"aObbWLBCbXsvuajS@nand.local","threadId":"64229","inReplyTo":"04f501dc330a$0ecd3010$2c679030$@nexbridge.com","subject":"Re: When should we release Git 3.0?","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2025-10-08T21:44:56Z","receivedAt":"2025-10-08T21:44:58Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Wed, Oct 01, 2025 at 03:31:54PM -0400, rsbecker@nexbridge.com wrote:\n> On October 1, 2025 12:05 PM, Taylor Blau wrote:\n> >On Wed, Oct 01, 2025 at 08:13:12AM +0100, Luca Milanesio wrote:\n> >> I am worried that if we rush into Git 3.0 with breaking changes that\n> >> would make other “forges” (e.g. JGit) incompatible, we would be in a\n> >> difficult situation with the other Git ecosystem that isn’t based on\n> >> the C-Git implementation.\n> >\n> >That's a good point. I am not familiar enough with JGit (or really any non-standard\n> >Git implementations) to know where SHA-256 support is in those respective\n> >implementations.\n>\n> AFAIK, JGit still depends on some core git functions, including gc. It\n> also depends on LFS for those functions. Interop it fairly important\n> in that space.\n\nWhat are \"core git functions\" here? I'm not at all familiar with JGit,\nbut my understanding is that it doesn't use the Git binary directly\nwhatsoever, so I am not sure how the presence of interop support or not\nwould affect JGit or LFS.\n\nThanks,\nTaylor\n"},{"id":"528335","messageId":"020a01dc389e$370c3f50$a524bdf0$@nexbridge.com","threadId":"64229","inReplyTo":"aObbWLBCbXsvuajS@nand.local","subject":"RE: When should we release Git 3.0?","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-10-08T21:55:03Z","receivedAt":"2025-10-08T21:55:12Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On October 8, 2025 5:45 PM, Taylor Blau wrote:\n>On Wed, Oct 01, 2025 at 03:31:54PM -0400, rsbecker@nexbridge.com wrote:\n>> On October 1, 2025 12:05 PM, Taylor Blau wrote:\n>> >On Wed, Oct 01, 2025 at 08:13:12AM +0100, Luca Milanesio wrote:\n>> >> I am worried that if we rush into Git 3.0 with breaking changes\n>> >> that would make other “forges” (e.g. JGit) incompatible, we would\n>> >> be in a difficult situation with the other Git ecosystem that isn’t\n>> >> based on the C-Git implementation.\n>> >\n>> >That's a good point. I am not familiar enough with JGit (or really\n>> >any non-standard Git implementations) to know where SHA-256 support\n>> >is in those respective implementations.\n>>\n>> AFAIK, JGit still depends on some core git functions, including gc. It\n>> also depends on LFS for those functions. Interop it fairly important\n>> in that space.\n>\n>What are \"core git functions\" here? I'm not at all familiar with JGit, but my\n>understanding is that it doesn't use the Git binary directly whatsoever, so I am not\n>sure how the presence of interop support or not would affect JGit or LFS.\n\nI tried doing a JGit gc. It delegates to git. There are other functions.\n\n"},{"id":"528338","messageId":"aObep4lUP8hcWXxG@nand.local","threadId":"64229","inReplyTo":"aN5-n_ArhQqaQZgt@pks.im","subject":"Re: When should we release Git 3.0?","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2025-10-08T21:59:03Z","receivedAt":"2025-10-08T21:59:05Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Thu, Oct 02, 2025 at 03:31:11PM +0200, Patrick Steinhardt wrote:\n> On Wed, Oct 01, 2025 at 12:04:38PM -0400, Taylor Blau wrote:\n> > On Wed, Oct 01, 2025 at 08:13:12AM +0100, Luca Milanesio wrote:\n> > > I am worried that if we rush into Git 3.0 with breaking changes that\n> > > would make other “forges” (e.g. JGit) incompatible, we would be in a\n> > > difficult situation with the other Git ecosystem that isn’t based on\n> > > the C-Git implementation.\n> >\n> > That's a good point. I am not familiar enough with JGit (or really any\n> > non-standard Git implementations) to know where SHA-256 support is in\n> > those respective implementations.\n> >\n> > But regardless of whether we're talking about a forge that is based on\n> > git.git or some other implementation, there is very likely lots of other\n> > work to be done to support SHA-256 outside of flipping the hash function\n> > within Git.\n> >\n> > (I'm thinking here about database migrations for columns that may store\n> > 40-character SHA-1 hashes, for example, which can take a potentially\n> > significant amount of time to migrate depending on the size of the\n> > database, etc.)\n> >\n> > So my feeling here is that we should take into account not just the\n> > readiness of the underlying Git implementation used by hosting providers\n> > in the Git ecosystem, but also the readiness of the hosting providers\n> > themselves to do the work necessary to facilitate that transition\n> > outside of their Git implementation.\n>\n> We definitely should take into account the readiness. But what I think\n> we'll need is a roadmap from impacted Git implementations and hosting\n> providers so that we can answer the question when they plan to have\n> SHA256 support ready.\n>\n> Without such a roadmap it's basically impossible for us to set up any\n> realistic date. In that case, we only have one of two options:\n>\n> - We just wait until eventually everyone has SHA256 support. This has\n> the effect that there is no pressure on anybody, and thus it is more\n> likely than not that it'll just never happen.\n>\n> - We set a strict, \"uninformed\" deadline that may be too ambitious and\n> unrealistic.\n>\n> Once we have roadmaps, we should set a strict deadline that takes them\n> into account. Any hosting provider or implementation of Git that doesn't\n> provide a roadmap will not be taken into account in our planning.\n\nI would imagine that the definition of \"roadmap\" here is fairly\nlightweight, since I imagine that some organizations may not want to\nshare details beyond \"we will have it done by X date\".\n\nI think I generally agree with you, but I would say that while I think\nthe project should take a firm stance on when it will release Git 3.0, I\ndo not think that we should entirely disregard the readiness of\nforges/implementations by making the deadline so strict.\n\nThanks,\nTaylor\n"},{"id":"528341","messageId":"aObgEGjcou06nP68@nand.local","threadId":"64229","inReplyTo":"aOTrBAXhKF4iYzQB@pks.im","subject":"Re: When should we release Git 3.0?","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2025-10-08T22:05:04Z","receivedAt":"2025-10-08T22:05:07Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Tue, Oct 07, 2025 at 12:27:16PM +0200, Patrick Steinhardt wrote:\n> Yeah, it's definitely my goal here to do exactly that: reach out to\n> folks and take everyone's input into account. Once we've got it, propose\n> a timeline.\n>\n> I guess as part of that initial communication with the stakeholders we\n> can also mention that the current plan is to release roughly towards the\n> end of next year, which may help to put things into perspective.\n\nI am not sure what our proposal would be other than max(proposed_dates),\nclamped to some reasonable range that we are comfortable with so as not\nto delay the transition to use SHA-256 by default too far into the\nfuture.\n\nI think a more interesting question is:\n\n - What do we do for implementations that do not have a roadmap, or\n whose roadmap is too far into the future?\n\n - What do we do for implementations that have a roadmap, have a date\n that is palatable to the project, but end up slipping and are unable\n to meet that date?\n\nI generally agree that we have to draw a line in the sand *somewhere*,\nbut I don't think we should be so inflexible as to say \"if you don't\nhave SHA-256 done by X date, you are out of luck\". Of course, if the\namended timeline is too far beyond the initial deadline that's one case.\nBut if someone is a release cycle or so behind, I think it's reasonable\nthat the project should be flexible enough to accommodate that.\n\nThanks,\nTaylor\n"},{"id":"528357","messageId":"aOdOqX45_uvsDXTL@pks.im","threadId":"64229","inReplyTo":"aObNPk8ily0EFNxM@szeder.dev","subject":"Re: When should we release Git 3.0?","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-10-09T05:56:57Z","receivedAt":"2025-10-09T05:57:09Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Wed, Oct 08, 2025 at 10:44:46PM +0200, SZEDER Gábor wrote:\n> On Tue, Oct 07, 2025 at 12:27:23PM +0200, Patrick Steinhardt wrote:\n> > The question of course is how to get such roadmaps. The easiest way to\n> > do it is probably to gather a list of known projects that would be\n> > impacted and just shoot maintainers or representatives of those an\n> > email? From the top of my head, that would include:\n> > \n> > - Implementations\n> > - libgit2\n> > - JGit\n> > - Gitoxide\n> > - go-git\n> > - Forges\n> > - GitHub\n> > - GitLab\n> > - Bitbucket\n> > - Forgejo\n> > - SourceHut\n> \n> codeberg.org\n\nIsn't Codeberg essentially the one driving Forgejo? They (or a\nrepresentative of them) would have been my primary contact point there.\n\nThanks!\n\nPatrick\n"},{"id":"528358","messageId":"aOdPXrELgKkxVLSp@pks.im","threadId":"64229","inReplyTo":"aObgEGjcou06nP68@nand.local","subject":"Re: When should we release Git 3.0?","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-10-09T05:59:58Z","receivedAt":"2025-10-09T06:00:06Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Wed, Oct 08, 2025 at 06:05:04PM -0400, Taylor Blau wrote:\n> On Tue, Oct 07, 2025 at 12:27:16PM +0200, Patrick Steinhardt wrote:\n> > Yeah, it's definitely my goal here to do exactly that: reach out to\n> > folks and take everyone's input into account. Once we've got it, propose\n> > a timeline.\n> >\n> > I guess as part of that initial communication with the stakeholders we\n> > can also mention that the current plan is to release roughly towards the\n> > end of next year, which may help to put things into perspective.\n> \n> I am not sure what our proposal would be other than max(proposed_dates),\n> clamped to some reasonable range that we are comfortable with so as not\n> to delay the transition to use SHA-256 by default too far into the\n> future.\n> \n> I think a more interesting question is:\n> \n> - What do we do for implementations that do not have a roadmap, or\n> whose roadmap is too far into the future?\n> \n> - What do we do for implementations that have a roadmap, have a date\n> that is palatable to the project, but end up slipping and are unable\n> to meet that date?\n> \n> I generally agree that we have to draw a line in the sand *somewhere*,\n> but I don't think we should be so inflexible as to say \"if you don't\n> have SHA-256 done by X date, you are out of luck\". Of course, if the\n> amended timeline is too far beyond the initial deadline that's one case.\n> But if someone is a release cycle or so behind, I think it's reasonable\n> that the project should be flexible enough to accommodate that.\n\nYeah, if it's about a small number of releases I definitely think we\nshould accommodate for that. But if it's \"We'll never have it\" or \"We'll\nhave it in five years\" it's probably a different story.\n\nIn any case though, I'd propose to punt on those questions for now and\nwait for feedback from the impacted communities first. Once we have such\nfeedback we can discuss in more detail.\n\nPatrick\n"},{"id":"529024","messageId":"aPFkeZrowzxtg6uN@fruit.crustytoothpaste.net","threadId":"64229","inReplyTo":"aObgEGjcou06nP68@nand.local","subject":"Re: When should we release Git 3.0?","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-10-16T21:32:41Z","receivedAt":"2025-10-16T21:32:44Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-10-08 at 22:05:04, Taylor Blau wrote:\n> I am not sure what our proposal would be other than max(proposed_dates),\n> clamped to some reasonable range that we are comfortable with so as not\n> to delay the transition to use SHA-256 by default too far into the\n> future.\n> \n> I think a more interesting question is:\n> \n> - What do we do for implementations that do not have a roadmap, or\n> whose roadmap is too far into the future?\n> \n> - What do we do for implementations that have a roadmap, have a date\n> that is palatable to the project, but end up slipping and are unable\n> to meet that date?\n> \n> I generally agree that we have to draw a line in the sand *somewhere*,\n> but I don't think we should be so inflexible as to say \"if you don't\n> have SHA-256 done by X date, you are out of luck\". Of course, if the\n> amended timeline is too far beyond the initial deadline that's one case.\n> But if someone is a release cycle or so behind, I think it's reasonable\n> that the project should be flexible enough to accommodate that.\n\nI agree that it would be appropriate to be somewhat flexible. My\npersonal view is that we should inform stakeholders relatively soon\n(preferably within the next month) and expect them to promptly and\ndiligently undertake the necessary work to get started (maybe within\nanother month) and provide a rough roadmap.\n\nIf that happens, I expect most stakeholders will be done in about a year\nto a year and a half, tops. Assuming a reasonable release cycle, I\nthink it should be fine to give people some grace to do a release with\nthose changes as long as they can communicate a reasonable timeline to\nus and show that they're making a reasonably diligent effort.\n\nI also think there will be some stakeholders, probably including some\nforges, that will not promptly undertake the work. In my view, the\nanswer then is that we won't consider their readiness as affecting our\ntimeline.\n\nThere are also some implementations that I know already have SHA-256\nsupport. I believe libgit2 and Forgejo both have at least some\nfunctionality there, so we may want to just give them a heads up that\nthey may want to polish any support they have before Git 3.0.\n\nIf we want to set a hard cap, then I'd say two years. I know that's\nwhat we said in 2024, but we didn't communicate it well at the time.\nWhat I have been communicating elsewhere is that Git 3.0 is tentatively\nplanned for a year from now, so that may be a good initial phrasing to\nset expectations, with the clarifications we've specified. I think a\nyear from now would be good if all the relevant stakeholders are\nfinished before then (which is possible, but unlikely).\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"529025","messageId":"aPFmtqFvzB2kMDqA@fruit.crustytoothpaste.net","threadId":"64229","inReplyTo":"aObep4lUP8hcWXxG@nand.local","subject":"Re: When should we release Git 3.0?","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-10-16T21:42:14Z","receivedAt":"2025-10-16T21:42:16Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-10-08 at 21:59:03, Taylor Blau wrote:\n> I would imagine that the definition of \"roadmap\" here is fairly\n> lightweight, since I imagine that some organizations may not want to\n> share details beyond \"we will have it done by X date\".\n\nCertainly. I think the more details stakeholders are willing to give\nus, though, the more flexible we can be. If a forge says, \"we're about\n75% done, but our CI product needs another month,\" that's a more\ncompelling argument than, \"well, we just need another month for\nreasons,\" especially if their previous deadline has already slipped\n(which tends to happen on software projects, as we all know).\n\nFor open source projects, of course, seeing progress is relatively easy.\nMany companies may have alpha or beta programs and could share that\nstatus with us if they don't wish to be more specific.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"}]}