On Sun, Feb 07, 2010 at 12:25:13PM -0800, Junio C Hamano wrote:
> 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.
--
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