Re: Command-line interface thoughts
- From
- Michael Nahas <mike.nahas@gmail.com>
- Date
- Jun 7, 2011, 11:04 UTC
- Message-ID
- <BANLkTi=Wu77cJikN63NjSqb-PtB4+9BiEQ@mail.gmail.com>
- In-Reply-To
- <7voc2a70f0.fsf@alter.siamese.dyndns.org>
On Tue, Jun 7, 2011 at 12:03 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 6 quoted lines
> Michael Nahas <mike.nahas@gmail.com> 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?
Good question. You've been asking it a lot. I answered it later in the email.
Show 8 quoted lines
> 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.
(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