Web lists-archives.com

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

$ git hash-object --stdin -w -t commit <<EOF
tree c70b4a33a0089f15eb3b38092832388d75293e86
parent 105d5b91138ced892765a84e771a061ede8d63b8
author Stefan Beller <sbeller@xxxxxxxxxx> 1519859216 -0800
committer Stefan Beller <sbeller@xxxxxxxxxx> 1519859216 -0800
tree 5495266479afc9a4bd9560e9feac465ed43fa63a
test commit
$ git fsck |grep 19abfc3bf1c5d782045acf23abdf7eed81e16669

So it is technically possible to create a commit with two tree entries
and fsck is not complaining.

But why would I want to do that?

There are multiple abstraction levels in Git, I think of them as follows:
* data structures / object model
* plumbing
* porcelain commands to manipulate the repo "at small scale", e.g.
create a commit/tag
* porcelain to modify the repo "at larger scale", such as rebase,
cherrypicking, reverting
  involving more than 1 commit.

These large scale operations involving multiple commits however
are all modal in its nature. Before doing anything else, you have to
finish or abort the rebase or you need expert knowledge how to
go otherwise.

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?