Re: [RFD] Notes are independent: proposal for new notes implementation
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Feb 9, 2010, 20:55 UTC
- Message-ID
- <201002092155.29304.jnareb@gmail.com>
- In-Reply-To
- <32541b131002091226p58b40237j40d3cd6cfaa91df5@mail.gmail.com>
On Tue, 9 Feb 2010, Avery Pennarun wrote:
> 2010/2/9 Jakub Narebski <jnareb@gmail.com>:
Show 10 quoted lines
> > 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
Show 8 quoted lines
> > 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