Re: A generalization of git notes from blobs to trees - git metadata?

[Jeff King <peff@peff.net>]

On Tue, Feb 09, 2010 at 09:23:12PM -0800, Junio C Hamano wrote:

> > Hmm. OK, I see the point of Jakub's message a bit more now. You want to
> > create a new view, inconsistent with that of either Alice or Bob (that
> > is, you have taken snippets of each's state, but you cannot in good
> > faith represent this as a history merge, because your state should not
> > supersede either of theirs).
> 
> In the message you are quoting, I am not interested in creating a narrowed
> view.  If I cannot resolve conflicts between Alice and Bob in a merge in
> the contents space, I would ask either of them (because they are more
> familiar with the area) to do the merge.  I however was unsure if asking
> the same for merges in the notes space is a reasonable thing to do.

No, I don't see a problem with asking them to do it. If you are all
collaborating as a group, it is something they will need to do
eventually anyway. If they are not, and you are an intermediary, you are
eventually going to share Alice's history with Bob and vice versa. So
you pull from Alice, then say to Bob: "I have some history but I'm not
sure of the correct merge. Pull from me and merge please". The only real
problem is if you _never_ want to share the history between the two of
them. In that case, I think you should keep two parallel branches of
history (refs/notes/alice and refs/notes/bob), and then squash the trees
at run-time (either concatenating them, or favoring one over the other
in the case of conflicts).

-Peff