Hi Junio, On Fri, 20 Jul 2018, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > AFAICT there is at least one scenario where you run `rebase -i`, the notes > > get updated, and of course the *reverse mapping* does *not* get updated: > > 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. That's just great. I ask you to make my life easier by keeping the information correct, and now you just drop it altogether? Just great. Seriously, I am trying to *improve* something here, because I really do care about contributors, and how hard we make it on them. I would not have expected such a backlash against that. > 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. Awesome. You might want to make sure that Peff stops advertising the amlog notes, then, though. > 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. Right. And it does not have to be stored anywhere, because nobody used it anyway, right? Well, I hate to break it to you: I just found a really excellent use case, and you are making it very, very hard for me. Deliberately so. I don't know how I deserve that. > 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 ;-) The idea that you publish the amlog notes just for your own use cases, sounds a bit strange to me. So to reiterate: the information you have in amlog is useful, if faulty. Rather than "fixing" it by stopping the useful reverse-mapping, it would make a ton more sense to instate that post-rewrite hook I already drafted for you. Besides, while you spent all of that time to make things harder for me, you still did not look into the most worrisome of my findings: there are apparently Message-Id mappings where *none* of the commits returned by said `git grep` you mentioned above are valid. Not a single one. I will dig out the mail for you on Monday, because I care that much, where I provided one example of a Message-Id with two commits that match in amlog, none of which is actually reachable from any of your public branches, and I also provided the commit that *actually* corresponds to that Message-Id, and it is not annotated. So at least in this case *even you* should have a vested interest in figuring out what goes wrong because even your own use case is affected by it. Ciao, Dscho
