Re: [BUG] Highly inconsistent diff UI

Okay, so the point I was trying to make is:

The range version of $(git merge-base A B) B is B ^$(git merge-base A B), and not B --not $(git merge-base --all A B) [which is equivalent to B ^A or A..B].

Junio C Hamano wrote:

Sorry about that.  I'll rewrite it as a set of commands:

$ cd /tmp $ git clone gh:artagnon/clayoven $ cd clayoven $ git checkout -b pu master~10 $ echo "foom" >>LICENSE $ git commit -a -m "Change in pu" $ git checkout -b rebase.autostash master~5 $ echo "loom" >> clayoven.gemspec $ git commit -a -m "Change in rebase.autostash" $ git checkout master $ git merge pu $ git checkout rebase.autostash $ git merge pu $ echo "quux" >>Gemfile $ git commit -a -m "Change 2 in rebase.autostash" $ git log rebase.autostash ^master $ git log rebase.autostash --not $(git merge-base --all rebase.autostash master) $ git log rebase.autostash ^$(git merge-base rebase.autostash master) $ git diff rebase.autostash ^$(git merge-base rebase.autostash master)

Note that git diff can only take two endpoints so git merge-base --all is meaningless in this case.

To summarize: B ^(git merge-base A B) [the current ... syntax of git diff] has no exact equivalent in the log world. Therefore, no matter which existing rev spec we overload, we can never get the current ... for diff in a consistent manner.

We certainly know that 'git diff A~B' is going to be useful, and have an exact equivalent 'git log A~B' (but I'm not sure how useful it will be, because I don't work with merges much). The point is that it can be overloaded in a consistent manner for other commands like 'rebase -i' too.

I recently caved to overloading .. [1] because there's so much resistance to inventing a new rev spec. I'm not exactly elated with that.

[1]: http://thread.gmane.org/gmane.comp.version-control.git/222343