Re: [PATCH 1/2] builtin/rebase.c: Emit warning when rebasing without a forkpoint

2 messages, 2 authors, 2023-09-02 · open the first message on its own page

Re: [PATCH 1/2] builtin/rebase.c: Emit warning when rebasing without a forkpoint

From: Junio C Hamano <hidden>
Date: 2023-09-01 18:11:01

Wesley [off-list ref] 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?  

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.

Puzzled.  

Re: [PATCH 1/2] builtin/rebase.c: Emit warning when rebasing without a forkpoint

From: Wesley <hidden>
Date: 2023-09-02 01:37:04

On 9/1/23 14:10, Junio C Hamano wrote:
Wesley [off-list ref] writes:
quoted
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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help