Re: The case for two trees in a commit ("How to make rebase less modal")

From: Jeff King <peff@peff.net>
Date: Mar 1, 2018, 04:26 UTC
Message-ID: <20180301042620.GA21310@sigill.intra.peff.net>
In-Reply-To: <CAGZ79ka6PXgs+JDicaQYWYSKgEthj0A-2bBaRcdp_0T2H+sREA@mail.gmail.com>

On Wed, Feb 28, 2018 at 03:30:27PM -0800, Stefan Beller wrote:

Show 12 quoted lines

> During the rebase there might be a hard to resolve conflict, which
> you may not want to resolve right now, but defer to later.  Deferring a
> conflict is currently impossible, because precisely one tree is recorded.
> 
> If we had multiple trees possible in a commit, then all these large scale
> operations would stop being modal and you could just record the unresolved
> merge conflict instead; to come back later and fix it up later.
> 
> I'd be advocating for having multiple trees in a commit
> possible locally; it might be a bad idea to publish such trees.
> 
> Opinions or other use cases?

What benefit does it have over adding a new header "unresolved-tree" or similar? I do not think you are getting any backwards compatibility here. For instance, "prune" will not traverse it with existing versions of git, nor "pack-objects" include it in a pack (I didn't actually test it, so I could be wrong; but those are all based around parse_commit, which should look at only the first tree).

-Peff