Tejun Heo <tj@xxxxxxxxxx> 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?
