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