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. Separate notes refs for separate histories are not IMHO a good solution: refs namespaces are about *kind* (flavor) of notes: commits annotations, bisect, git-svn, apply-email, bugs / tickets, etc. and each flavor (kind) of notes contain many independent notes. This is opposed to workspace history, where history (in almost all cases) makes sense only of all files, history of a project as a whole. And of course we would have atomic commits, merge tracking, support for renames etc., something like Zit[1] [1]: http://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools#Zit > > 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. > Of course this whole line of reasoning could lead to questions like > "can I rebase my notes history?" and "what about rebase -i" and "can I > maintain a notes patch queue" and so on. -- Jakub Narebski Poland -- 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