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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 1, 2018, 18:50 UTC
Message-ID: <xmqqd10nhbq6.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CA+P7+xpB36t7WHpYOa+8wc7kLY7ES_bVEnSHPYHJ50gJ03uQBw@mail.gmail.com>

Jacob Keller <jacob.keller@gmail.com> writes:

Show 6 quoted lines

> 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 you write four trees out of each stage in the index and record them, you could in theory have a new command that reads them and recreate the conflicted index. Oh, and then you would need the fifth tree that records what the working-tree files (with conflict markers) looked like, in order to reproduce the state seen by the person who ran "git merge", attempted to resolve and gave up halfway in the middle.

As a local operation, extending "git stash" somehow so that it can stash even in a conflicted working tree may be a better approach, and it does not need cruft headers in commit objects, I would think.