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

[Tejun Heo <tj@kernel.org>]

Hello, Junio.

On Wed, Dec 12, 2018 at 04:26:57PM +0900, Junio C Hamano wrote:
> It also is not immediately obvious to me what your general strategy
> to maintain this reverse mapping is, when new ways and codepaths to
> cause new commits with "cherry-picked-from" trailer appear.  Do we
> keep piling on new hooks?  Or is the reverse mapping information

So, what I actually wanted was "this repo now has these new commits"
hook, but that didn't seem to be in line with other hooks as most were
bound to specific directly user-visible commands and actions.

> 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 traverseal.
> 
> I also wonder how this topic and the topic Stefan Xenos has been
> working on (cf. <20181201005240.113210-1-sxenos@google.com>) can
> benefit from each other by cross pollination.  Stefan's topic also
> needs to answer, given a commit, what other commits were created out
> of it by cherry-picking and then further amending the results, so
> that when the original commit itself gets amended, the cherry-picked
> ones that were created from the original can be easily identified
> and get updated in the same way as necessary.  

Ah, I see, forward-propagating amends to cherry-picks.

> The motivating workflow your topic's cover letter gives us is to
> maintain the release branch that goes only forward, so in that
> context, how a commit on the release branch that was created by
> cherry-picking an original gets updated when the original commit
> gets amended would be different (I am assuming that you cannot

At least we don't do this with our trees and most trees that I've
worked with don't either as that would make it really confusing for
people to work together.

> affored to rebase the release branch to update a deeply buried
> commit that was an earlier cherry-pick), but I would imagine that
> both topics share the need for a good data structure to keep track
> of (1) the relationship between the original and copy of the
> cherry-pick and (2) the fact that the original of such a cherry-pick
> is now stale and the copy might want to get updated.

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

Thanks.

-- 
tejun