{"thread":{"id":"65928","subject":"[PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite","startedAt":"2026-07-06T12:38:01Z","lastAt":"2026-08-26T20:53:59Z","messageCount":20,"participants":["Ian Jackson","Junio C Hamano","Colin Stagner","Phillip Wood","D. Ben Knoble"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"547217","messageId":"20260706115816.20267-2-ijackson@chiark.greenend.org.uk","threadId":"65928","inReplyTo":"20260706115816.20267-1-ijackson@chiark.greenend.org.uk","subject":"[PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite","fromName":"Ian Jackson","fromEmail":"ijackson@chiark.greenend.org.uk","sentAt":"2026-07-06T11:58:15Z","receivedAt":"2026-07-06T12:38:01Z","isPatch":true,"body":"This is going to be forward compatible, but not backward compatible:\nprojects are expected to adopt the new tool, but not go back to this\nold one.\n\nCC: Colin Stagner <ask+git@howdoi.land>\nCC: Johannes Schindelin <Johannes.Schindelin@gmx.de>\nSigned-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>\n---\n contrib/subtree/git-subtree.sh | 18 ++++++++++++++++++\n 1 file changed, 18 insertions(+)\n\ndiff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh\nindex 791fd8260c..e9c7ca7cf5 100755\n--- a/contrib/subtree/git-subtree.sh\n+++ b/contrib/subtree/git-subtree.sh\n@@ -278,6 +278,20 @@ main () {\n \t\"cmd_$arg_command\" \"$@\"\n }\n \n+# Usage: reject_if_v2_config REV\n+#\n+# Bails if we find .git-subtree/config.  This file is used by the RIIR\n+# git-subtree, which can read data from this script, but which generates\n+# data that this script cannot cope with.  So if we find that the user's\n+# project has already been processed with the new tool, we stop, to\n+# avoid generating broken output.\n+reject_if_v2_config () {\n+\tlocal config=.git-subtree/config\n+\tif git rev-parse --verify -q \"$rev:$config\"; then\n+\t\tdie \"fatal: tree contains $config: has been processed with new standalone (Rust) git-subtree; use that tool instead of this one.  See https://codeberg.org/diziet/git-subtree https://crates.io/crates/git-subtree\"\n+\tfi\n+}\n+\n # Usage: cache_setup\n cache_setup () {\n \tassert test $# = 0\n@@ -846,6 +860,7 @@ process_split_commit () {\n #    Or: cmd_add REPOSITORY REF\n cmd_add () {\n \n+\treject_if_v2_config HEAD\n \tensure_clean\n \n \tif test $# -eq 1\n@@ -934,6 +949,8 @@ cmd_split () {\n \t\tdie \"fatal: you must provide exactly one revision, and optionally a repository.  Got: '$*'\"\n \tfi\n \n+\treject_if_v2_config \"$rev\"\n+\n \t# Now validate prefix against the commit, not the working tree\n \tif ! git cat-file -e \"$rev:$dir\" 2>/dev/null\n \tthen\n@@ -1034,6 +1051,7 @@ cmd_merge () {\n \tthen\n \t\trepository=\"$2\"\n \tfi\n+\treject_if_v2_config HEAD\n \tensure_clean\n \n \tif test -n \"$arg_addmerge_squash\"\n-- \n2.47.3\n\n"},{"id":"547218","messageId":"20260706115816.20267-3-ijackson@chiark.greenend.org.uk","threadId":"65928","inReplyTo":"20260706115816.20267-1-ijackson@chiark.greenend.org.uk","subject":"[PATCH 2/2] git-subtree: Bail out if we find output from Rust rewrite (test)","fromName":"Ian Jackson","fromEmail":"ijackson@chiark.greenend.org.uk","sentAt":"2026-07-06T11:58:16Z","receivedAt":"2026-07-06T13:01:20Z","isPatch":true,"body":"Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>\n---\n contrib/subtree/t/t7900-subtree.sh | 18 ++++++++++++++++++\n 1 file changed, 18 insertions(+)\n\ndiff --git a/contrib/subtree/t/t7900-subtree.sh b/contrib/subtree/t/t7900-subtree.sh\nindex 4194687cfb..e8fa640166 100755\n--- a/contrib/subtree/t/t7900-subtree.sh\n+++ b/contrib/subtree/t/t7900-subtree.sh\n@@ -439,6 +439,24 @@ test_expect_success 'split sub dir/ with --rejoin' '\n \t)\n '\n \n+test_expect_success 'split fail on RIIR git subtree data' '\n+\tsubtree_test_create_repo \"$test_count\" &&\n+\tsubtree_test_create_repo \"$test_count/sub proj\" &&\n+\ttest_create_commit \"$test_count\" main1 &&\n+\ttest_create_commit \"$test_count/sub proj\" sub1 &&\n+\t(\n+\t\tcd \"$test_count\" &&\n+\t\tgit fetch ./\"sub proj\" HEAD &&\n+\t\tgit subtree add --prefix=\"sub dir\" FETCH_HEAD &&\n+\t\t# simulate RIIR git-subtree generated data\n+\t\tmkdir .git-subtree &&\n+\t\techo \"# sabotage\" >.git-subtree/config &&\n+\t\tgit add .git-subtree/config &&\n+\t\tgit commit -m sabotage &&\n+\t\ttest_must_fail git subtree split -P \"sub dir\" HEAD\n+\t)\n+'\n+\n # Tests that commits from other subtrees are not processed as\n # part of a split.\n #\n-- \n2.47.3\n\n"},{"id":"547219","messageId":"20260706115816.20267-1-ijackson@chiark.greenend.org.uk","threadId":"65928","inReplyTo":null,"subject":"[PATCH 0/2] git-subtree: Bail out if we find output from Rust rewrite","fromName":"Ian Jackson","fromEmail":"ijackson@chiark.greenend.org.uk","sentAt":"2026-07-06T11:58:14Z","receivedAt":"2026-07-06T13:04:00Z","isPatch":true,"body":"My rewrite of git-subtree is coming along fairly nicely.  I have done\na bunch of data model design work, as well as successfully implemented\nthe \"split\" operation.  (It's several orders of magnitude faster than\nthe shell script implementation, and produces much better output.)\n\nI have concluded that it is going to be too difficult to have\nbidirectional interoperability, for a number of reasons.  One reason\nis that I want to change the way split commits are constructed and\nthey should be as stable as we can make them.\n\nAnother, bigger, reason is that current git-subtree generates unmarked\nsubtree merges (ie, without any git-subtree trailers); reliably\nfiguring out whether something is such a merge requires a complete\nhistory walk, which is very unfortunate.  To avoid having to do this\nin perpetuity, I plan to have new git-subtree assume that commits\nwhich show signs of use of new git-subtree are not unmarked subtree\nmerges generated by old git-subtree.\n\nSo mycompatibility plan is:\n\n - New git-subtree can read old git-subtree data\n - Old git-subtree (this one here) will *not* handle new data\n\nNew git-subtree needs an in-downstream-tree config file with at least\nan indication of the downstream project name, because otherwise split\ncommits can be quite inscrutable.  So the presence of that file is a\nconvenient way to signal the change.\n\n\nThe purpose of the present patch is to help prevent messes, where old\ngit-subtree is used *afer* new git-subtree, generating output that no\ntooling can handle correctly.  We change old git-subtree to spot the\nnew git-subtree's config file, and bail out.\n\nRight now there is no new data in existence, becauwe new git-subtree\nis not useable.  So right now this change has no effect.\n\nBut if we ship this change now, users with this change will be\ndefended from this lossage, as their collaborators start to use new\ngit-subtree.  I'm hoping to possibly persuade distros etc. to take\nthis patch as a backport.\n\nI wasn't sure how precisely to word the error message.  I chose to\nrefer to the new tool, as if it really exists.  By the time anyone\nactually seex this message, it will do.\n\n\nIan Jackson (2):\n  git-subtree: Bail out if we find output from Rust rewrite\n  git-subtree: Bail out if we find output from Rust rewrite (test)\n\n contrib/subtree/git-subtree.sh     | 18 ++++++++++++++++++\n contrib/subtree/t/t7900-subtree.sh | 18 ++++++++++++++++++\n 2 files changed, 36 insertions(+)\n\n-- \n2.47.3\n\n"},{"id":"547245","messageId":"xmqqy0fob2kl.fsf@gitster.g","threadId":"65928","inReplyTo":"20260706115816.20267-2-ijackson@chiark.greenend.org.uk","subject":"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-07-06T14:44:10Z","receivedAt":"2026-07-06T14:44:12Z","isPatch":true,"body":"Ian Jackson <ijackson@chiark.greenend.org.uk> writes:\n\n> +# Usage: reject_if_v2_config REV\n> +#\n> +# Bails if we find .git-subtree/config.  This file is used by the RIIR\n> +# git-subtree, which can read data from this script, but which generates\n> +# data that this script cannot cope with.  So if we find that the user's\n> +# project has already been processed with the new tool, we stop, to\n> +# avoid generating broken output.\n> +reject_if_v2_config () {\n> +\tlocal config=.git-subtree/config\n> +\tif git rev-parse --verify -q \"$rev:$config\"; then\n> +\t\tdie \"fatal: tree contains $config: has been processed with new standalone (Rust) git-subtree; use that tool instead of this one.  See https://codeberg.org/diziet/git-subtree https://crates.io/crates/git-subtree\"\n> +\tfi\n> +}\n\n[warning: I have no idea what is going on in the code we see here,\nas I do not use subtree script at all]\n\nThe above helper may work for one caller that passes \"$rev\" but not\nfor the other caller that passes \"HEAD\", no?\n\n\n\tif git rev-parse --verify -q \"$1:$config\"\n\tthen\n\t\tdie \"fatal: tree contains $config: has been processed with new standalone (Rust) git-subtree; use that tool instead of this one.  See https://codeberg.org/diziet/git-subtree https://crates.io/crates/git-subtree\"\n\tfi\n\nOverly long output does not look very easy to read, but I kept it\nthe same as the original.\n\n> @@ -846,6 +860,7 @@ process_split_commit () {\n>  #    Or: cmd_add REPOSITORY REF\n>  cmd_add () {\n>  \n> +\treject_if_v2_config HEAD\n>  \tensure_clean\n\nIf (global) $rev is not set here, we'd check :.git-subtree/config in\nthe index in order to detect the v2's configuration.  It seems to me\nthat this code however wants to inspect HEAD's tree.\n\n> @@ -934,6 +949,8 @@ cmd_split () {\n>  \t\tdie \"fatal: you must provide exactly one revision, and optionally a repository.  Got: '$*'\"\n>  \tfi\n>  \n> +\treject_if_v2_config \"$rev\"\n\nThis would happen to work, as the global \"$rev\" visible here is the\nsame one as what the new helper function sees and uses.\n\n>  \t# Now validate prefix against the commit, not the working tree\n>  \tif ! git cat-file -e \"$rev:$dir\" 2>/dev/null\n>  \tthen\n> @@ -1034,6 +1051,7 @@ cmd_merge () {\n>  \tthen\n>  \t\trepository=\"$2\"\n>  \tfi\n> +\treject_if_v2_config HEAD\n>  \tensure_clean\n\nThe same comment as the one for cmd_add's usage.\n\n>  \tif test -n \"$arg_addmerge_squash\"\n"},{"id":"547248","messageId":"27211.50096.133710.528147@chiark.greenend.org.uk","threadId":"65928","inReplyTo":"xmqqy0fob2kl.fsf@gitster.g","subject":"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite","fromName":"Ian Jackson","fromEmail":"ijackson@chiark.greenend.org.uk","sentAt":"2026-07-06T15:03:12Z","receivedAt":"2026-07-06T15:03:14Z","isPatch":true,"body":"Hi.  Thanks for the quick review.\n\nJunio C Hamano writes (\"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite\"):\n> If (global) $rev is not set here, we'd check :.git-subtree/config in\n> the index in order to detect the v2's configuration.  It seems to me\n> that this code however wants to inspect HEAD's tree.\n\nThis was a slip.  The code in reject_if_v2_config is supposed to use\nits argument (as per the usage comment I added), not a global.  I'll\nfix this with a respin.\n\n(I think it may somehow work by accident in my tests.)\n\n> The above helper may work for one caller that passes \"$rev\" but not\n> for the other caller that passes \"HEAD\", no?\n\nHEAD is a valid revision spec for git-rev-parse, but the\nfunction should use $1 (which in that case would be HEAD), not $rev.\n\n> \tif git rev-parse --verify -q \"$1:$config\"\n> \tthen\n> \t\tdie \"fatal: tree contains $config: has been processed with new standalone (Rust) git-subtree; use that tool instead of this one.  See https://codeberg.org/diziet/git-subtree https://crates.io/crates/git-subtree\"\n> \tfi\n> \n> Overly long output does not look very easy to read, but I kept it\n> the same as the original.\n\nI'm not a great fan of the long error message myself, but it seemed to\nbe what the rest of the script was doing.  I didn't find any\nmulti-line calls to die, so that's why I did it this way.\n\nI'm happy to reformat this to your taste.\n\nThanks,\nIan.\n\n-- \nIan Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.  \n\nPronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,\nthat is a private address which bypasses my fierce spamfilter.\n"},{"id":"547264","messageId":"xmqqik6ran63.fsf@gitster.g","threadId":"65928","inReplyTo":"27211.50096.133710.528147@chiark.greenend.org.uk","subject":"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-07-06T20:16:52Z","receivedAt":"2026-07-06T20:16:55Z","isPatch":true,"body":"Ian Jackson <ijackson@chiark.greenend.org.uk> writes:\n\n>> \tif git rev-parse --verify -q \"$1:$config\"\n>> \tthen\n>> \t\tdie \"fatal: tree contains $config: has been processed with new standalone (Rust) git-subtree; use that tool instead of this one.  See https://codeberg.org/diziet/git-subtree https://crates.io/crates/git-subtree\"\n>> \tfi\n>> \n>> Overly long output does not look very easy to read, but I kept it\n>> the same as the original.\n>\n> I'm not a great fan of the long error message myself, but it seemed to\n> be what the rest of the script was doing.  I didn't find any\n> multi-line calls to die, so that's why I did it this way.\n>\n> I'm happy to reformat this to your taste.\n\nNah, it seems your plan is to deprecate this script over time and\nmove everybody to a newer implementation, so as long as \"die\" does\nits job to stop and prevent breakages from spreading, that would be\nfine.\n\nThanks.\n"},{"id":"547551","messageId":"f557bfcf-ffd2-4903-8015-97fff97dbe09@howdoi.land","threadId":"65928","inReplyTo":"20260706115816.20267-2-ijackson@chiark.greenend.org.uk","subject":"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite","fromName":"Colin Stagner","fromEmail":"ask+git@howdoi.land","sentAt":"2026-07-09T01:49:40Z","receivedAt":"2026-07-09T01:50:13Z","isPatch":true,"body":"On 7/6/26 06:58, Ian Jackson wrote:\n\n> Another, bigger, reason is that current git-subtree generates unmarked\n> subtree merges (ie, without any git-subtree trailers)\n\nSubtree merges can be performed without git-subtree, via the `-X \nsubtree` merge strategy option. While the design of RIIR git-subtree is \noutside the scope of this patch series, this may be worth thinking about \nin your rewrite.\n\n\n> --- a/contrib/subtree/git-subtree.sh\n> +++ b/contrib/subtree/git-subtree.sh\n> @@ -278,6 +278,20 @@ main () {\n\n\n> +reject_if_v2_config () {\n> +\tlocal config=.git-subtree/config\n\nThis is a nit, but `local` is not specified by POSIX. I know it is used \nelsewhere within git-subtree, but it is specifically discouraged.\n\n> +\tif git rev-parse --verify -q \"$rev:$config\"; then\n\nFor subtree split, should we also test for this file in tree you are \nsplitting: i.e., \"$dir/$config\"? The answer might be no.\n\nI think that subtree merge should only test the top-level project, as \nthis patch does now.\n\nColin\n\n\n"},{"id":"547552","messageId":"9ef8cfcc-ab47-479b-9f23-71ba99e1e56b@howdoi.land","threadId":"65928","inReplyTo":"20260706115816.20267-3-ijackson@chiark.greenend.org.uk","subject":"Re: [PATCH 2/2] git-subtree: Bail out if we find output from Rust rewrite (test)","fromName":"Colin Stagner","fromEmail":"ask+git@howdoi.land","sentAt":"2026-07-09T01:59:16Z","receivedAt":"2026-07-09T01:59:31Z","isPatch":true,"body":"On 7/6/26 06:58, Ian Jackson wrote:\n\n> --- a/contrib/subtree/t/t7900-subtree.sh\n> +++ b/contrib/subtree/t/t7900-subtree.sh\n> @@ -439,6 +439,24 @@ test_expect_success 'split sub dir/ with --rejoin' '\n>   \t)\n>   '\n>   \n> +test_expect_success 'split fail on RIIR git subtree data' '\n> +\tsubtree_test_create_repo \"$test_count\" &&\n> +\tsubtree_test_create_repo \"$test_count/sub proj\" &&\n\nIt may be slightly faster to create only one repo and just make orphan \nbranches, like `test_create_subtree_add()` does.\n\n> +\t\techo \"# sabotage\" >.git-subtree/config &&\n> +\t\tgit add .git-subtree/config &&\n> +\t\tgit commit -m sabotage &&\n\n`test_commit()` from test-lib-functions.sh may be superior to manually \nwriting and committing this file.\n\n\nColin\n\n"},{"id":"547580","messageId":"27215.27575.968985.583226@chiark.greenend.org.uk","threadId":"65928","inReplyTo":"f557bfcf-ffd2-4903-8015-97fff97dbe09@howdoi.land","subject":"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite [and 1 more messages]","fromName":"Ian Jackson","fromEmail":"ijackson@chiark.greenend.org.uk","sentAt":"2026-07-09T09:36:55Z","receivedAt":"2026-07-09T09:37:03Z","isPatch":true,"body":"Hi.  Thanks for the review.  I'll go through it point by point:\n\nColin Stagner writes (\"Re: [PATCH 2/2] git-subtree: Bail out if we find output from Rust rewrite (test)\"):\n> It may be slightly faster to create only one repo and just make orphan \n> branches, like `test_create_subtree_add()` does.\n...\n> `test_commit()` from test-lib-functions.sh may be superior to manually \n> writing and committing this file.\n\nThanks for the suggestions.  I'll take a look.\n\nTBH I found this test framework quite awkward to work with.  Maybe\nfolks here have some tips:\n\nOne thing I was missing was a primitive for \"check this fails *and\nproduces an error message matching this regexp*\".  test_must_fail\nmakes it easy for a slips in the command (or some kinds of regression)\nto go undetected: the test then passes because the command *does* fail\nwith a usage error or whatever.  And AFAICT there isn't a way to\nmanually inspect the output when the tests pass?  I resorted to\nsabotaging the test by adding `&& false` to the end of the shell\nsnippet string, and eyeballing t/test-results/t7900-subtree.out.\n\nColin Stagner writes (\"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite\"):\n> > +reject_if_v2_config () {\n> > +\tlocal config=.git-subtree/config\n> \n> This is a nit, but `local` is not specified by POSIX. I know it is used \n> elsewhere within git-subtree, but it is specifically discouraged.\n\nThere are 7 existing uses of `local`.  I think I prefer to use it here\ntoo.  In practice I think there are no shells we might want to use\nthat don't have local.  The alternative is to change all the variable\nnames to be obviously globally unique, which is clumsy and also seems\nto me to put us at greater risk of bugs.\n\n> > +\tif git rev-parse --verify -q \"$rev:$config\"; then\n> \n> For subtree split, should we also test for this file in tree you are \n> splitting: i.e., \"$dir/$config\"? The answer might be no.\n\nYou're right that we should consider this question.  The answer is:\nno, we should not.  Briefly, whether to use the new or old algorithms\ndepends on whether the downstream has adopted the new git-subtree, not\non whether the upstream has added some optional config.\n\nhttps://codeberg.org/diziet/git-subtree/src/branch/main/DATA-MODEL.md#control-of-unmarked-subtree-merges-guessing-config\n\n> I think that subtree merge should only test the top-level project, as \n> this patch does now.\n\nBy \"top-level\" I think you mean what I've taken to calling the\n\"downstream\": the project where the subtree is in a subdir, and whose\ntop-level has other stuff.  In which case I agree.\n\n> On 7/6/26 06:58, Ian Jackson wrote:\n> > Another, bigger, reason is that current git-subtree generates unmarked\n> > subtree merges (ie, without any git-subtree trailers)\n> \n> Subtree merges can be performed without git-subtree, via the `-X \n> subtree` merge strategy option. While the design of RIIR git-subtree is \n> outside the scope of this patch series, this may be worth thinking about \n> in your rewrite.\n\nThis is what I'm calling an \"unmarked subtree merge\".  My rewrite is\nnot going to support this user behaviour.  The problem is that it is\nnot possible to reliably determine whetheer something is an unmarked\nsubtree merge.\n\nIt is possible to guess based on tree similarity, but that's a\nheuristic.  It's also possible to guess based on root commits.\nBoth of these approaches can go wrong in some cases.  I prefer to\nwrite reliable software, which doesn't guess.\n\nI'll advise against this practice in the documentation, but I'm\nreasonably confident that if a user does this anyway the results won't\nbe terrible.  The upstream input to an unmarked subtree merge in a\ndownstream that has already used my rewrite, will be treated as if it\nwere a downstream branch that predates the subtree addition.  The\neffect on split (in most cases) is a missing parent relationship,\nwhich is undesirable but not catastrophic.I've made a note to add a\ntest case for this scenario.\n\nCombining manual -X subtree merges with git-subtree --squash merges\ncould easily produce quite weird and wrong results in the tree (even\nbefore anyone tries split, or something).  I don't think I can even\nreliably detect this situation after the user has done it, and of\ncourse since that user is using plain git, I certainly can't prevent\nit.  This is another reason why manual use of -X subtree should be\ndiscouraged.\n\nRegards,\nIan.\n\n-- \nIan Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.  \n\nPronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,\nthat is a private address which bypasses my fierce spamfilter.\n"},{"id":"547605","messageId":"0fc3a36f-dd43-43d1-b260-8e30cf46d845@gmail.com","threadId":"65928","inReplyTo":"27215.27575.968985.583226@chiark.greenend.org.uk","subject":"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite [and 1 more messages]","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2026-07-09T13:19:35Z","receivedAt":"2026-07-09T13:19:42Z","isPatch":true,"body":"Hi Ian\n\nOn 09/07/2026 10:36, Ian Jackson wrote:\n> \n> Colin Stagner writes (\"Re: [PATCH 2/2] git-subtree: Bail out if we find output from Rust rewrite (test)\"):\n>> It may be slightly faster to create only one repo and just make orphan\n>> branches, like `test_create_subtree_add()` does.\n> ...\n>> `test_commit()` from test-lib-functions.sh may be superior to manually\n>> writing and committing this file.\n> \n> Thanks for the suggestions.  I'll take a look.\n\nI think\n\n     test_commit --no-tag sabotage .git-subtree/config \"# sabotage\"\n\nis the equivalent of what you have in the test at the moment\n\n> TBH I found this test framework quite awkward to work with.  Maybe\n> folks here have some tips:\n> \n> One thing I was missing was a primitive for \"check this fails *and\n> produces an error message matching this regexp*\".  test_must_fail\n> makes it easy for a slips in the command (or some kinds of regression)\n> to go undetected: the test then passes because the command *does* fail\n> with a usage error or whatever.  And AFAICT there isn't a way to\n> manually inspect the output when the tests pass?  I resorted to\n> sabotaging the test by adding `&& false` to the end of the shell\n> snippet string, and eyeballing t/test-results/t7900-subtree.out.\n\nThe usual approach to checking that a command fails for the expected \nreason is\n\n     test_must_fail git ... 2>err &&\n     test_grep regexp err\n\nwhich prints the contents of err if it does not match regexp. To see the \noutput of the tests run them with \"-v\". I frequently use \"-v -i -x\" to \ndebug test failures. \"-i\" stops the test run at the first failure so you \ncan inspect the test repository and \"-x\" turns on tracing so you can see \nwhich command failed which is useful when I test has not been written \nwith debugging in mind.\n\nThanks\n\nPhillip\n\t\n> Colin Stagner writes (\"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite\"):\n>>> +reject_if_v2_config () {\n>>> +\tlocal config=.git-subtree/config\n>>\n>> This is a nit, but `local` is not specified by POSIX. I know it is used\n>> elsewhere within git-subtree, but it is specifically discouraged.\n> \n> There are 7 existing uses of `local`.  I think I prefer to use it here\n> too.  In practice I think there are no shells we might want to use\n> that don't have local.  The alternative is to change all the variable\n> names to be obviously globally unique, which is clumsy and also seems\n> to me to put us at greater risk of bugs.\n> \n>>> +\tif git rev-parse --verify -q \"$rev:$config\"; then\n>>\n>> For subtree split, should we also test for this file in tree you are\n>> splitting: i.e., \"$dir/$config\"? The answer might be no.\n> \n> You're right that we should consider this question.  The answer is:\n> no, we should not.  Briefly, whether to use the new or old algorithms\n> depends on whether the downstream has adopted the new git-subtree, not\n> on whether the upstream has added some optional config.\n> \n> https://codeberg.org/diziet/git-subtree/src/branch/main/DATA-MODEL.md#control-of-unmarked-subtree-merges-guessing-config\n> \n>> I think that subtree merge should only test the top-level project, as\n>> this patch does now.\n> \n> By \"top-level\" I think you mean what I've taken to calling the\n> \"downstream\": the project where the subtree is in a subdir, and whose\n> top-level has other stuff.  In which case I agree.\n> \n>> On 7/6/26 06:58, Ian Jackson wrote:\n>>> Another, bigger, reason is that current git-subtree generates unmarked\n>>> subtree merges (ie, without any git-subtree trailers)\n>>\n>> Subtree merges can be performed without git-subtree, via the `-X\n>> subtree` merge strategy option. While the design of RIIR git-subtree is\n>> outside the scope of this patch series, this may be worth thinking about\n>> in your rewrite.\n> \n> This is what I'm calling an \"unmarked subtree merge\".  My rewrite is\n> not going to support this user behaviour.  The problem is that it is\n> not possible to reliably determine whetheer something is an unmarked\n> subtree merge.\n> \n> It is possible to guess based on tree similarity, but that's a\n> heuristic.  It's also possible to guess based on root commits.\n> Both of these approaches can go wrong in some cases.  I prefer to\n> write reliable software, which doesn't guess.\n> \n> I'll advise against this practice in the documentation, but I'm\n> reasonably confident that if a user does this anyway the results won't\n> be terrible.  The upstream input to an unmarked subtree merge in a\n> downstream that has already used my rewrite, will be treated as if it\n> were a downstream branch that predates the subtree addition.  The\n> effect on split (in most cases) is a missing parent relationship,\n> which is undesirable but not catastrophic.I've made a note to add a\n> test case for this scenario.\n> \n> Combining manual -X subtree merges with git-subtree --squash merges\n> could easily produce quite weird and wrong results in the tree (even\n> before anyone tries split, or something).  I don't think I can even\n> reliably detect this situation after the user has done it, and of\n> course since that user is using plain git, I certainly can't prevent\n> it.  This is another reason why manual use of -X subtree should be\n> discouraged.\n> \n> Regards,\n> Ian.\n> \n\n"},{"id":"547653","messageId":"c8b81987-ab56-4d6b-a650-879b84597a17@howdoi.land","threadId":"65928","inReplyTo":"27215.27575.968985.583226@chiark.greenend.org.uk","subject":"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite [and 1 more messages]","fromName":"Colin Stagner","fromEmail":"ask+git@howdoi.land","sentAt":"2026-07-09T22:43:02Z","receivedAt":"2026-07-09T22:43:28Z","isPatch":true,"body":"On 7/9/26 04:36, Ian Jackson wrote:\n\n> Colin Stagner writes (\"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite\"):\n>\n>> I think that subtree merge should only test the top-level project, as\n>> this patch does now.\n>\n> By \"top-level\" I think you mean what I've taken to calling the\n> \"downstream\": the project where the subtree is in a subdir, and whose\n> top-level has other stuff.  In which case I agree.\n\nYes, I think we're talking about the same thing.\n\nIn retrospect, \"top-level\" is ambiguous. \"Upstream\" and \"downstream\" may \nbe as well. Within git-branch(1), the phrase \"upstream\" refers to the \nremote tracking branch set by\n\n     git branch --set-upstream-to=<upstream>\n\ngit-merge(1) is consistent with this.\n\n     \"If no commit is given from the command line, merge the\n      remote-tracking branches that the current branch is\n      configured to use as its upstream.\"\n\ngit-subtree.sh doesn't really deal in \"upstreams\" in the git-branch or \ngit-merge sense.\n\nLess ambiguous language is available:\n\nFor merge commits, there is the \"first parent\" and \"second parent\" (or \n3rd or higher parents).\n\nFor trees, there is the \"root tree\" and \"sub-trees,\" like `git ls-tree -r`\n\n     -r     Recurse into sub-trees.\n\nBoth of these deliberately ignore the dependency relationship between \nthe various projects and branches in question, which can potentially get \nmessy.\n\n>>> +\tif git rev-parse --verify -q \"$rev:$config\"; then\n>>\n>> For subtree split, should we also test for this file in tree you are\n>> splitting: i.e., \"$dir/$config\"? The answer might be no.\n> \n> You're right that we should consider this question.  The answer is:\n> no, we should not.  Briefly, whether to use the new or old algorithms\n> depends on whether the downstream has adopted the new git-subtree, not\n> on whether the upstream has added some optional config.\n\nVery well-reasoned; I like it.\n\nLet me ask this question in a slightly different way: does RIIR subtree \nhonor config files in locations other than the one you test for above? \nThat's\n\n     ${rev}:.git-subtree/config\n\nwhich is `.git-subtree/config` within the root tree of the rev that is \nbeing manipulated?\n\nIf this is the only config file RIIR subtree honors, the patch is \nprobably correct. If RIIR subtree honors config from other places, such as\n\n* the working tree\n* HEAD:.git-subtree/config\n* HEAD:./.git-subtree/config\n\nthen consider testing for those if appropriate.\n\n>> Subtree merges can be performed without git-subtree, via the `-X\n>> subtree` merge strategy option.\n> \n> This is what I'm calling an \"unmarked subtree merge\".  My rewrite is\n> not going to support this user behaviour.  The problem is that it is\n> not possible to reliably determine whetheer something is an unmarked\n> subtree merge.\n\nThanks for looking at this.\n\n> Combining manual -X subtree merges with git-subtree --squash merges\n> could easily produce quite weird and wrong results in the tree\n\nI haven't tried it, but I think if --squash is in use, then attempting \nan unmarked subtree merge will probably die with \"unrelated history\" \nwarnings.\n\nLooking forward to v2,\n\nColin\n\n\n"},{"id":"547730","messageId":"27216.58259.815175.923629@chiark.greenend.org.uk","threadId":"65928","inReplyTo":"c8b81987-ab56-4d6b-a650-879b84597a17@howdoi.land","subject":"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite [and 1 more messages]","fromName":"Ian Jackson","fromEmail":"ijackson@chiark.greenend.org.uk","sentAt":"2026-07-10T12:20:35Z","receivedAt":"2026-07-10T12:20:43Z","isPatch":true,"body":"Colin Stagner writes (\"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite [and 1 more messages]\"):\n> In retrospect, \"top-level\" is ambiguous. \"Upstream\" and \"downstream\" may \n> be as well. Within git-branch(1), the phrase \"upstream\" refers to the \n> remote tracking branch set by\n\nUpstream and downstream are of course relative terms.  I think the\ngit usage you cite isn't quite central.\n\n> git-subtree.sh doesn't really deal in \"upstreams\" in the git-branch or \n> git-merge sense.\n\nI'm using \"upstream\" in the wider sense; here, when you import a\ndepedency you're downstream of it.\n\nI'm open to better terminology and now is a good time to be debating\nthis, but I don't like the other suggestions so far.\n\nI want a term that talks about the logical (even, social) relationship\nbetween the two projects; and it should be one that makes sense from\nthe point of view of the upstream.  Talking about the file position\nwithin the downstream tree doesn't make sense from the upstream's\npoint of view.\n\n> Both of these deliberately ignore the dependency relationship between \n> the various projects and branches in question, which can potentially get \n> messy.\n\nI think the dependency relationship is inherent in git-subtree's usual\nuse cases: suppose a project A gets merged with git-subtree into a\nsubdirectory S of project B, so that B.git:/S/ is a copy of A.git:/\n\nThen I think almost invariably, this is because A has B as a\ndependency.  And A has B as an upstream:\n\nCode that's part of B flows from B to A, and can be edited in A, but\nthe canonical version is that in B itself.  If there are multiple As\nincorporating the same B, they share via \"split\", which produces\nhistory \"within\" B.  Thios seems a classic upstream/downstream\nrelationship.\n\nAs I say, I'm open to other terminology but I don't think \"root tree\"\nand \"subtree\" are the general terms I need to describe the\nrelationship.  In particular, from the point of view of the upstream\nproject, it is its own root tree.\n\n> Very well-reasoned; I like it.\n> \n> Let me ask this question in a slightly different way: does RIIR subtree \n> honor config files in locations other than the one you test for above? \n> That's\n> \n>      ${rev}:.git-subtree/config\n\nYes, but not relevantly.  Different information is taken from\ndifferent places (the design gets a little complex to make sure\neverything works in all the use cases).\n\n> > Combining manual -X subtree merges with git-subtree --squash merges\n> > could easily produce quite weird and wrong results in the tree\n> \n> I haven't tried it, but I think if --squash is in use, then attempting \n> an unmarked subtree merge will probably die with \"unrelated history\" \n> warnings.\n\nI think that's not guaranteed if squash merges and non-squash merges\nare interleaved.\n\n> Looking forward to v2,\n\nThanks for your support, and your critical consideration of the design\nquestions.\n\nIan.\n\n-- \nIan Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.  \n\nPronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,\nthat is a private address which bypasses my fierce spamfilter.\n"},{"id":"547836","messageId":"CALnO6CAPMEjVsj-5X9VyUtGM1JipXj6g_0JrC5gk37s178G02A@mail.gmail.com","threadId":"65928","inReplyTo":"27215.27575.968985.583226@chiark.greenend.org.uk","subject":"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite [and 1 more messages]","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-07-11T13:41:55Z","receivedAt":"2026-07-11T13:42:06Z","isPatch":true,"body":"Hi Ian,\n\nOn Thu, Jul 9, 2026 at 5:48 AM Ian Jackson\n<ijackson@chiark.greenend.org.uk> wrote:\n[snip]\n> > On 7/6/26 06:58, Ian Jackson wrote:\n> > > Another, bigger, reason is that current git-subtree generates unmarked\n> > > subtree merges (ie, without any git-subtree trailers)\n> >\n> > Subtree merges can be performed without git-subtree, via the `-X\n> > subtree` merge strategy option. While the design of RIIR git-subtree is\n> > outside the scope of this patch series, this may be worth thinking about\n> > in your rewrite.\n>\n> This is what I'm calling an \"unmarked subtree merge\".  My rewrite is\n> not going to support this user behaviour.  The problem is that it is\n> not possible to reliably determine whetheer something is an unmarked\n> subtree merge.\n>\n> It is possible to guess based on tree similarity, but that's a\n> heuristic.  It's also possible to guess based on root commits.\n> Both of these approaches can go wrong in some cases.  I prefer to\n> write reliable software, which doesn't guess.\n>\n> I'll advise against this practice in the documentation, but I'm\n> reasonably confident that if a user does this anyway the results won't\n> be terrible.  The upstream input to an unmarked subtree merge in a\n> downstream that has already used my rewrite, will be treated as if it\n> were a downstream branch that predates the subtree addition.  The\n> effect on split (in most cases) is a missing parent relationship,\n> which is undesirable but not catastrophic.I've made a note to add a\n> test case for this scenario.\n>\n> Combining manual -X subtree merges with git-subtree --squash merges\n> could easily produce quite weird and wrong results in the tree (even\n> before anyone tries split, or something).  I don't think I can even\n> reliably detect this situation after the user has done it, and of\n> course since that user is using plain git, I certainly can't prevent\n> it.  This is another reason why manual use of -X subtree should be\n> discouraged.\n\nJust to make sure I understand you (I regularly use -X subtree with\none project): the Rust rewrite won't support -X subtree merges, but we\ndon't intend to discourage folks from using -X subtree merges in toto,\nright? Merely not support a mix of the 2?\n"},{"id":"547860","messageId":"27218.41052.331367.161844@chiark.greenend.org.uk","threadId":"65928","inReplyTo":"CALnO6CAPMEjVsj-5X9VyUtGM1JipXj6g_0JrC5gk37s178G02A@mail.gmail.com","subject":"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite [and 1 more messages]","fromName":"Ian Jackson","fromEmail":"ijackson@chiark.greenend.org.uk","sentAt":"2026-07-11T19:58:20Z","receivedAt":"2026-07-11T19:58:29Z","isPatch":true,"body":"D. Ben Knoble writes (\"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite [and 1 more messages]\"):\n> Just to make sure I understand you (I regularly use -X subtree with\n> one project): the Rust rewrite won't support -X subtree merges, but we\n> don't intend to discourage folks from using -X subtree merges in toto,\n> right? Merely not support a mix of the 2?\n\nPrecisely so.\n\nI think you may find my git-subtree rewrite superior in ergonomics to\ngit merge -X subtree so you might want to switch to it, when it exists\nand supports that transition.\n\nI haven't yet thought about how that transition ought to go but I\nthink it might look like what I'm calling an \"unmarked subtree\nmerge~.  I've made a TODO note in my working branch to remind myself\nto consider this situation.\n\nRegards,\nIan.\n\n-- \nIan Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.  \n\nPronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,\nthat is a private address which bypasses my fierce spamfilter.\n"},{"id":"547869","messageId":"xmqqmrvx86wi.fsf@gitster.g","threadId":"65928","inReplyTo":"27215.27575.968985.583226@chiark.greenend.org.uk","subject":"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite [and 1 more messages]","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-07-11T23:04:45Z","receivedAt":"2026-07-11T23:04:48Z","isPatch":true,"body":"Ian Jackson <ijackson@chiark.greenend.org.uk> writes:\n\n> Hi.  Thanks for the review.  I'll go through it point by point:\n>\n> Colin Stagner writes (\"Re: [PATCH 2/2] git-subtree: Bail out if we find output from Rust rewrite (test)\"):\n>> It may be slightly faster to create only one repo and just make orphan \n>> branches, like `test_create_subtree_add()` does.\n> ...\n>> `test_commit()` from test-lib-functions.sh may be superior to manually \n>> writing and committing this file.\n>\n> Thanks for the suggestions.  I'll take a look.\n\nSo, is there a conclusion after reviewing this?\n\nI think this is the only thing outstanding item among the review\ncomments this thread received.  Specifically, regarding the use of\n'local' discussed in the thread, our coding guidelines explicitly\nstate:\n\n - Even though \"local\" is not part of POSIX, we make heavy use of it\n   in our test suite.  We do not use it in scripted Porcelains, and\n   hopefully nobody starts using \"local\" before all shells that matter\n   support it (notably, ksh from AT&T Research does not support it yet).\n\nThus, we are fine there.\n\nJust responding belatedly as I was scanning topics that are marked\nas \"Expecting a reroll\" in my draft copy of the \"What's cooking\"\nreport that I work from.\n\nThanks.\n"},{"id":"547870","messageId":"a8c72dcd-f8d7-47ce-a4b2-ebcd4188875e@howdoi.land","threadId":"65928","inReplyTo":"xmqqmrvx86wi.fsf@gitster.g","subject":"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite [and 1 more messages]","fromName":"Colin Stagner","fromEmail":"ask+git@howdoi.land","sentAt":"2026-07-11T23:37:07Z","receivedAt":"2026-07-11T23:37:29Z","isPatch":true,"body":"On 7/11/26 18:04, Junio C Hamano wrote:\n\n> So, is there a conclusion after reviewing this?\n\nI think we're expecting a reroll, but this looks like the way forward.\n\nColin\n\n"},{"id":"547878","messageId":"27219.20156.438730.881821@chiark.greenend.org.uk","threadId":"65928","inReplyTo":"a8c72dcd-f8d7-47ce-a4b2-ebcd4188875e@howdoi.land","subject":"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite [and 1 more messages]","fromName":"Ian Jackson","fromEmail":"ijackson@chiark.greenend.org.uk","sentAt":"2026-07-12T08:22:20Z","receivedAt":"2026-07-12T08:22:24Z","isPatch":true,"body":"Colin Stagner writes (\"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite [and 1 more messages]\"):\n> On 7/11/26 18:04, Junio C Hamano wrote:\n> > So, is there a conclusion after reviewing this?\n> \n> I think we're expecting a reroll, but this looks like the way forward.\n\nYes.  Please bear with me, I'm travelling for a few days.\n\nIan.\n\n-- \nIan Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.  \n\nPronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,\nthat is a private address which bypasses my fierce spamfilter.\n"},{"id":"547900","messageId":"xmqq33xo729i.fsf@gitster.g","threadId":"65928","inReplyTo":"27219.20156.438730.881821@chiark.greenend.org.uk","subject":"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite [and 1 more messages]","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-07-12T13:42:33Z","receivedAt":"2026-07-12T13:42:36Z","isPatch":true,"body":"Ian Jackson <ijackson@chiark.greenend.org.uk> writes:\n\n> Colin Stagner writes (\"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite [and 1 more messages]\"):\n>> On 7/11/26 18:04, Junio C Hamano wrote:\n>> > So, is there a conclusion after reviewing this?\n>> \n>> I think we're expecting a reroll, but this looks like the way forward.\n>\n> Yes.  Please bear with me, I'm travelling for a few days.\n>\n> Ian.\n\nNo worries, and take your time.  I was just updating the status of\nthe various topics in the \"What's cooking\" draft.\n\nThanks.\n\n\n\n"},{"id":"548196","messageId":"b2e0142c-f8d3-442d-b3e7-63233ab88a17@howdoi.land","threadId":"65928","inReplyTo":"27216.58259.815175.923629@chiark.greenend.org.uk","subject":"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite [and 1 more messages]","fromName":"Colin Stagner","fromEmail":"ask+git@howdoi.land","sentAt":"2026-07-15T03:47:09Z","receivedAt":"2026-07-15T03:47:39Z","isPatch":true,"body":"Nothing here impacts the patch under review, so this is a bit OT, but...\n\nOn 7/10/26 07:20, Ian Jackson wrote:\n> Colin Stagner writes (\"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite [and 1 more messages]\"):\n> \n>> git-subtree.sh doesn't really deal in \"upstreams\" in the git-branch or\n>> git-merge sense.\n> \n> I'm using \"upstream\" in the wider sense; here, when you import a\n> depedency you're downstream of it.\n>\n> I want a term that talks about the logical (even, social) relationship\n> between the two projects; and it should be one that makes sense from\n> the point of view of the upstream.  Talking about the file position\n> within the downstream tree doesn't make sense from the upstream's\n> point of view.\nIt may be useful to differentiate between command documentation like \ngit-merge(1) and tutorial documentation like gitworkflows(7).\n\nThe man page for `merge` reads like: \"So you want to merge THIS into \nTHAT? Here's how to do it.\" The banner-line example is merging a topic \nbranch into master, but the \"social\" aspect of this is not front-and-center.\n\nOther common terms used in merges include \"ours\" (HEAD) and \"theirs\" \n(MERGE_HEAD, \"branch head,\" \"commit [that is being merged]\").\n\ngitworkflows(7) discusses the social relationships of branches, \nincluding the \"merge upwards\" workflow. Here is where we find more \nsocial terms like \"upstream\" and \"downstream:\"\n\n     The merge workflow works by copying branches between\n     upstream and downstream. Upstream can merge\n     contributions into the official history;\n     downstream base their work on the official history.\n\nBut \"upwards\" or \"upstream\" is merely in the direction of increasing \nstability or acceptance. This makes the terms \"upstream\" and \n\"downstream\" very broad and inclusive. An upstream branch might be in \nthe same repo, a parent repo of a fork, or an entirely different repo. \nThe repo might be yours or belong to someone else.\n\nBranches are branches, wherever they are.\n\n\n> I think the dependency relationship is inherent in git-subtree's usual\n> use cases: suppose a project A gets merged with git-subtree into a\n> subdirectory S of project B, so that B.git:/S/ is a copy of A.git:/\n> \n> Then I think almost invariably, this is because A has B as a\n> dependency.  And A has B as an upstream.\n\n\"Dependencies\" are perhaps a bit beyond Git's usual scope as I \nunderstand it.\n\nFor subtree merges, it is possible that \"largely unrelated\" minirepos \nare being collected together just to make them a monorepo. I have also \nused subtree merges within a single repo. This is handy to keep a \nsubproject isolated on its own branch for reuse elsewhere.\n\nFor splits, it's possible that history is split just to meet the needs \nof some other build system. I've observed this in the wild with AUR. \nI've seen multiple AUR packages stored together [1], but they must be \n`subtree split` first with aurpublish [2]. AUR users have been on-list \nbefore to report trouble with `subtree split` that I inadvertently \ncaused [3]. They may be very interested in your rewrite.\n\nIn conclusion,\n\n* Documentation is hard!\n\n* Consider focusing \"command-level\" documentation more on mechanics. Use \nvery specific terms like \"branch,\" \"(sub)tree,\" \"merge-base,\" etc.\n\n* Consider using \"upstream\" and \"downstream\" in the context of the \n\"merging upwards\" workflow from gitworkflows(7). It is not necessary for \nthese to be in another repo or even a different \"project.\"\n\nThese are just my recommendations, and they're not relevant for this \npatch series.\n\n\n>> I haven't tried it, but I think if --squash is in use, then attempting\n>> an unmarked subtree merge will probably die with \"unrelated history\"\n>> warnings.\n> \n> I think that's not guaranteed if squash merges and non-squash merges\n> are interleaved.\n\nProbably true.\n\n\nColin\n\n[1]: https://github.com/christian-heusel/aur\n\n[2]: https://github.com/eli-schwartz/aurpublish\n\n[3]: <755578cb-07e0-4b40-aa90-aacf4d45ccaa@heusel.eu>\n\n\n"},{"id":"551315","messageId":"xmqqcxv4eh7e.fsf@gitster.g","threadId":"65928","inReplyTo":"xmqq33xo729i.fsf@gitster.g","subject":"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite [and 1 more messages]","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-08-26T20:53:57Z","receivedAt":"2026-08-26T20:53:59Z","isPatch":true,"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:\n>\n>> Colin Stagner writes (\"Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite [and 1 more messages]\"):\n>>> On 7/11/26 18:04, Junio C Hamano wrote:\n>>> > So, is there a conclusion after reviewing this?\n>>> \n>>> I think we're expecting a reroll, but this looks like the way forward.\n>>\n>> Yes.  Please bear with me, I'm travelling for a few days.\n>>\n>> Ian.\n>\n> No worries, and take your time.  I was just updating the status of\n> the various topics in the \"What's cooking\" draft.\n\nAny change of plans or situation since then?\n\nThanks.\n"}]}