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

On Mon, 06 Apr 2009 18:02:10 -0700, Junio C Hamano [off-list ref] wrote:

David Kågedal [off-list ref] writes:

quoted

quoted

   - 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.

quoted

quoted

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.