David Kågedal [off-list ref] writes:
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".
quoted
Think. What does "git log STAGE" mean? Can you explain why it does not
make any sense?
As I already explained, you read way to much into my message.
I think the fundamental difference between us is that you are too attached
to the notion of "for diff you can use these metavariables to name two
things compared". That by itself looks very nice if you only look at the
diff command line, but I do not want "but you can do so only for diff, so
you have to unlearn the metavariables and do thing in different ways for
other commands" part.
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.