Re: [PATCH 2/3] merge-base: return fork-point outside reflog

[Junio C Hamano <gitster@pobox.com>]

Michael J Gruber <git@grubix.eu> writes:

> I'm still trying to understand what the original intent was: If we
> abstract from the implementation (as we should, as you rightly
> emphasize) and talk about historical tips then we have to ask ourselves:
> - What is "historical"?
> - What is tip?
> - Tip of what, i.e. what is a "branch"?

The feature was meant to be a solution for "upstream rebased the
branch I based my work on."

Suppose you did

	git clone $URL
	git checkout -b mytopic origin/topic
	work work work and commit commit commit

and then the next "git fetch" found that remote/origin/topic did not
fast-forward, i.e. your upstream rewound and rebuilt the topic.

Now, running

	git rebase origin/topic mytopic

would be a disaster, as it would try to replay all the commits
reachable from mytopic on top of the updated origin/topic, but the
set of commits reachable from mytopic includes those the upstream
used to have, on top of which you based your work, and you are not
interested in replaying them at all.

If you remember where you forked your topic from (you should be able
to tell from "git log mytopic"), then

	git rebase --onto origin/topic $fork_point mytopic

would be the way to replay "your" work on mytopic on top of the
updated upstream.

The reason why "--fork-point" exists is because people wanted to
automate the "remember where you forked your topic from" part.

Your upstream might have rewound the tip of topic many times while
your repository did not fetch from it (iow, the reflog for
origin/topic may not have _all_ the tips of other people observed to
be historicallly at the tip of the remote), but that is immaterial
for our purpose.  As long as you built on top of origin/topic, the
fork point must be one of the commits _you_ saw at the tip and it
does not matter that you did not constantly fetch to observe all the
changes at the remote.

So the answers of these three questions are:

 - "historical": _you_ saw in your repository;

 - "tip": _you_ saw it pointed by the branch you forked your work
   from; and

 - "branch": whatever you consider you based your work on top of,
   typically a remote tracking branch.

Of course, if you are employing a more advanced workflow, you might
not have started your mytopic branch at any of the tip.  E.g.  if
you wanted to extend Ben's fsmonitor topic, you would have forked
your own topic like

	git checkout -b my-fsmonitor origin/pu^2

after fetching from me, and --fork-point would not be of much help
obviously for such a workflow.  But such users will use --onto and
explicitly specify the fork point so it is outside the scope of the
feature.