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:
> I dunno. The description you gave was insufficient for me to answer
> that question.
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 recently caved to overloading ..  because there's so much
resistance to inventing a new rev spec. I'm not exactly elated with
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html