Ramkumar Ramachandra <artag...@gmail.com> writes:
> 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:
[now that a few days have passed...]
Please don't. All of these clayoven, LICENSE, foom, loom are mere
... goes and draws the diagram himself ...
> $ git clone gh:artagnon/clayoven
> $ cd clayoven
A > $ git checkout -b pu master~10
> $ echo "foom" >>LICENSE
B > $ git commit -a -m "Change in pu"
C > $ git checkout -b rebase.autostash master~5
> $ echo "loom" >> clayoven.gemspec
D > $ git commit -a -m "Change in rebase.autostash"
E > $ git checkout master
F > $ git merge pu
> $ git checkout rebase.autostash
G > $ git merge pu
> $ echo "quux" >>Gemfile
H > $ git commit -a -m "Change 2 in rebase.autostash"
So you have this:
/ \ /
/ D---G---H /
/ / /
(master~10) (master~5) (master-old)
In the beginning, master was at E, but at the end, it is moved to
F. The tip of your topic is at H.
> $ git log rebase.autostash ^master
That is range "F..H", which lists "H G D".
> $ git log rebase.autostash --not $(git merge-base --all rebase.autostash
The merge bases between F and H are B and C, so that is
range "^B ^C H", which again lists "H G D".
> $ git log rebase.autostash ^$(git merge-base rebase.autostash master)
Depending on which one of B or C is chosen it is either one of these:
- range "^B H" which lists "H G D C"
- range "^C H" which lists "H G D B"
neither of which is more useful than "H G D", as it shows irrelevant
"other merge base" you did not pick.
> $ git diff rebase.autostash ^$(git merge-base rebase.autostash master)
This will show either "diff B H", which is work done by G and H, or
"diff C H", which is work done by D thru H. In the former, "the
work done by G" includes what was done by A..D, which are mostly
irrelevant to explain what you did on your topic, but you asked for
it. In the latter, "the work done by G" is what was done by A..B,
which again are not what D and H did.
The example explains why you should not merge other's work to your
topic branch [*1*], but does not say anything about usefulness of
A...B vs A~B.
> To summarize: B ^(git merge-base A B) [the current ... syntax of git
> diff] has no exact equivalent in the log world.
Nor does "log" need one. See how picking either B or C and omitting
the other would produce worse result than excluding all merge bases,
which log F..H would naturally does.
> Therefore, no matter
> which existing rev spec we overload, we can never get the current ...
> for diff in a consistent manner.
As "log" does not need any such thing, that is irrelevant, no?
> We certainly know that 'git diff A~B' is going to be useful,...
We certainly know it is an unnecessary "there is another way to
spell the same thing we have been using for a long time".
You did not give anything new that hints that it might be worth
spending time listening to you in this message. Should I do a "kill
file for a few days" thing again?
*1* Instead, you have a separate integration branch for testing that
merges other's work and your topic.
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