On 2026-10-08 at 19:06:32, Maciej Ciemborowicz wrote:
> At this point, I face a moral dilemma, because the next step is to
> hand the patch over to other people to read, which means asking them
> to spend their time on it. I have the following options:
> 
> 1. Report the bug without submitting a patch.
> 2. Report the bug and spend a month writing the patch myself, learning
> Git internals and C along the way. Unfortunately, I'm not planning a
> career in C. I've been programming for well over a decade in a
> completely different stack, and I simply can't afford to devote that
> much time to it. It might be worthwhile if I intended to spend the
> next several years working with Git and C, but unfortunately, that's
> not an option for me. On top of that, I can't shake the feeling that
> AI is already learning faster than I am.
> 3. Report the bug and solve the problem as well as I can with the help
> of an AI agent.
> 
> So realistically, my choice comes down to options 1 and 3. And that's
> my moral dilemma: I don't know whether it's better not to submit a
> patch at all, or to do the best I can with the time I have, using AI.

It's better not to submit a patch at all if you can't submit something
of reasonably good quality or can't satisfy the guidelines in
SubmittingPatches (either with regard to AI usage or in any other way).
I've been contributing for probably a decade and there are lots of times
I submit a bug report or notice a problem and _don't_ submit a patch,
either because I'm limited in time or because it's something that I'm
just not familiar with (like the internals of the pack bitmap code).
Reporting bugs is valuable to us even without a patch and nobody is
expected to magically understand all the code.

The problem you reported has been noticed by other people, so it may be
that someone who _is_ familiar with the code or confidence in C picks it
up.  That happened with a change that went into 2.56 about an issue I
reported around the 2.51 time frame.  I agree this is something that
should ideally be fixed and a fix would be valuable for another problem
that I've also reported (`git remote rename` is very expensive with many
remote-tracking refs), so it's likely someone will pick it up
eventually and that could end up being me if nobody else gets to it
first (no promises, though).
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA