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

From: Jeff King <peff@peff.net>
Date: Feb 10, 2010, 05:29 UTC
Message-ID: <20100210052902.GA28832@coredump.intra.peff.net>
In-Reply-To: <7vvde5irzz.fsf@alter.siamese.dyndns.org>

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

Show 11 quoted lines

> > 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