Jeff King <peff@xxxxxxxx> 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. -- 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