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

From: Jeff King <peff@peff.net>
Date: Feb 10, 2010, 05:09 UTC
Message-ID: <20100210050902.GD28526@coredump.intra.peff.net>
In-Reply-To: <7v8wb4aj4m.fsf@alter.siamese.dyndns.org>

On Sun, Feb 07, 2010 at 12:25:13PM -0800, Junio C Hamano wrote:

Show 9 quoted lines

> Suppose Alice, Bob and I are involved in a project, and we annotate
> commits for some shared purpose (say, tracking regressions).  Alice and
> Bob may independently annotate overlapping set of commits (and hopefully
> they have shared root for their notes history as they are collaborating),
> and they may even be working together on the same issue, but I may not be
> involved in the area.  What happens when I pull from Alice and Bob and get
> conflicts in notes they produced, especially the only reason I was
> interested was because they have new things to say about commits that I am
> interested in?

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

The standard way to do such a thing in git is to create a new, alternate history through cherry-picking or rebasing. So I suspect we could do something like:

  1. git notes pull alice

     We fast-forward (or do the trivial merge) with Alice's work.

  2. git notes pull --ignore-conflicts bob

     We try to merge Bob's work and see that there are conflicts. So we
     iterate through refs/notes..bob/notes, cherry-picking each one that
     applies cleanly and ignoring the rest.

And then you're at a state inconsistent with Bob, and a superset of what Alice has. And that's what your history represents, too: you've branched but done some of the same things as Bob. At that point you can examine your inconsistent state, and then when you're done, you can either:

  3a. Reset back to your pre-ignore-conflicts state.

  3b. Leave it. When you pull from Bob later, your shared changes will
      be ignored[1], and you will get the conflicts that you ignored
      earlier.

It is perhaps a hacky band-aid to handle notes this way, but it is the "most git" way of doing it. That is, it uses our standard tools and practices. And when all you have is a hammer... :) And I really expect the "I am collaborating with these people, but I want an inconsistent view of their history" to be the exception. Most people would _want_ to resolve the conflicts (especially if there is a --cat-conflicts option to do it automatically) in a collaboration scenario.

-Peff

[1] Actually because history has diverged, you have the usual cherry pick problems with merging later. If some note is at state A, then I cherry-pick Bob's change to B, then Bob changes it to C and I try to merge with him, from the 3-way merge's perspective we have a conflict, because nothing in the history says that Bob's change to C meant to supersede my cherry-picked version of his history.