Re: Transfer notes when rebasing

> On Wed, Sep 04, 2013 at 08:59:41AM +0100, John Keeping wrote:
>
>> On Wed, Sep 04, 2013 at 03:53:10AM -0400, Jeff King wrote:
>> > On Wed, Sep 04, 2013 at 09:51:26AM +0200, Francis Moreau wrote:
>> >
>> > > When rebasing a branch which contains commits with notes onto another
>> > > branch it happens that some commits are already presents in the target
>> > > branch.
>> > >
>> > > In that case git-rebase correctly drops those (already present)
>> > > commits but it also drops the notes associated with them.
>> > >
>> > > Can the notes be transfered somehow in the target branch on the
>> > > already present commits ?
>> >
>> > Yes, see the notes.rewriteRef config option to enable this.
>>
>> Does that actually work for this case?  It sounds like Francis has the
>> notes copying correctly when commits are rewritten but the notes are not
>> copied anywhere if the commit becomes empty.
>
> Ah, I misunderstood. If we are dropping commits from the rebase because
> their counterpart is already applied upstream, then no, there isn't an
> automatic way to do this.
>
> If the commits are dropped because a commit with the same patch-id
> already exists upstream, you could match them up by patch-id and copy
> the notes. Annoyingly, while we have things like "log --cherry-mark" to
> show which commits are already present on each side, I do not think
> there is a way to correlate them commit for commit. So I think you are
> stuck doing something in the shell like:
>
>   patch_ids() {
>     git rev-list "$1" |
>     git diff-tree --stdin -p |
>     git patch-id |
>     sort
>   }
>
>   patch_ids $upstream..HEAD >us
>   patch_ids HEAD..$upstream >them
>
>   join us them |
>   cut -d' ' -f2-3 |
>   git notes copy --stdin
>
> However, if the commit is dropped because we find while applying that it
> becomes empty, there is not much we can do. It may have been obsoleted
> by its counterpart patch that had a different patch-id, or it may even
> have been obsoleted by unrelated patches. In the latter case, there is
> nothing to copy to. In the former, you would have to trying to match up
> the commit messages or similar to guess that the two commits correspond.