Re: The case for two trees in a commit ("How to make rebase less modal")
- Date: Wed, 28 Feb 2018 23:25:07 -0800
- From: Jacob Keller <jacob.keller@xxxxxxxxx>
- Subject: Re: The case for two trees in a commit ("How to make rebase less modal")
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
> $ 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?
> 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?