Re: [PATCH 1/2] builtin/rebase.c: Emit warning when rebasing without a forkpoint
- From
Wesley <wesleys@opperschaap.net>
- Date
- Sep 2, 2023, 01:35 UTC
- Message-ID
- <fa702b47-ae29-4299-9226-4920620b9fff@opperschaap.net>
- In-Reply-To
- <xmqqledppxw3.fsf@gitster.g>
On 9/1/23 14:10, Junio C Hamano wrote:
Show 9 quoted lines
> Wesley <wesleys@opperschaap.net> 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.
Show 7 quoted lines
> 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?