Re: [PATCHSET] git-reverse-trailer-xrefs: Reverse map cherry-picks and other cross-references

[Tejun Heo <tj@kernel.org>]

Hello, Junio.

On Thu, Dec 13, 2018 at 02:47:36PM +0900, Junio C Hamano wrote:
> Tejun Heo <tj@kernel.org> writes:
> 
> > Hmmm... I see.  I still have a bit of trouble seeing why doing it that
> > way is better tho.  Wouldn't new-object-hook be simpler?  They'll
> > achieve about the same thing but one would need to keep the states in
> > two places.
> 
> The new-object-hook thing will not have keep the states.  Whenever
> Git realizes that it created a new object, it must call that hook,
> and at that point in time, without keeping any state, it knows which
> objects are what it has just created.  So "in two places" is not a

Yeap, that's what I was trying to say.

> problem at all.  There is only one place (i.e. the place the sweeper
> would record what it just did to communicate with its future
> invocation).
> 
> A new-object-hook that will always be called any time a new object
> enters the picture would be a nightmare to maintain up-to-date.  One

But I didn't know this.  I probably am too naive in thinking so but
it's a bit surprising that there's no single / few chokepoints for
repo updates that we can attach to.

> missed codepath and your coverage will have holes.  Having a back-up
> mechanism to sweep for new objects will give you a better chance of
> staying correct as the system evolves, I'd think.

The duplicate state tracking still bothers me a bit (duplicate in the
sense that the end results are the same) especially as this would mean
any similar mechanism would need to track their own states too, but I
really don't have the full (not even close) picture here and it can
easily be me missing something.

Anyways, I'll wait for Stefan to chime in.

Thanks.

-- 
tejun