On 9/3/23 00:50, Junio C Hamano wrote:
Junio C Hamano <gitster@xxxxxxxxx> writes:
If you rewind to lose commits from the branch you are (re)building
against, and what was rewound and discarded was part of the work you
are building, whether it is on a local branch or on a remote branch
that contains what you have already pushed, they will be discarded,
it is by design, and it is a known deficiency with the fork-point
heuristics. How the fork-point heuristics breaks down is rather
well known ...
Another tangent, this time very closely related to this topic, is
that it may be worth warning when the fork-point heuristics chooses
the base commit that is different from the original upstream,
regardless of how we ended up using fork-point heuristics.
[snip]
Perhaps something along the lines of this (not even compile tested,
though)... It might even be useful to show a shortlog between the
.restrict_revision and .upstream, which is the list of commits that
is potentially lost, but that might turn out to be excessively loud
and noisy in the workflow of those who do benefit from the
fork-point heuristics because their project rewinds branches too
often and too wildly for them to manually keep track of. I dunno.
I like the idea of the warning, but it could be loud indeed and you'll
want to turn it off in that case.
--
Wesley
