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

Jeff King [off-list ref] writes:

Or perhaps you would not even want to do a tree-merge between notes at
all, and would rather see a conflict if two people noted two different
trees.

I've been thinking about the merge issues, and am starting to suspect that
we might want a merge strategy quite drastically different even for blob
cases.  That is one of the reasons why I don't want to see us muddy the
issues by introducing even more complex "tree" case.

Anybody working in the same project can start 'notes' tree with his or her
own root.  That is the normal use case for annotating commits for your own
use.  For merges inside the history of primary contents that people try to
collaborate to advance, three-way merge pivoting on a common ancestor is a
natural way to reach a satisfactory result.  In notes namespace, on the
other hand, the norm is to simply overlay the notes trees, adjusting for
the fan-out.  You annotated that commit I was not interested in, while I
annotated this commit you weren't interested in.  We have our notes in the
end result, and both of us are happy.  If we happen to have annotated the
same commit without knowing what the other was doing, then there is no
sane consolidation---in the most typical case, we would want to keep both,
perhaps concatenating them together.  Textual merge becomes the exception
that triggers two "notes" histories happened to have forked from the same
root somehow.

And for that most typical use case, I suspect even the current "notes on
any and all commits for a single purpose are thrown into a one _bag_ that
is a notes tree, and the growth of that bag is made into a history" model
captures sets of notes that is too wide.

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?

You can end up with conflicts in areas you are not familiar with but Alice
and Bob are in charge of even in the primary content space, but there is a
fundamental difference of this type of conflict in the notes space, I
think.  The set of contents in the primary content space are supposed to
make a consistent whole, and there is a topic branch workflow to partition
the work to allow me to easily kick the merge back to them (i.e. I can
tell Alice and Bob to resolve the conflicts between themselves and trust
that what they do between them do not touch outside of their area) without
getting blocked.  I don't see a clear workflow to resolve this in the
notes space, especially with the set of operations the current "git notes"
(and obvious and straightforward enhancements of what it does).  At least
not yet.

It's like "keeping track of /etc" (or "your home directory").  It is a
misguided thing to do because you are throwing in records of the states of
totally unrelated things into a single history (e.g. "Why does it matter I
added new user frotz to /etc/passwd before I futzed with my sendmail
configuration?  ---It shouldn't matter; there shouldn't be ancestry
relationships between these two changes").  I somehow feel that keeping
track of the "growth of the bag of annotations to any and all commits" in
a single history may be making the same mistake.

Junio C Hamano [off-list ref] writes:

It's like "keeping track of /etc" (or "your home directory").  It is a
misguided thing to do because you are throwing in records of the
states of totally unrelated things into a single history.

I've recently tried doing this again with Git, so this comment piqued my
interest. (That is, tracking changes to my various configuration files.)
I agree that browsing the history in toto is jarring, though the history
of a particular file may be telling.

Is there an alternative you'd recommend?

-- 
Steven E. Harris

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.