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). -Peff
