On Wed, Feb 28, 2018 at 3:30 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: > $ 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 > EOF > 19abfc3bf1c5d782045acf23abdf7eed81e16669 > $ 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. > How does this let you defer a conflict? A future commit which modified blobs in that tree wouldn't know what version of the trees/blobs to actually use? Clearly future commits could record their own trees, but how would they generate the "correct" tree? Maybe I am missing something here? Thanks, Jake > 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? > > Thanks, > Stefan
