summaryrefslogtreecommitdiff
path: root/t/perf/p0003-delta-base-cache.sh
diff options
context:
space:
mode:
authorLibravatar Junio C Hamano <gitster@pobox.com>2017-11-09 11:49:45 +0900
committerLibravatar Junio C Hamano <gitster@pobox.com>2017-11-09 12:28:30 +0900
commit6d1700b8af43ea6078c8f17dedc0613431f6b07d (patch)
tree3735997037cd4842329078e6eb257c366b5b64a2 /t/perf/p0003-delta-base-cache.sh
parentGit 2.12.5 (diff)
downloadtgif-6d1700b8af43ea6078c8f17dedc0613431f6b07d.tar.xz
merge-base --fork-point doc: clarify the example and failure modes
The illustrated history used to explain the `--fork-point` mode named three keypoint commits B3, B2 and B1 from the oldest to the newest, which was hard to read. Relabel them to B0, B1, B2. Also illustrate the history after the rebase using the `--fork-point` facility was made. The text already mentions use of reflog, but the description is not clear what benefit we are trying to gain by using reflog. Clarify that it is to find the commits that were known to be at the tip of the remote-tracking branch. This in turn necessitates users to know the ramifications of the underlying assumptions, namely, expiry of reflog entries will make it impossible to determine which commits were at the tip of the remote-tracking branches and we fail when in doubt (instead of giving a random and incorrect result without even warning). Another limitation is that it won't be useful if you did not fork from the tip of a remote-tracking branch but from in the middle. Describe them. Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/perf/p0003-delta-base-cache.sh')
0 files changed, 0 insertions, 0 deletions