From: Jeff King <peff@peff.net>
Date: Wed, 10 Feb 2010 04:51:50 GMT
Subject: Re: [RFD] Notes are independent: proposal for new notes implementation
Message-ID: <20100210045150.GB28526@coredump.intra.peff.net>
In-Reply-To: <201002092105.25636.jnareb@gmail.com>

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