Michael Nahas [off-list ref] writes:
I think NEXT and WTREE should be like tree objects, not commits, so I
would argue that "git show NEXT" should show what it shows for a tree.
So what is the definition of such a "tree" during a conflicted merge?
The traditional definition is "such a state cannot be expressed as a
tree". You are free to define it the same way, or for NEXT to be more
useful than status quo, come up with a better definition.
My thought is that NEXT should only represent those changing files
that have been resolved. So, NEXT would be HEAD plus the files in
Stage0. So, "git diff HEAD NEXT" would print out the changes in
Stage0.
That would mean conflicted files will all be shown as removed, or
unchanged? Either would be more confusing.
On Tue, Jun 7, 2011 at 12:03 AM, Junio C Hamano [off-list ref] wrote:
Michael Nahas [off-list ref] writes:
quoted
I think NEXT and WTREE should be like tree objects, not commits, so I
would argue that "git show NEXT" should show what it shows for a tree.
So what is the definition of such a "tree" during a conflicted merge?
Good question. You've been asking it a lot. I answered it later in the email.
The traditional definition is "such a state cannot be expressed as a
tree". You are free to define it the same way, or for NEXT to be more
useful than status quo, come up with a better definition.
quoted
My thought is that NEXT should only represent those changing files
that have been resolved. So, NEXT would be HEAD plus the files in
Stage0. So, "git diff HEAD NEXT" would print out the changes in
Stage0.
(during a conflicted merge...)
"NEXT would be HEAD plus the files in Stage0".
That is the tree. HEAD plus the resolved files.
That would mean conflicted files will all be shown as removed, or
unchanged? Either would be more confusing.
Conflicted files would be shown as unchanged in NEXT.
"diff NEXT HEAD" == changes in resolved files
"diff WTREE NEXT" == changes in conflicted files
"diff WTREE HEAD" == all changes.
That makes a lot of sense to me. Those are the three different
changesets I'd want to see and those are the logical commands using
NEXT and WTREE to see them.
I _believe_ but don't know for sure that that _is_ the current behavior for:
"diff --cached HEAD" and
"diff --cached"
"diff HEAD"
If it is the current behavior, I don't see how it could be more
confusing. It's exactly the same amount of confusing ... with a more
regular syntax, IMHO.
Another way to think about this: If you had a conflicted merge and
someone allowed you to create the next commit with a command "git
commit --force", what would you expect to be in the created commit?
Wouldn't it be only the resolved files? The files in Stage0? The
files in WTREE have the "<<<<</=====/>>>>>" blocks in them - would you
want to commit those? No. For those files, you'd prefer the versions
you already had in HEAD.
Mike