On Fri, Jul 29, 2016 at 06:00:55AM -0700, Josh Triplett wrote:

On Fri, Jul 29, 2016 at 01:44:44PM +0100, Richard Ipsum wrote:

quoted

On Fri, Jul 29, 2016 at 04:04:26AM -0700, Josh Triplett wrote:

quoted

I hope to use git notes with git-series in the future, by putting
another gitlink under the git-series for notes related to the series.
I'd intended that for more persistent notes; putting them in the series
solves some of the problems related to notes refs, pushing/pulling, and
collaboration.  Using notes for review comments makes sense as well,
whether in a series or in a separate ref.

Sounds interesting, can you explain how this works in more detail?

The tree within a git-series commit includes a blob "cover" for the
cover letter, a gitlink "base" for the base commit, and a gitlink
"series" for the top of the series.  I could add a gitlink "notes",
which acts like a notes ref; then, each version of the series would have
its own notes ref.  As with the series, git-series would track the
"history of history"; since git-notes themselves use git history to
store a set of notes, git-series would store the history of the notes.
So if you add, remove, or change a note, git-series would track that as
a change to the notes ref.  If you merge/rebase/etc the notes ref to
merge notes, git-series would track that too.  A different series would
have a different set of notes, so you wouldn't be limited to
one notes ref per repository.

This doesn't solve the problem of merging notes, but it *does* mean you
have a full history of the changes to notes, not just the notes
themselves.

Something similar might work for the Gerrit notesdb.

Okay I think there is a misunderstanding, Notedb is based on notes,
but they're not used in the same way as git-notes,
an example will help explain what I mean,

For a candidate 'update_readme' we store the change/candidate/whatever
metadata at refs/candidates/heads/up/update_readme/meta which is analogous
to Gerrit's notedb refs which uses something like refs/changes/34/1234/meta,
the prototype library I've written supports both forms and allows for some
flexibility in the naming of the prefix of the former type of ref
(so you may use refs/series/heads/up/update_readme/meta for example).

So the output of,
    git log -p refs/candidates/heads/up/update_readme/meta

gives

commit 38d0c182a46dc5a0f5d04ea0890e278b8e7a6eb6
Author: Richard Ipsum [off-list ref]
Date:   Sun Jul 24 16:59:16 2016 +0100

    Metadata update
    
    Patch-set: 1
    Status: merged

commit f45a396a156e121f923321e7530e74746e10bdb8
Author: Richard Ipsum [off-list ref]
Date:   Sun Jul 24 16:50:13 2016 +0100

    Vote on patch set 1
    
    
    
    Label: CodeReview=+1
    Patch-set: 1

commit b74eb15c1847d3bb28618c738c8ebc3412b6935a
Author: Richard Ipsum [off-list ref]
Date:   Sun Jul 24 16:48:11 2016 +0100

    Update our README to reflect reality
    BranchCommit; 59c46c9fa03725308779841f95ad71e7ccdb919c
    
    Branch: master
    Commit: 761d8da03a10b63b0b1e3cf97ffd7ececb09e3d6
    Patch-set: 1
    Status: new
    Subject: update_readme

This Notedb history is the result of the following git-candidate invocations

    git candidate create update_readme -m "Update our README to reflect reality"
    git candidate vote +1
    (use whatever git commands you like to merge the change)
    git candidate close update_readme

Basically any change made to a change in Notedb is recorded in a git history.

The format is explained in some more detail here[1].

[1]: https://storage.googleapis.com/gerrit-talks/summit/2015/NoteDB.pdf