Itches with the current rev spec

[Ramkumar Ramachandra <artagnon@gmail.com>]

Hi,

So, I have three serious itches that would be nice to address:

1. git reset --hard HEAD~1/ git show HEAD~1 is a very common idiom
that's unnecessarily cumbersome to type out.  We can make the <rev>
part of <rev>~<n> optional without being ambiguous: you might argue
that ~<n> normally refers to a /home/<n>, but who uses numbers in
place of usernames?  Even if they do, how can that path possibly be
inside our repository?

2. git rebase -i master fails unless I've rebased my branch on top of
master.  I always wished I could do the equivalent of 'git rebase -i
master..', but I can't.  Can we give the A..B syntax a new meaning in
the context of rebase, namely $(git merge-base A B)?  No, this is not
similar to the current diff A..B at all: first, we don't operate on
two endpoints (so 'git rebase -i A B' is nonsensical, and only the
'git rebase -i A ^B'/ 'git rebase -i ^A B' should be handled as
special cases); second, we're trying to be consistent with the
end-result meaning of A..B in ranged-commands like log (as opposed to
diff, which is being inconsistent).

3. Even though I lashed out strongly against 'git diff A..B' because
of inconsistency, I can't say that it's not useful (omit specifying
HEAD on one side).  If we were to start over today, I would argue that
'git diff A ^B' and 'git diff B ^A' be handled as special cases to
mean 'git diff B $(git merge-base A B)' and 'git diff $(git merge-base
A B) B' respectively.  The normal 'git diff A B' should have nothing
to do with this.  Plus, 'git diff A...B' is really an eyesore.  So I
ask again: what can be done to improve the situation?

Thanks.