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? But you are right: since the reflog for a branch is in a different file from the branch head, there is no way to do an update to both of them at the same time. I guess this will have to be a reftable-only feature. > I believe that today git can do very fast reachability checks without opening > pack files by using some of its indexes (bitmap code or https://git-scm.com/ > docs/commit-graph ?). It probably makes sense to add this ability to jgit if > that is what you need? The bitmaps are generated by GC, and you can't GC all the time. JGit has support for bitmaps, and its support actually predates C-Git's support for it. (It was added to JGit by Colby Ranger who worked in Shawn's team). I expect that the commit graph doesn't work for my intended use-case. -- 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
