Message-ID: <20160731143539.GA15477@salo>
Date:	Sun, 31 Jul 2016 15:35:39 +0100
From:	Richard Ipsum <richard.ipsum@...ethink.co.uk>
To:	Josh Triplett <josh@...htriplett.org>
Cc:	git@...r.kernel.org, linux-kernel@...r.kernel.org,
	dborowitz@...gle.com
Subject: Re: [ANNOUNCE] git-series: track changes to a patch series over time

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:
> > On Fri, Jul 29, 2016 at 04:04:26AM -0700, Josh Triplett wrote:
> > > 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 <richardipsum@...tmail.co.uk>
Date:   Sun Jul 24 16:59:16 2016 +0100

    Metadata update
    
    Patch-set: 1
    Status: merged

commit f45a396a156e121f923321e7530e74746e10bdb8
Author: Richard Ipsum <richardipsum@...tmail.co.uk>
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 <richardipsum@...tmail.co.uk>
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

Powered by blists - more mailing lists