Hi Junio, On Mon, 9 Jul 2018, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > Speaking of GitGitGadget: I just encoutered a problem with your > > `refs/notes/amlog` and I hope you can help me with that. > > ... > > When I ask `git notes --ref=refs/notes/gitster-amlog show > > 4cec3986f017d84c8d6a2c4233d2eba4a3ffa60d` (the SHA-1 is the one > > corresponding to `Message-Id: <...>` for that mail), it insists on > > outputting > > > > 5902152ab02291af4454f24a8ccaf2adddefc306 > > It is not uncommon for me to have to do "am" the same patch twice > when attempting to find the right branch/commit to base a change on, But then the `post-applypatch` hook just kicks in twice, leaving the correct mapping in place, no? > so the reverse direction that abuses the notes mechanism to map > message id to resulting commits would be unreliable, especially > given that they may need to further go through "rebase -i" or manual > "cherry-pick <range>" depending on the situation. We already have a mechanism in place that rewrites notes in `rebase -i`'s case. Not so sure about `cherry-pick`, but if it is missing, then that is definitely something we will want to address. In other words, let's not let shortcomings of our own software dictate what we record and what we don't record. This is highly important information that we willfully lose by using the patch contribution process we are going with. And we *can* at least record that information. > I am kind of surprised that the message-to-commit mapping still > records any data that is remotely useful (these days, I only use it > to run "show --notes=amlog" for commit-to-message mapping). Please do understand that this information is the only remotely sane way to work around the limitations of the mailing list-based approach we use here. It costs me a ton of time to figure out these mappings manually, and I think that others simply are not as tenacious as I am and simply drop the ball, which is not good for the project. > I do not think I have anything special when amending the commit, but > amlog notes should be updated in both diretions for its entries to stay > correct across amending, I would think. Indeed. See my other mail about the `post-rewrite` hook I suggest you to install (I did not test this code, of course, but you will probably be able to validate/fix it without much trouble). Ciao, Dscho