Re: [PATCH] push: make `--force-with-lease[=<ref>]` safer
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Sep 11, 2020, 22:16 UTC
- Message-ID
- <nycvar.QRO.7.76.6.2009120013070.56@tvgsbejvaqbjf.bet>
- In-Reply-To
- <20200910144456.GA25125@mail.clickyotomy.dev>
Hi Srinidhi,
On Thu, 10 Sep 2020, Srinidhi Kaushik wrote:
Show 26 quoted lines
> On 09/10/2020 12:22, Johannes Schindelin wrote:
>
> > BTW I think the patch needs to cover a bit more, still: after I run `git
> > pull --rebase`, the local branch will never have been at the same revision
> > as the fetched one: `git rebase` moves to an unnamed branch before
> > replaying the patches. So I think we need to see whether the remote tip
> > was _reachable_ from (not necessarily identical to) any of the reflog's
> > revisions.
>
> Good catch. Would adding in_merge_bases() along with checking if OIDs
> are equal for each reflog entry in oid_in_reflog_ent() address the
> problem? That way, we would check if remote ref is reachable from
> one of the entries?
>
> Thanks.
>
> -- >8 --
> + static int oid_in_reflog_ent(struct object_id *ooid, struct object_id *noid,
> + const char *ident, timestamp_t timestamp, int tz,
> + const char *message, void *cb_data)
> + {
> + struct object_id *remote_oid = cb_data;
> + struct commit *a = lookup_commit_reference(the_repository, noid);
> + struct commit *b = lookup_commit_reference(the_repository, remote_oid);
> + return oideq(noid, remote_oid) || in_merge_bases(b, a);
> + }Since `in_merge_bases()` is quite a bit more expensive than `oideq()`, personally, I would actually walk the reflog with the `oideq()` check first (stopping early in case a match was found), and only fall back to looking for a merge base in the reflog if the first reflog walk did not find a match.
Ciao, Dscho