git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFD] Notes are independent: proposal for new notes implementation

From
Jeff King <peff@peff.net>
Date
Feb 10, 2010, 04:51 UTC
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
Previous: Avery Pennarun
Message 5 of 5 in “[RFD] Notes are independent: proposal for new notes implementation”
  1. Jakub NarebskiFeb 9, 2010
  2. Avery PennarunFeb 9, 2010
  3. Jakub NarebskiFeb 9, 2010
  4. Avery PennarunFeb 9, 2010
  5. Jeff KingFeb 10, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.