On Tue, Feb 09, 2010 at 09:05:23PM +0100, Jakub Narebski wrote: > The proposed solution was to use custom merge strategy for notes. But > what if the answer was to change implementation, decoupling history of > notes from each other, and keeping history of each note separate. If I am understanding you correctly, instead of keeping a commit history of trees of many notes (one per sha1), we will have a tree of commit histories, one history per sha1. What problem is this solving? If I modify commit X and you modify commit Y, we avoid making a merge commit. But so what? The merge would be trivial, since we did not modify the same entries. The user never cares that there is a merge commit. And if we both _did_ edit commit X, both cases result in a merge. If we both modified X and Y, then you will presumably do the merge for X and Y iteratively before you can create a new notes tree. Or you could merge them separately. But why? Why would I want to pull some subset of your notes (and keep in mind this is a subset of the commits you have noted, not a semantically different notes namespace), and how would I even specify which notes were of interest and which were not? So what is the concrete use case where this helps? -Peff -- 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