From: Wesley Date: Sat, 02 Sep 2023 01:35:33 GMT Subject: Re: [PATCH 1/2] builtin/rebase.c: Emit warning when rebasing without a forkpoint Message-ID: In-Reply-To: On 9/1/23 14:10, Junio C Hamano wrote: > Wesley 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?