Re: The case for two trees in a commit ("How to make rebase less modal")
- Date: Wed, 28 Feb 2018 23:26:20 -0500
- From: Jeff King <peff@xxxxxxxx>
- Subject: Re: The case for two trees in a commit ("How to make rebase less modal")
On Wed, Feb 28, 2018 at 03:30:27PM -0800, Stefan Beller wrote:
> 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).