Re: [PATCHSET] git-reverse-trailer-xrefs: Reverse map cherry-picks and other cross-references
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Dec 13, 2018, 03:01 UTC
- Message-ID
- <xmqqefamgmey.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <20181212145456.GQ2509588@devbig004.ftw2.facebook.com>
Tejun Heo <tj@kernel.org> writes:
Show 15 quoted lines
>> 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?