Re: refs/notes/amlog problems, was Re: [PATCH v3 01/20] linear-assignment: a function to solve least-cost assignment problems

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

It turns out that I never had a rewrite hook; the notes.rewriteref mechanism is the only thing that has been used to maintain amlog.

I've stopped populating the reverse mapping, by the way. The script that I feed a message from gmane or public-inbox when I need to learn the set of commits that resulted from the message instead uses "git grep $message-id notes/amlog". And that is fast enough for my purpose.

There is no good reason to abuse the notes mechanism to map a random object-name looking string (i.e. hash result of message id), other than the ease of "quick access" when somebody is making a lot of inquiry, but that "database" does not have to be stored in notes. It certainly does not belong to cycles worth spending by me *while* I work during the say with various history reshaping tools to record and/or update the reverse mapping and that is why my post-applypatch hook no longer has the "reverse map" hack.

It is not like anybody (including me) needs realtime up-to-date reverse mapping from amlog while I run my "commit --amend", "rebase -i", etc. and the reverse map is constructable by reversing the forward map, obviously, with a postprocessing. And I think that is a reasonably way forward if anybody wants to have a reverse mapping. The postprocessing can be done either by me before pushing out the amlog ref, or done by any consumer after fetching the amlog ref from me. If I did the postprocessing and refuse to use rewrite hook you wouldn't even know ;-)