Re: [PATCHSET] git-reverse-trailer-xrefs: Reverse map cherry-picks and other cross-references

[Junio C Hamano <gitster@pobox.com>]

Tejun Heo <tj@kernel.org> writes:

>> allowed to be a bit stale and be completed immediately before it
>> gets used?  A totally different approach could be to record list of
>> commits, all commits behind which have been scanned for reverse
>> mapping, in the tip of the notes history, perhaps in the commit log
>> message (which is machine generated anyway).  Then, before you need
>> the up-to-date-to-the-last-second reverse mapping, you could run
>> 
>> 	git rev-list --all --not $these_tips_recorded
>
> Wouldn't it be more useful to have repo-updated-with-these-commits
> hook instead rather than putting more logic on note handling?
>
>> and scan the commits, just like you scan what you fetched.  And when
>> you update the reverse mapping notes tree, the commit to record that
>> notes update can record the tip of the above traversal.

I do not consider what you do in notes/xref-* "more logic on note
handling" in the sense that the logic is part of "notes" API.

The moment you decided to reserve one hierarchy in refs/notes/ and
designed what the mapping recorded there means, you designed a new
trailer-xrefs API.  It is a part of that API how blobs stored in
your refs/notes/xref-cherry-picks are formatted and what they mean.
It's the same thing---it is also part of your API how the log
message for recording commits in that hierarchy is formatted and
what it means.

> As long as we can keep the reverse rference notes consistent, wouldn't
> amend propagation just consume them?

Yes.  Would that mean you do not need the notes/xref-* series we are
seeing here, and instead (re)use what Stefan's series, which already
needs to have access to and record the information anyway, records?