Hi Srinidhi,
On Thu, 10 Sep 2020, Srinidhi Kaushik wrote:
> 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
