Instead, work directly with update-flags. This has the advantage that
the REF_DELETING bit, set in the first loop, can be read in the third
loop instead of having to compute the same expression again. Plus, it
was kindof confusing having both update-flags and flags, which
sometimes had different
On 04/24/2015 11:51 PM, Eric Sunshine wrote:
On Fri, Apr 24, 2015 at 7:35 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
Instead, work directly with update-flags. This has the advantage that
the REF_DELETING bit, set in the first loop, can be read in the third
loop instead of having to
On Fri, Apr 24, 2015 at 01:35:48PM +0200, Michael Haggerty wrote:
Instead, work directly with update-flags. This has the advantage that
the REF_DELETING bit, set in the first loop, can be read in the third
loop instead of having to compute the same expression again. Plus, it
was kindof
On 04/24/2015 07:30 PM, Jeff King wrote:
On Fri, Apr 24, 2015 at 01:35:48PM +0200, Michael Haggerty wrote:
Instead, work directly with update-flags. This has the advantage that
the REF_DELETING bit, set in the first loop, can be read in the third
loop instead of having to compute the same
On Fri, Apr 24, 2015 at 11:15:09PM +0200, Michael Haggerty wrote:
Hmm. I think this is losing the distinction of flags the caller has
passed in to us versus flags we are using locally only during the
transaction_commit routine. If callers look at the flags in the
REF_TRANSACTION_CLOSED
On Fri, Apr 24, 2015 at 7:35 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
Instead, work directly with update-flags. This has the advantage that
the REF_DELETING bit, set in the first loop, can be read in the third
loop instead of having to compute the same expression again. Plus, it
was
6 matches
Mail list logo
