Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite [and 1 more messages]

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
Date: Jul 10, 2026, 12:20 UTC
Message-ID: <27216.58259.815175.923629@chiark.greenend.org.uk>
In-Reply-To: <c8b81987-ab56-4d6b-a650-879b84597a17@howdoi.land>

Colin Stagner writes ("Re: [PATCH 1/2] git-subtree: Bail out if we find output from Rust rewrite [and 1 more messages]"):

> In retrospect, "top-level" is ambiguous. "Upstream" and "downstream" may 
> be as well. Within git-branch(1), the phrase "upstream" refers to the 
> remote tracking branch set by

Upstream and downstream are of course relative terms. I think the git usage you cite isn't quite central.

> git-subtree.sh doesn't really deal in "upstreams" in the git-branch or 
> git-merge sense.

I'm using "upstream" in the wider sense; here, when you import a depedency you're downstream of it.

I'm open to better terminology and now is a good time to be debating this, but I don't like the other suggestions so far.

I want a term that talks about the logical (even, social) relationship between the two projects; and it should be one that makes sense from the point of view of the upstream. Talking about the file position within the downstream tree doesn't make sense from the upstream's point of view.

> Both of these deliberately ignore the dependency relationship between 
> the various projects and branches in question, which can potentially get 
> messy.

I think the dependency relationship is inherent in git-subtree's usual use cases: suppose a project A gets merged with git-subtree into a subdirectory S of project B, so that B.git:/S/ is a copy of A.git:/

Then I think almost invariably, this is because A has B as a dependency. And A has B as an upstream:

Code that's part of B flows from B to A, and can be edited in A, but the canonical version is that in B itself. If there are multiple As incorporating the same B, they share via "split", which produces history "within" B. Thios seems a classic upstream/downstream relationship.

As I say, I'm open to other terminology but I don't think "root tree" and "subtree" are the general terms I need to describe the relationship. In particular, from the point of view of the upstream project, it is its own root tree.

Show 7 quoted lines

> Very well-reasoned; I like it.
> 
> Let me ask this question in a slightly different way: does RIIR subtree 
> honor config files in locations other than the one you test for above? 
> That's
> 
>      ${rev}:.git-subtree/config

Yes, but not relevantly. Different information is taken from different places (the design gets a little complex to make sure everything works in all the use cases).

Show 6 quoted lines

> > Combining manual -X subtree merges with git-subtree --squash merges
> > could easily produce quite weird and wrong results in the tree
> 
> I haven't tried it, but I think if --squash is in use, then attempting 
> an unmarked subtree merge will probably die with "unrelated history" 
> warnings.

I think that's not guaranteed if squash merges and non-squash merges are interleaved.

> Looking forward to v2,

Thanks for your support, and your critical consideration of the design questions.

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.