From: Jakub Narebski <jnareb@gmail.com>
To: Avery Pennarun <apenwarr@gmail.com>
Cc: git@vger.kernel.org, Johan Herland <johan@herland.net>,
Junio C Hamano <gitster@pobox.com>,
Jon Seymour <jon.seymour@gmail.com>
Subject: Re: [RFD] Notes are independent: proposal for new notes implementation
Date: Tue, 9 Feb 2010 21:55:28 +0100 [thread overview]
Message-ID: <201002092155.29304.jnareb@gmail.com> (raw)
In-Reply-To: <32541b131002091226p58b40237j40d3cd6cfaa91df5@mail.gmail.com>
On Tue, 9 Feb 2010, Avery Pennarun wrote:
> 2010/2/9 Jakub Narebski <jnareb@gmail.com>:
> > 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
next prev parent reply other threads:[~2010-02-09 20:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-09 20:05 [RFD] Notes are independent: proposal for new notes implementation Jakub Narebski
2010-02-09 20:26 ` Avery Pennarun
2010-02-09 20:55 ` Jakub Narebski [this message]
2010-02-09 21:37 ` Avery Pennarun
2010-02-10 4:51 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201002092155.29304.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=apenwarr@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johan@herland.net \
--cc=jon.seymour@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).