On 9/1/23 14:10, Junio C Hamano wrote:
Wesley <wesleys@xxxxxxxxxxxxxxx> writes:
The quirk is this: --fork-point looks at the reflog and reflog is
local. Meaning, having an remote upstream branch will make
--fork-point a noop. Only where you have an upstream which is local
and your reflog has seen dropped commits it does something.
Why do you lack reflog on your remote-tracking branches in the first
place?
I do not know? I tested with a bare repo and two clones. And I also
tested it with just a remote upstream in another branch.
When in repo-1 I do the reset --hard HEAD^, and push the results, and
pull them in in repo-2 the behavior doesn't replicate. The git reflog
command doesn't show the reset.
However, if I delete the reflog entry for removal of the reset HEAD^,
git rebase exposes the fork-point behavior.
The fork-point heuristics, as far as I understand it, was invented
exactly to protect you from your upstream repository rewinding and
rebuilding the branch you have been building on top of. The default
fetch refspec +refs/heads/*:refs/remotes/origin/* has the "force"
option "+" in front exactly because the fetching repository is
expected to keep the reflog for remote-tracking branches to help
recovering from such a rewind & rebuild.
I haven't force pushed anything btw, maybe that could explain things?
Cheers,
Wesley
--
Wesley
Why not both?
