git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).