git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Distinguishing FF vs non-FF updates in the reflog?

From
Han-Wen Nienhuys <hanwen@google.com>
Date
Mar 18, 2021, 08:58 UTC
Message-ID
<CAFQ2z_MavgAGDyJzc9-+j6zTDODP7hCdPHtB5dyx-reLMSLX3Q@mail.gmail.com>
In-Reply-To
<5359503.g8GvsOHjsp@mfick-lnx>
On Wed, Mar 17, 2021 at 10:22 PM Martin Fick <mfick@codeaurora.org> wrote:
Show 15 quoted lines
>
> 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
Previous: Martin FickNext: Jeff King
Message 3 of 19 in “Distinguishing FF vs non-FF updates in the reflog?”
  1. Han-Wen NienhuysMar 17, 2021
  2. Martin FickMar 17, 2021
  3. Han-Wen NienhuysMar 18, 2021
  4. Jeff KingMar 18, 2021
  5. Martin FickMar 18, 2021
  6. Han-Wen NienhuysMar 22, 2021
  7. Martin FickMar 22, 2021
  8. Martin FickMar 18, 2021
  9. Jeff KingMar 18, 2021
  10. Jeff KingMar 18, 2021
  11. Han-Wen NienhuysMar 22, 2021
  12. Jeff KingMar 26, 2021
  13. Ævar Arnfjörð BjarmasonMar 22, 2021
  14. Han-Wen NienhuysMar 22, 2021
  15. Ævar Arnfjörð BjarmasonMar 22, 2021
  16. Han-Wen NienhuysMar 22, 2021
  17. Ævar Arnfjörð BjarmasonMar 22, 2021
  18. Han-Wen NienhuysMar 22, 2021
  19. Junio C HamanoMar 22, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.