Re: [RFC/PATCH 0/2] New 'stage' command

["Octavio Alvarez" <alvarezp@alvarezp.ods.org>]

On Mon, 06 Apr 2009 18:02:10 -0700, Junio C Hamano <gitster@pobox.com> wrote:

> David Kågedal <davidk@lysator.liu.se> writes:
>
>>>    - when you want to work with both the index and the work tree at the
>>>      same time, you say STAGEANDWORKTREE (the same disambiguation  
>>> caveat
>>>      applies).
>>
>> No, where did this come from?
>
> "git apply STAGEANDWORKTREE this.patch".  I do not want "for diff you can
> use these metavariables to name two things compared, but you can do so
> only for diff".

That example is broken. git apply doesn't even take an arbitrary treeish.

>>> Think.  What does "git log STAGE" mean?  Can you explain why it does  
>>> not
>>> make any sense?

gitk actually does this. Even more, gitk shows them in this order:
STAGE^ would be HEAD.
WORKTREE^ would be STAGE.

Makes sense.

(Not that I think git log should do the same.)

The difference between git diff and git reset is that git diff should take
a range of trees, not a range of commits as parameters. OTOH, git reset
doesn't know or care about trees, it needs commits.

git checkout WORKTREE:file makes sense, even though it is useless, but
that's why it git checout STAGE:file makes sense: it should accept any tree
instead of a commit.

git apply doesn't even take commits. It *could* take trees if it
automagically created a branch on the commit, though. Either that,
or git-apply shouldn't exist at all.

It's similar with git reset. You wouldn't use STAGE or WORKTREE here because
a commit is actually necessary, but according option names like: --stage
--worktree --both --none are better than --hard, --soft and --mixed.

So, if the man page for git-reset says "commit-id" and the man page for
git diff says "tree-id..tree-id", I don't see any kind of confusion.
git checkout could too. git reset and git log are to say "commit-id",
but support clearer options.

WORKTREE, STAGE are trees as commits are also trees, but not all trees are
commits.