On 2025-09-22 at 20:59:00, Junio C Hamano wrote:
> The version of the document in this thread talks about 2.52 (opt-in)
> and 2.53 (opt-out) before jumping to 3.0 (no way to opt-out) but it
> does not say anything about how far out that big version bump is.
> But the numbers I remember hearing was in the orders of 18 monts or
> so if I am not mistaken?

I think the plan was 4 release cycles, or about a year.  Git 3.0 was
going to replace 2.55.

> As I already said a few times (e.g. <xmqq8qipzhg3.fsf@gitster.g>), I
> feel that the timeline hinted by any of these documents that were
> proposed is way too aggressive for affected people to practically
> prepare for.

I don't think it's substantially more aggressive than the
interoperability code.  Both are aggressive timelines, but getting LLVM
ported to some of the affected targets isn't out of the question
(especially since older versions of it supported some of those targets)
and once that's done, I'm pretty sure Rust upstream would be on board
with supporting those systems.

> By the way, I was hoping that the hash compatibility work can be
> done as an opt-in item available only for those with Rust, while
> Rustless folks are forever stuck in a single hash algorithm world,
> and be released well before Git 3.0 that makes Rust mandatory.  That
> does not change the fact that nothing will work wrt hash transition
> for Rustless folks, though ;-).

I would love to have the interoperability work in sooner, but I don't
think it's realistic.  I have about 100 patches and I expect a total of
200 to 400 for the entire work.  That means someone has to send in 50 to
100 patches every one of the four release cycles before 3.0 and get
them sufficiently polished to get accepted, including any necessary
re-rolls.  I don't think you actually want me to send all of those
patches for one cycle at once, either.

Even with time to work on it at work, that's a lot of time and effort
for one person, and I also have personal responsibilities to family and
friends (someone has to cook dinner, for instance).  We'll see if
additional assistance is forthcoming, in which case timelines could
possibly be more aggressive.

Otherwise, if we want Git 3.0 to contain the interoperability work and
are unwilling to ship without it, then we may have a longer timeframe
for Git 3.0, and it may be more like replacing Git 2.57 or 2.58 instead.

> [Footnote]
> 
> * By the way, I _think_ I never saw that policy document until
>   Ezekiel started his topic and sent it out as one of the component
>   patches; how did it get there from brian to Ezekiel's topic?

I had it in a branch of mine that I was going to submit at some point
and I mentioned it to Ezekiel, who modified it and incorporated it.  The
original branch should be `rust` on my remote for those who are
interested.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA