Re: [RFC PATCH 1/1] Define an extended tree format

From: Elijah Newren <newren@gmail.com>
Date: Oct 1, 2025, 21:21 UTC
Message-ID: <CABPp-BEAawZgDz+bBizUVz1=9XHE_g3vWGV17JooUes=JSmkwA@mail.gmail.com>
In-Reply-To: <20251001005814.846992-2-sandals@crustytoothpaste.net>

On Tue, Sep 30, 2025 at 5:58 PM brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 8 quoted lines

>
> +Following that is a modified BER-encoded integer representing the type of
> +object and a modified BER-encoded integer consisting of flags.
> +
> +The object type is one of the following:
> +
> +0:: invalid
> +1:: conflict tree (only valid at top level)

I think there may have been some miscommunication. There was discussion around "at the toplevel" and "trees," but I believe "at the toplevel" was meant to refer to the commit itself -- specifically, for each commit, at the highest level of the objects it references (i.e., the commit object). The idea is that conflict information would be represented by multiple traditional toplevel trees (or possibly even commits?) recorded in the commit object, with no conflicts recorded within any individual tree. Instead, the existence of multiple distinct toplevel trees is what would signal a conflict.

Recording conflict information in trees rather than commits, as this proposal suggests (even if only at the toplevel tree), introduces a problem similar to what Martin mentioned yesterday regarding blobs. In particular, doing so would require every `git log` operation -- which wants to determine if a commit is conflicted so it can highlight it for users -- to walk not only the commits but also additional objects. Even if limited to just one extra level for toplevel trees, it effectively doubles the objects traversed for non-diffing log operations, impacting performance for everyone, not just those using conflict headers. I’d prefer to avoid imposing a performance penalty on users who don’t use any new features associated with first-class conflicts.

Additionally, I believe this approach would diverge from how jj and GitButler record conflicted commits. I’d rather follow the path they paved to benefit from their expertise and minimize (if not eliminate) any possible rework they need for continued interoperability with Git versions that gain features they first implemented.

We may find reason to revisit this as things progress, but for now, I don’t conflicted trees needs to be included in your modified tree proposal.