Hello, Junio. On Thu, Dec 13, 2018 at 02:47:36PM +0900, Junio C Hamano wrote: > Tejun Heo <tj@xxxxxxxxxx> 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
