Re: Using Origin hashes to improve rebase behavior

> OK. That's certainly the conservative answer, and where we should start.
> But I wonder in practice how many times we'll hit all the criteria just
> right for this feature to kick in (i.e., a cherry pick or rebase with no
> conflicts, followed by one that would cause a conflict). But I think
> there's nothing to do but implement and see how it works.
>
> After thinking about this a bit more, the whole idea of "is this
> cherry-picked/rebased/whatever commit the same as the one before" is
> really the same as the notes-rewriting case (i.e., copying notes on
> commit A when it is rebased into A'). Which makes me excited about using
> notes for this, because the rules that you do figure out to work in
> practice will be good rules for notes rewriting in general.
>
>> The problem with an external annotation is that if developers are sharing
>> feature branches, as a branch maintainer I want to know whether commits coming
>> from those feature branches are already in the branch I'm maintaining.
>
> In that case, I would suggest putting it in git-notes and sharing the
> notes with each other. The notes code should happily merge them all
> together, and then everyone gets to see everybody else's
> cherry-pick/rebase annotations.