Jeff King <peff@xxxxxxxx> writes:
> E.g., imagine resolving "main" to 1234abcd in step one, then somebody
> updates it to 5678cdef, then you run "for-each-ref" to compute
> ahead/behind, and now you show an inconsistent result: you say that
> "main" points to 1234abcd, but show the wrong ahead/behind information.
>
> Showing 1234abcd at all is out-of-date, of course, but the real problem
> is the lack of atomicity. Most porcelain scripts deal with this by
> resolving the refs immediately, assuming object ids are immutable (which
> they are modulo games like refs/replace), and then working with them.
A really paranoid caller can use %(ahead-behind-detail:refs/heads/main)
and get a report on refs/heads/topic, something that conveys
refs/heads/topic (at 67f9f40d) is ahead by 2 commits and behind
by 4 commits relative to refs/heads/main (at d7c3a768).
in a machine readable form. And when the "ahead by 2 commits"
disappears, we know 67f9f40d is merged to main sometime before
d7c3a768. Then it can say "update-ref -d refs/heads/topic 67f9f40d"
to avoid racing with simultanous updaters.
