All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Colin Stagner <ask+git@howdoi.land>
Cc: Christian Heusel <christian@heusel.eu>,
	george@mail.dietrich.pub, Christian Hesse <list@eworm.de>,
	Phillip Wood <phillip.wood@dunelm.org.uk>,
	git@vger.kernel.org
Subject: Re: [PATCH v2 0/3] contrib/subtree: reduce recursion during split
Date: Fri, 13 Mar 2026 16:06:09 -0700	[thread overview]
Message-ID: <xmqqbjgr1g9q.fsf@gitster.g> (raw)
In-Reply-To: <xmqqldfv1gxc.fsf@gitster.g> (Junio C. Hamano's message of "Fri, 13 Mar 2026 15:51:59 -0700")

Junio C Hamano <gitster@pobox.com> writes:

> Colin Stagner <ask+git@howdoi.land> writes:
>
>> * cs/subtree-split-recursion: when processing large history
>>   graphs on Debian or Ubuntu, "git subtree" can die with a
>>   "recursion depth reached" error. Reduce recursion.
>>
>> On Debian's POSIX sh, shell recursion is artificially limited
>> to 1000 calls. You can check if your sh has limited recursion
>> with:
>>
>>     #!/bin/sh
>>     recurse() {
>>         r=$(( r + 1 ))
>>         test "$r" -le 1000 || { echo OK; exit; }
>>         recurse
>>     } && r=0 && recurse
>>
>> Depending on the history graph, subtree split can recurse deeply
>> enough to encounter this limit. Rewrite the rejoin-deepening
>> algorithm to reduce recursive calls.
>>
>> ---
>> Changes in v2:
>> - Rebase on master
>
> We have seen two iterations of this series without anybody
> commenting on it.  Is it a sign that the topic, or possibly "git
> subtree" itself, is of interest to nobody?  Or is it that it is so
> well done that nobody had any comment on it?
>
> I don't use "git subtree" myself, and I do not know of anybody who
> will scream at me if I break it by merging an unreviewed patch, so I
> can merge it without worrying too much about fallout personally, but
> that is a tad irresponsible as the maintainer ;-)
>
> So...?  Any volunteers among those who have a higher stake in the
> program than I do (which admittedly is not a high bar to cross)?

FWIW, I can see that [1/3] is a benign clean-up that should not
change any semantics.  [2/3] talks about the variable $sub, which is
used elsewhere, is not protected from getting overwritten by running
the function inside a subprocess, but I do not know if updates to
other variables (like $b, $sq, $repository, but not $fail_msg,
$hint1 and $hint2 that are used only in this function) want to be
seen after the calls to this function outside (and do not want to
find out myself---I'd rather want to see somebody else with stakes
in "git subtree" to verify), but otherwise the change looks benigh
to me.  I have no idea if what [3/3] does is sensible or not (and
again, I'd rather want to see somebody with stakes to double check).

Thanks.

  reply	other threads:[~2026-03-13 23:06 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-15 20:17 [PATCH 0/3] contrib/subtree: reduce recursion during split Colin Stagner
2026-02-15 20:17 ` [PATCH 1/3] contrib/subtree: reduce function side-effects Colin Stagner
2026-02-15 20:17 ` [PATCH 2/3] contrib/subtree: functionalize split traversal Colin Stagner
2026-02-15 20:17 ` [PATCH 3/3] contrib/subtree: reduce recursion during split Colin Stagner
2026-03-05 23:55 ` [PATCH v2 0/3] " Colin Stagner
2026-03-05 23:55   ` [PATCH v2 1/3] contrib/subtree: reduce function side-effects Colin Stagner
2026-03-05 23:55   ` [PATCH v2 2/3] contrib/subtree: functionalize split traversal Colin Stagner
2026-03-05 23:55   ` [PATCH v2 3/3] contrib/subtree: reduce recursion during split Colin Stagner
2026-03-13 22:51   ` [PATCH v2 0/3] " Junio C Hamano
2026-03-13 23:06     ` Junio C Hamano [this message]
2026-04-15 17:58       ` Junio C Hamano
2026-04-15 21:39         ` Ben Knoble
2026-04-16 13:25   ` Ian Jackson
2026-04-16 19:34     ` Junio C Hamano
2026-04-17  4:50     ` Colin Stagner
2026-04-19 19:55       ` Ian Jackson
2026-04-20  1:09         ` Ben Knoble
2026-04-20  1:50         ` Junio C Hamano
2026-04-20  9:57         ` Ian Jackson
2026-04-21  5:07           ` Colin Stagner
2026-04-22  9:43             ` Johannes Schindelin
2026-04-22 17:12           ` git-subtree rewrite Ian Jackson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqbjgr1g9q.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=ask+git@howdoi.land \
    --cc=christian@heusel.eu \
    --cc=george@mail.dietrich.pub \
    --cc=git@vger.kernel.org \
    --cc=list@eworm.de \
    --cc=phillip.wood@dunelm.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.