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

On Tue, Feb 9, 2010 at 3:55 PM, Jakub Narebski [off-list ref] wrote:

On Tue, 9 Feb 2010, Avery Pennarun wrote:

quoted

2010/2/9 Jakub Narebski [off-list ref]:

quoted

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.

quoted

quoted

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.