lkml.org 
[lkml]   [2016]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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@fastmail.co.uk>
Date: Sun Jul 24 16:59:16 2016 +0100

Metadata update

Patch-set: 1
Status: merged

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

\
 
 \ /
  Last update: 2016-07-31 17:21    [W:0.070 / U:0.964 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site