On Wed, Sep 4, 2013 at 10:28 AM, Jeff King <peff@xxxxxxxx> wrote:
> 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.
Can't git-rebase at least handle the case where a patch and its
counterpart have the same patch-id ?
Also maybe git-rebase should warn when dropping a commit having a note
to tell the user that the note is dropped too.
--
Francis
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html