On Tue, Feb 9, 2010 at 3:55 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > On Tue, 9 Feb 2010, Avery Pennarun wrote: >> 2010/2/9 Jakub Narebski <jnareb@xxxxxxxxx>: >> > But >> > what if the answer was to change implementation, decoupling history of >> > notes from each other, and keeping history of each note separate. >> >> Congratulations, you've re-invented CVS! :) >> >> Seriously though, I'm not sure what problems this solved. Notes that >> are related to each other can (and perhaps should) be in the same >> notes commit history; notes that are not related to each other can >> exist in separate histories with their own ref. > > The problem is (as I see it) that notes are _not_ (in almost all cases) > related to each other, just like files in $HOME or in /etc are not > related to each other. As a side note, I didn't find this example compelling at all. I *absolutely* want to manage all my files in /etc as a single repo. "The configuration of my computer" is an ongoing project where the configuration of my smtp daemon depends on /etc/hosts and /etc/passwd and /etc/group. If I set up another server, I want to be able to fork my basic configuration and apply some patches. If I set up some clever aliases in /etc/profile, I want to send that patch "upstream" to the /etc project on my other servers. Similarly with $HOME; the evolution of my home directory over time is a thing I can talk about as a sensible whole, and of course I want rename tracking and deltas and so on. Combining /etc and $HOME into a single repo would be harder to justify. But that sounds to me like the "kind (flavor)" distinction you're talking about; system config files and personal files are two different kinds of files. >> > This means for example that if in repository A somebody annotated >> > commits foo and bar creating notes in this order, and in repository B >> > somebody annotated bar and foo (creating notes in reverse order), then >> > merging those changes would require generating merge commit even if >> > those notes are identical. >> >> That's a feature; now you have the true history of your notes, which >> is good for all the same reasons it's good in git. > > No, you are introducing artificial ordering in something that is a bag, > unordered collection. I would put it another way: you're recording the true ordering of something where the ordering *may* not be important. It is easy to ignore that ordering. However, it's very hard to unignore ordering that you didn't record in the first place. That's why CVS's model of recording one-history-per-file is so nasty. Yet it seemed so clever when they invented it. What is a real use case where the "artificial ordering" causes a problem? Here's a use case where having a single history would be a clear benefit: say you're running an autobuilder such as gitbuilder[1]. Something goes wrong with your autobuild environment, like the disk fills up, and all the build results since yesterday at noon are invalid. If the build results are stored as a single history of git notes[2], I can just rewind the history to yesterday at noon and discard the entire sequence of bad results across all commits. If they each had their own history, it would be more complex to implement. Have fun, Avery [1] http://github.com/apenwarr/gitbuilder [2] gitbuilder doesn't currently use git-notes, it just uses plain files. -- 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