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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux