On Thu, Mar 18, 2021 at 11:24 PM Martin Fick <mfick@xxxxxxxxxxxxxx> wrote: > > On Thursday, March 18, 2021 9:58:56 AM MDT Han-Wen Nienhuys wrote: > > On Wed, Mar 17, 2021 at 10:22 PM Martin Fick <mfick@xxxxxxxxxxxxxx> wrote: > > > On Wednesday, March 17, 2021 9:06:06 PM MDT Han-Wen Nienhuys wrote: > > > > I'm working on some extensions to Gerrit for which it would be very > > > > beneficial if we could tell from the reflog if an update is a > > > > fast-forward or not: if we find a SHA1 in the reflog, and see there > > > > were only FF updates since, we can be sure that the SHA1 is reachable > > > > from the branch, without having to open packfiles and decode commits. > > > > > > I don't think this would be reliable. > > > > > > 1) Not all updates make it to the reflogs > > > 2) Reflogs can be edited or mucked with > > > 3) On NFS reflogs can outright be wrong even when used properly as their > > > are caching issues. We specifically have seen entries that appear to be > > > FFs that were not. > > > > Can you tell a little more about 3) ? SInce we don't annotate non-FF > > vs FF today, what does "appear to be FFs" mean? > > To be honest I don't recall for sure, but I will describe what I think has > happened. I think that we have seen a server(A) update a branch from > C1 to C2A, and then later another server(B) update the same branch from C1 to > C2B. Obviously the move from C2A to C2B is not a FF, but that move is not what > is recorded. Each of those updates was a FF when viewed as separate entries, I think those would fail with the way that Gerrit uses JGit, because C1 -> C2B would fail with LOCK_ERROR. I guess there are code paths in Git (?) that will execute force-push without checking if the update is FF or not. -- Han-Wen Nienhuys - Google Munich I work 80%. Don't expect answers from me on Fridays. -- Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
