Junio C Hamano venit, vidit, dixit 06.06.2011 08:16:
> Scott Chacon <schacon@xxxxxxxxx> writes:
>
>> For example, implementation details aside, I think having something
>> like WTREE and NEXT available would help users understand that there
>> are these 3 trees that are important and useful in Git and re-inforce
>> a very non-SVN style workflow in that manner.
>
> That's a funny thing to say. Working tree may almost always (to put it
> another way, "you could make it to") act like a tree, but the index does
> not act like a tree at all in more important situations.
>
> For example, how would you design the user experience of "git show NEXT"?
> Try to write a transcript (i.e. "The user starts from this state, runs
> these commands, and then says 'git show NEXT'. The user will see this."),
> covering various corner cases exhaustively, including what would happen
> before the first commit, and during a conflicted "pull" or "rebase -i".
>
> It's not just the matter of "internally pretend to run write-tree with
> 'not committed yet' as a fake commit log message and show it as if it is
> an existing commit.
>
> I wouldn't demand "implement 'git show NEXT'" here, nor "implement it
> efficiently" here; just designing the user experience is a good first step
> to realize that the index does not act like a tree, and I do not think you
> should spread such a misconception to the end users.
That is why the other Michael suggested "NEXT" as opposed to "INDEX":
The index has many aspects, only one of which is "the contents of the
next commit if I would issue 'git commit' right now". (I would even go
so far as using "STAGE".) Now, it's hard to argue that "the result of a
commit" is not tree-like, isn't it? And there's no question what "git
show NEXT" would do. Yes, if you repeat that command, you get a
different sha1 each time (because of the time field).
I don't think anyone is seriously suggesting to replace the index by a
pseudo commit; but the one aspect which people use most could be well
represented like that, and this might even help emphasizing the
different aspects of the index. Give the index an identity as an
"object" (no, no new type, not in the object db, but as a ui object),
not something mysterious behind the scenes!
As for WTREE: git diff against work tree does not look at non-tracked
ignored files, so why should WTREE?
Full disclosure: I love the index but hate the way we make it difficult
to use sometimes, and even have to lookup myself what command and option
to actually use if all I want to do is diff A against B, or take the
version of a file from A and write it to B, when A and B are a commit,
the index or the worktree (with a commit being the nonwritable, of course).
I mean, this is really crazy: We have 4 commands ("add", "rm
[--cached]", "checkout [<commit>] --", "reset [<commit>] --") which you
need to be aware of if all you want to do is moving file contents
(content at a path) between a commit, the index and the worktree! And
this is actually worse than having 6 for the 6 cases.
Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html