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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 22, 2017, 09:14 UTC
Message-ID: <xmqqa81njds0.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <4a14c35c-88b0-7bc3-0a6e-c69ed9ec7ee7@grubix.eu>

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

Show 6 quoted lines

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