From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: git@vger.kernel.org
Subject: git subtree bugs (mishandled merges, recursion depth)
Date: Wed, 17 Jul 2024 17:49:17 +0100 [thread overview]
Message-ID: <26263.62989.829497.450160@chiark.greenend.org.uk> (raw)
I have what ought to be a fairly straightforward situation that
git-subtree seems to be mishandling.
Steps to reproduce:
git clone https://gitlab.torproject.org/tpo/core/arti.git
cd arti
git checkout 01d02118cdda30636e606fc1a89b3e04f28b8ad1
git subtree split -P maint/rust-maint-common
Expected behaviour:
git subtree (hopefully fairly rapidly) prints a the commitid of the
tip of a branch suitable for merging back to the upstream repo, which
is at https://gitlab.torproject.org/tpo/core//rust-maint-common
The resulting history ought to have a few dozen commits,
most of which are the upstream history of the subtree.
Actual behaviour (git 2.45.2, Debian amd64 1:2.45.2-1 .deb):
$ git subtree split -P maint/rust-maint-common
/usr/lib/git-core/git-subtree: 318: Maximum function recursion depth (1000) reached
$
Actual behaviour (git 2.20.1, Debian ancient 1:2.20.1-2+deb10u9):
Takes a very long time. Everntually produces an output commit
which has most of arti.git#main in its history.
Notes about the source repository:
The state of arti.git:maint/rust-maint-common is the result of the
following:
(i) create a new rust-maint-common.git, and add and edit files
(many of these changes came via gitlab MRs, there are merges)
(ii) in arti.git, `git subtree add`, and make further changes,
to files both within and without the subtree
(iii) Make a gitlab MR from (ii) and merge it into arti.git#main.
(resulting in a fairly merge-rich history)
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2267
A workaround:
If I check out main^2 (01d02118cdda30636e606fc1a89b3e04f28b8ad1^2)
and run git-subtree split using the ancient version of git, it still
takes ages, but the output is correct. So the old version of git has
a bug meaning it can produce higly excessive output, when merges are
present.
This workaround is only available because right now the history of
the subtree's files, within arti.git, is fairly simple.
With the new version of git, I get the "recursion depth" error,
regardless.
Thanks for your attention.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
next reply other threads:[~2024-07-17 16:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-17 16:49 Ian Jackson [this message]
-- strict thread matches above, loose matches on Subject: below --
2024-07-17 16:55 git subtree bugs (mishandled merges, recursion depth) Ian Jackson
2026-04-16 1:26 ` Colin Stagner
2026-04-16 14:31 ` Ian Jackson
2026-04-17 4:14 ` Colin Stagner
2024-07-17 16:31 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=26263.62989.829497.450160@chiark.greenend.org.uk \
--to=ijackson@chiark.greenend.org.uk \
--cc=git@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox