[ANNOUNCE] git-series: track changes to a patch series over time

[ANNOUNCE] git-series: track changes to a patch series over time

[Josh Triplett]

I'd like to announce a project I've been working on for a while:

git-series provides a tool for managing patch series with git, tracking
the "history of history". git series tracks changes to the patch series
over time, including rebases and other non-fast-forwarding changes. git
series also tracks a cover letter for the patch series, formats the
series for email, and prepares pull requests.

This makes it easier to collaborate on a patch series, distribution
package, backport, or any other development process that includes
rebasing or non-fast-forward development.

A patch series typically goes through multiple iterations before
submission; the path from idea to RFC to [PATCHv12 1/8] includes many
invocations of git rebase -i. However, while Git tracks and organizes
commits quite well, it doesn't actually track changes to a patch series
at all, outside of the ephemeral reflog. This makes it a challenge to
collaborate on a patch series, distribution package, backport, or any
other development process that includes rebasing or non-fast-forward
development.

Typically, tracking the evolution of a patch series over time involves
moving part of the version control outside of git. You can move the
patch series from git into quilt or a distribution package, and then
version the patch files with git, losing the power of git's tools. Or,
you can keep the patch series in git, and version it via multiple named
branches; however, names like feature-v2, feature-v3-typofix, and
feature-v8-rebased-4.6-alice-fix sound like filenames from corporate
email, not modern version control. And either way, git doesn't track
your cover letter at all.

git-series tracks both a patch series and its evolution within the same
git repository. git-series works entirely with existing git features,
allowing git to push and pull a series to any git repository along with
other branches and tags. Each time you change the patch series, whether
fast-forwarding or not, you can "git series commit" a new version of the
patch series, complete with commit message.

You can rebase a patch series with "git series rebase -i", format it for
submission with "git series format", or send a "please pull" request with
"git series req".  git-series knows the base of your series, so you
don't need to count patches or find a commit hash to run rebase or
format.

If you're interested in trying git-series, see
https://github.com/git-series/git-series for installation instructions
and a "getting started" guide.

I've also documented the internal storage format of git-series at
https://github.com/git-series/git-series/blob/master/INTERNALS.md ,
including the details for how git-series ensures git can always reach,
push, and pull a series.

I'd welcome any feedback, whether on the interface and workflow, the
internals and collaboration, ideas on presenting diffs of patch series,
or anything else.

- Josh Triplett

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Richard Ipsum]

On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
[snip]
> 
> I'd welcome any feedback, whether on the interface and workflow, the
> internals and collaboration, ideas on presenting diffs of patch series,
> or anything else.
> 

This looks awesome!

I've been working on some similar stuff for a while also.[1][2]

I'm particularly interested in trying to establish a standard for
storing review data in git. I've got a prototype for doing that[3],
and an example tool that uses it[4]. The tool is still incomplete/buggy though.

There seem to be a number of us trying to solve this in our different ways,
it would be great to coordinate our efforts.

The prototype library I have is partly the result of some discussion and work
with the Gerrit folks, since they were thinking about this problem
before I even started writing git-candidate, and solved it with Notedb.[5]

Let me know if you'd like to work together on this,
I've been considering taking the perl-notedb prototype and writing
a C library for it with bindings for other languages (i.e. Rust).

[1]: http://www.mail-archive.com/git%40vger.kernel.org/msg79461.html
[2]: http://www.mail-archive.com/git%40vger.kernel.org/msg80972.html

[3]: https://bitbucket.org/richardipsum/perl-notedb
[4]: https://bitbucket.org/richardipsum/git-candidate

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

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Josh Triplett]

On Fri, Jul 29, 2016 at 11:10:11AM +0100, Richard Ipsum wrote:
> On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
> [snip]
> > 
> > I'd welcome any feedback, whether on the interface and workflow, the
> > internals and collaboration, ideas on presenting diffs of patch series,
> > or anything else.
> > 
> 
> This looks awesome!
> 
> I've been working on some similar stuff for a while also.[1][2]
> 
> I'm particularly interested in trying to establish a standard for
> storing review data in git. I've got a prototype for doing that[3],
> and an example tool that uses it[4]. The tool is still incomplete/buggy though.

Looks promising, though!

> There seem to be a number of us trying to solve this in our different ways,
> it would be great to coordinate our efforts.

These definitely seem like a family of related problems.  I'd like to
use git-series as a format for storing iterations on things like GitHub
pull-requests or Gerrit patch versions (in the latter case, overcoming
Gerrit's limitations on only handling one patch at a time).  Integrating
reviews with that seems helpful.

> The prototype library I have is partly the result of some discussion and work
> with the Gerrit folks, since they were thinking about this problem
> before I even started writing git-candidate, and solved it with Notedb.[5]
> 
> Let me know if you'd like to work together on this,

I'd love to.

I'll be presenting git-series at LinuxCon North America; will you be
there by any chance?  If not, perhaps we could meet by IRC or some other
medium and talk about this family of problems.

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.

> I've been considering taking the perl-notedb prototype and writing
> a C library for it with bindings for other languages (i.e. Rust).

A C library based on libgit2 seems like a good idea; ideally the
bindings could interoperate with git2-rs.  (Alternatively, Rust can
*export* a C interface, so you could write directly with git2-rs. :) )

One of the items on my long-term TODO list is a completely federated
GitHub; I've been looking at other aspects of that, but federated
reviews/comments/etc seem critical to that as well.

- Josh Triplett

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Richard Ipsum]

On Fri, Jul 29, 2016 at 04:04:26AM -0700, Josh Triplett wrote:
[snip]
> 
> These definitely seem like a family of related problems.  I'd like to
> use git-series as a format for storing iterations on things like GitHub
> pull-requests or Gerrit patch versions (in the latter case, overcoming
> Gerrit's limitations on only handling one patch at a time).  Integrating
> reviews with that seems helpful.

Worth noting here that Gerrit's one patch per change format isn't
intrinsic to Notedb, since we just need to track the sha we want
to merge and optionally the branch we intend to merge into.

> 
> > The prototype library I have is partly the result of some discussion and work
> > with the Gerrit folks, since they were thinking about this problem
> > before I even started writing git-candidate, and solved it with Notedb.[5]
> > 
> > Let me know if you'd like to work together on this,
> 
> I'd love to.
> 
> I'll be presenting git-series at LinuxCon North America; will you be
> there by any chance?  If not, perhaps we could meet by IRC or some other
> medium and talk about this family of problems.

Cool :)

I didn't plan to be at LinuxCon North America,
but I can certainly send contact details out of band.

> 
> 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?
I ended up solving the push/pull issue with a custom merge driver
that effectively runs the Notedb parser on each side of the merge
and emits the union of the two sets of change notes.

> 
> > I've been considering taking the perl-notedb prototype and writing
> > a C library for it with bindings for other languages (i.e. Rust).
> 
> A C library based on libgit2 seems like a good idea; ideally the
> bindings could interoperate with git2-rs.  (Alternatively, Rust can
> *export* a C interface, so you could write directly with git2-rs. :) )

Certainly a fair alternative, though it may arguably be safer to write
the C and export to other languages, as cool as Rust looks it's not
established the way C is, so may be a slightly riskier foundation,
in my view.

And ofcourse in C we have native access to libgit2.

> 
> One of the items on my long-term TODO list is a completely federated
> GitHub; I've been looking at other aspects of that, but federated
> reviews/comments/etc seem critical to that as well.
> 

I agree.

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Josh Triplett]

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.

> > > I've been considering taking the perl-notedb prototype and writing
> > > a C library for it with bindings for other languages (i.e. Rust).
> > 
> > A C library based on libgit2 seems like a good idea; ideally the
> > bindings could interoperate with git2-rs.  (Alternatively, Rust can
> > *export* a C interface, so you could write directly with git2-rs. :) )
> 
> Certainly a fair alternative, though it may arguably be safer to write
> the C and export to other languages, as cool as Rust looks it's not
> established the way C is, so may be a slightly riskier foundation,
> in my view.

I was mostly joking there.  Rust makes that potentially reasonable,
unlike most languages that can consume but not easily provide a C API,
but that doesn't make it the ideal solution quite yet. :)

> And ofcourse in C we have native access to libgit2.

Right.

> > One of the items on my long-term TODO list is a completely federated
> > GitHub; I've been looking at other aspects of that, but federated
> > reviews/comments/etc seem critical to that as well.
>
> I agree.

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Stefan Beller]

On Fri, Jul 29, 2016 at 5:44 AM, Richard Ipsum
<richard.ipsum@codethink.co.uk> wrote:
>>
>> These definitely seem like a family of related problems.  I'd like to
>> use git-series as a format for storing iterations on things like GitHub
>> pull-requests or Gerrit patch versions (in the latter case, overcoming
>> Gerrit's limitations on only handling one patch at a time).  Integrating
>> reviews with that seems helpful.
>
> Worth noting here that Gerrit's one patch per change format isn't
> intrinsic to Notedb, since we just need to track the sha we want
> to merge and optionally the branch we intend to merge into.

Note that Gerrit started to lose the "one patch at a time" notion.
It is possible to at least submit multiple changes coupled together
(even across project boundaries) via the topic. Some sort of cover
letter is missing though, that could be used e.g. for the merge commit.

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Richard Ipsum]

On Fri, Jul 29, 2016 at 09:59:08AM -0700, Stefan Beller wrote:
> On Fri, Jul 29, 2016 at 5:44 AM, Richard Ipsum
> <richard.ipsum@codethink.co.uk> wrote:
> >>
> >> These definitely seem like a family of related problems.  I'd like to
> >> use git-series as a format for storing iterations on things like GitHub
> >> pull-requests or Gerrit patch versions (in the latter case, overcoming
> >> Gerrit's limitations on only handling one patch at a time).  Integrating
> >> reviews with that seems helpful.
> >
> > Worth noting here that Gerrit's one patch per change format isn't
> > intrinsic to Notedb, since we just need to track the sha we want
> > to merge and optionally the branch we intend to merge into.
> 
> Note that Gerrit started to lose the "one patch at a time" notion.
> It is possible to at least submit multiple changes coupled together
> (even across project boundaries) via the topic. Some sort of cover
> letter is missing though, that could be used e.g. for the merge commit.

Potentially my misuse of the format but git-candidate puts the cover
letter into the body of the commit message before the footers begin,
for each new patchset added to the change. This has the advantage
that you can track each version of the cover letter,
since there's one per patchset.

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Richard Ipsum]

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

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Christian Couder]

On Fri, Jul 29, 2016 at 12:10 PM, Richard Ipsum
<richard.ipsum@codethink.co.uk> wrote:
> On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
> [snip]
>>
>> I'd welcome any feedback, whether on the interface and workflow, the
>> internals and collaboration, ideas on presenting diffs of patch series,
>> or anything else.
>
> This looks awesome!
>
> I've been working on some similar stuff for a while also.[1][2]
>
> I'm particularly interested in trying to establish a standard for
> storing review data in git. I've got a prototype for doing that[3],
> and an example tool that uses it[4]. The tool is still incomplete/buggy though.

There is also git-appraise (https://github.com/google/git-appraise)
written in Go to store code review data in Git.
It looks like it stores its data in git notes and can be integrated
with Rust (https://github.com/Nemo157/git-appraise-rs).

> There seem to be a number of us trying to solve this in our different ways,
> it would be great to coordinate our efforts.

Yeah, I agree.

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Eric Wong]

Christian Couder <christian.couder@gmail.com> wrote:
> On Fri, Jul 29, 2016 at 12:10 PM, Richard Ipsum
> <richard.ipsum@codethink.co.uk> wrote:
> > On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
> > [snip]
> >>
> >> I'd welcome any feedback, whether on the interface and workflow, the
> >> internals and collaboration, ideas on presenting diffs of patch series,
> >> or anything else.

> > I'm particularly interested in trying to establish a standard for
> > storing review data in git. I've got a prototype for doing that[3],
> > and an example tool that uses it[4]. The tool is still incomplete/buggy though.
> 
> There is also git-appraise (https://github.com/google/git-appraise)
> written in Go to store code review data in Git.
> It looks like it stores its data in git notes and can be integrated
> with Rust (https://github.com/Nemo157/git-appraise-rs).

I'm not convinced another format/standard is needed besides the
email workflow we already use for git and kernel development.

Rather, better ways to archive/search the emails is desirable.
Fortunately, commit titles are rather unique :)

I started archiving the git ML with public-inbox (which uses git):

  https://public-inbox.org/git/20160710004813.GA20210@dcvr.yhbt.net/T/

It can be easy to search by Subject (commit titles):

  https://public-inbox.org/git/?q=s:%22more+archives+of+this+list%22

Search (currently Xapian) will be tuned to parse things like
filenames and diffs to allow searching within those.  It is
already somewhat email-aware, such as deprioritizing quoted
text; and having a code repository browser with mail archive
integration is in the works.

I also see the reliance on an after-the-fact search engine
(which can be tuned/replaced) as philosophically inline with
what git does, too, such as not having rename tracking and
doing delayed deltafication.

Email also has the advantage of having existing tooling, and
being (at least for now) federated without a single point of
failure.

vger.kernel.org can still be a major point of failure, which is
why the "archives first" approach of public-inbox favors readers
pulling messages over NNTP/HTTP/git (and maybe soon, POP3).

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Josh Triplett]

On Mon, Aug 01, 2016 at 07:55:54AM +0000, Eric Wong wrote:
> Christian Couder <christian.couder@gmail.com> wrote:
> > On Fri, Jul 29, 2016 at 12:10 PM, Richard Ipsum
> > <richard.ipsum@codethink.co.uk> wrote:
> > > On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
> > > [snip]
> > >>
> > >> I'd welcome any feedback, whether on the interface and workflow, the
> > >> internals and collaboration, ideas on presenting diffs of patch series,
> > >> or anything else.
> 
> > > I'm particularly interested in trying to establish a standard for
> > > storing review data in git. I've got a prototype for doing that[3],
> > > and an example tool that uses it[4]. The tool is still incomplete/buggy though.
> > 
> > There is also git-appraise (https://github.com/google/git-appraise)
> > written in Go to store code review data in Git.
> > It looks like it stores its data in git notes and can be integrated
> > with Rust (https://github.com/Nemo157/git-appraise-rs).
> 
> I'm not convinced another format/standard is needed besides the
> email workflow we already use for git and kernel development.

Not all projects use a patches-by-email workflow, or want to.  To the
extent that tools and projects use some other workflow, standardizing
the format they use to store patch reviews (including per-line
annotations, approvals, test results, etc) seems preferable to having
each tool use its own custom format.

> I also see the reliance on an after-the-fact search engine
> (which can be tuned/replaced) as philosophically inline with
> what git does, too, such as not having rename tracking and
> doing delayed deltafication.

Storing review data in git doesn't mean it needs to end up in the
history of the project itself; it can use after-the-fact annotations on
a commit.

> Email also has the advantage of having existing tooling, and
> being (at least for now) federated without a single point of
> failure.

Storing review data in git makes it easy to push and pull it, which can
provide the basis for a federated system.

- Josh Triplett

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Richard Ipsum]

On Mon, Aug 01, 2016 at 01:59:29AM -0700, Josh Triplett wrote:
> On Mon, Aug 01, 2016 at 07:55:54AM +0000, Eric Wong wrote:
[snip]
> > 
> > I'm not convinced another format/standard is needed besides the
> > email workflow we already use for git and kernel development.
> 
> Not all projects use a patches-by-email workflow, or want to.  To the
> extent that tools and projects use some other workflow, standardizing
> the format they use to store patch reviews (including per-line
> annotations, approvals, test results, etc) seems preferable to having
> each tool use its own custom format.

I concur, for better or for worse many projects have abandoned
mailing lists in favour of github, gerrit, gitlab and the like.
The problem being, with the exception of gerrit, most of these
tools store review data in sql databases, which is bad for obvious reasons.

> 
> > I also see the reliance on an after-the-fact search engine
> > (which can be tuned/replaced) as philosophically inline with
> > what git does, too, such as not having rename tracking and
> > doing delayed deltafication.
> 
> Storing review data in git doesn't mean it needs to end up in the
> history of the project itself; it can use after-the-fact annotations on
> a commit.

Exactly.

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Stephen Warren]

On 07/29/2016 12:40 AM, Josh Triplett wrote:
> I'd like to announce a project I've been working on for a while:
>
> git-series provides a tool for managing patch series with git, tracking
> the "history of history". git series tracks changes to the patch series
> over time, including rebases and other non-fast-forwarding changes. git
> series also tracks a cover letter for the patch series, formats the
> series for email, and prepares pull requests.

Just as an FYI, I wouldn't be surprised if there's some overlap, or 
potential for merging of tools, between this tool and the "patman" tool 
that's part of the U-Boot source tree:

http://git.denx.de/?p=u-boot.git;a=blob;f=tools/patman/README;h=e36857dedea1d0dbafa41732aaf9bf0988d63f38;hb=HEAD

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Josh Triplett]

On Mon, Aug 01, 2016 at 09:14:54AM -0600, Stephen Warren wrote:
> On 07/29/2016 12:40 AM, Josh Triplett wrote:
> > I'd like to announce a project I've been working on for a while:
> > 
> > git-series provides a tool for managing patch series with git, tracking
> > the "history of history". git series tracks changes to the patch series
> > over time, including rebases and other non-fast-forwarding changes. git
> > series also tracks a cover letter for the patch series, formats the
> > series for email, and prepares pull requests.
> 
> Just as an FYI, I wouldn't be surprised if there's some overlap, or
> potential for merging of tools, between this tool and the "patman" tool
> that's part of the U-Boot source tree:
> 
> http://git.denx.de/?p=u-boot.git;a=blob;f=tools/patman/README;h=e36857dedea1d0dbafa41732aaf9bf0988d63f38;hb=HEAD

Interesting tool; thanks for the link.

As far as I can tell from that documentation, patman doesn't track old
versions of a patch series; you rebase to modify patches or change
patman tags (embedded in commit messages), and nothing preserves the
previous version.  And it tracks the cover letter and similar in one of
the commit messages in the series, so previous versions of that don't
get saved either.  If you wanted to track the history of your changes,
you'd have to use branch names or similar.

In addition, tracking metadata in commit messages only works with a
patches-by-mail workflow where the messages get processed when
generating patches; that doesn't work for please-pull workflows.

patman does have quite a few interesting ideas, though.  git-series
needs some way of handling To/Cc addresses for patches and the cover
letter (beyond just scripts/get_maintainer.pl), and more automatic
handling of series versioning (v2, v3, ...) and associated series
changelogs.  Suggestions welcome.

- Josh Triplett

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Eric Wong]

Josh Triplett <josh@joshtriplett.org> wrote:
> On Mon, Aug 01, 2016 at 07:55:54AM +0000, Eric Wong wrote:
> > Christian Couder <christian.couder@gmail.com> wrote:
> > > On Fri, Jul 29, 2016 at 12:10 PM, Richard Ipsum
> > > <richard.ipsum@codethink.co.uk> wrote:
> > > > On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
> > > > [snip]
> > > >>
> > > >> I'd welcome any feedback, whether on the interface and workflow, the
> > > >> internals and collaboration, ideas on presenting diffs of patch series,
> > > >> or anything else.
> > 
> > > > I'm particularly interested in trying to establish a standard for
> > > > storing review data in git. I've got a prototype for doing that[3],
> > > > and an example tool that uses it[4]. The tool is still incomplete/buggy though.

> > I'm not convinced another format/standard is needed besides the
> > email workflow we already use for git and kernel development.
> 
> Not all projects use a patches-by-email workflow, or want to.  To the
> extent that tools and projects use some other workflow, standardizing
> the format they use to store patch reviews (including per-line
> annotations, approvals, test results, etc) seems preferable to having
> each tool use its own custom format.

I think standardizing on email conventions (such as what we
already do with format-patch, request-pull, S-o-b trailers) would
be a step in this direction and a good step to take.

But yeah, I also hope git adopters can somehow be convinced to
also adopt the workflow that built git itself.

> > I also see the reliance on an after-the-fact search engine
> > (which can be tuned/replaced) as philosophically inline with
> > what git does, too, such as not having rename tracking and
> > doing delayed deltafication.
> 
> Storing review data in git doesn't mean it needs to end up in the
> history of the project itself; it can use after-the-fact annotations on
> a commit.

Right.  So on public-inbox.org/git today, one could search for
after-the-fact annotations based on commit titles and maybe
exact commit ID matches.

A future goal might be to get search indexing working on commit
ID substrings.  So finding references to commit
deadbeefcafe01234567890123467890abcdef00 could be done by
searching for "commit deadbeefcafe" or even a shorter ID, and
the following results could still be returned:

  1. commit deadbeefcafe broke my cat feeder
  2. commit deadbeef killed my cow

> > Email also has the advantage of having existing tooling, and
> > being (at least for now) federated without a single point of
> > failure.
> 
> Storing review data in git makes it easy to push and pull it, which can
> provide the basis for a federated system.

Every public-inbox exposed over HTTP(S) is git clonable[1], so
it's possible to push/pull or have developers merge/combine
inboxes with index-only operations.  There's no UI for that,
yet, and having a working tree checked out is inefficient with
300K uncompressed mails...

But there needs to be way to message others about the existence
of new pushes/pull-requests/reviews/etc; including users
unable to clone or host 800M git repos; so that messaging
system might as well be email.



[1] git clone --mirror https://public-inbox.org/git/
    That's not efficient, yet, though, at around 800M when the
    gzipped fast-export dump is around half that:
    https://public-inbox.org/git/20160710034745.GA20270@dcvr.yhbt.net/T/#u

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Richard Ipsum]

On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
> 
> I'd welcome any feedback, whether on the interface and workflow, the
> internals and collaboration, ideas on presenting diffs of patch series,
> or anything else.
> 

One other nice thing I've noticed about this tool is the
way series behave like regular git branches: I specify the name
of the series and from then on all other commands act on that
series until told otherwise.

git-appraise looks as though it might also have this behaviour.
I think it's a nice way to do it, since you don't generally
perform more than one review simultaneously. So I may well
use this idea in git-candidate if it's okay. :)

I haven't found time to use the tool to do any serious review
yet, but I'll try and post some more feedback when I do.

Hope this helps,
Richard

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Josh Triplett]

On Wed, Aug 03, 2016 at 08:12:02PM +0100, Richard Ipsum wrote:
> On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
> > I'd welcome any feedback, whether on the interface and workflow, the
> > internals and collaboration, ideas on presenting diffs of patch series,
> > or anything else.
> 
> One other nice thing I've noticed about this tool is the
> way series behave like regular git branches: I specify the name
> of the series and from then on all other commands act on that
> series until told otherwise.

Thanks; I spent a while thinking about that part of the workflow.  I
save the current series as a symbolic ref SHEAD, and everything operates
on SHEAD.  (I should probably add support for running things like "git
series log" or "git series format" on a different series, because right
now "until told otherwise" doesn't include a way to tell it otherwise.)

One fun detail that took a couple of iterations to get right: I keep
separate "staged" and "working" versions per-series, so even with
outstanding changes to the cover letter, base, or series, you can always
detach or checkout another series without losing anything.  If you
switch back, all your staged and unstaged changes will remain staged and
unstaged where you left them.  That solves the "checkout a different
series with modifications to the current series" case.

> git-appraise looks as though it might also have this behaviour.
> I think it's a nice way to do it, since you don't generally
> perform more than one review simultaneously. So I may well
> use this idea in git-candidate if it's okay. :)

By all means.  For a review tool like git-candidate, it seems like you'd
want even more contextual information, to make it easier to specify
things like "comment on file F line L".  For instance, what if you
spawned the diff to review in an editor, with plenty of extra context
and a file extension that'll cause most editors to recognize it as a
patch (and specifically a git-candidate patch to allow specialized
editor modes), and told people to add their comments after the line they
applied to?  When the editor exits successfully, you can scan the file,
detect the added lines, and save those as comments.  You could figure
out the appropriate line by looking for the diff hunk headers and
counting line numbers.

If you use a format-patch diff that includes the headers and commit
message, you could also support commenting on those in the same way.
Does the notedb format support commenting on those?

> I haven't found time to use the tool to do any serious review
> yet, but I'll try and post some more feedback when I do.

Thanks!

- Josh Triplett

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Richard Ipsum]

On Thu, Aug 04, 2016 at 12:40:58PM -1000, Josh Triplett wrote:
> On Wed, Aug 03, 2016 at 08:12:02PM +0100, Richard Ipsum wrote:
> > On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
> > > I'd welcome any feedback, whether on the interface and workflow, the
> > > internals and collaboration, ideas on presenting diffs of patch series,
> > > or anything else.
> > 
> > One other nice thing I've noticed about this tool is the
> > way series behave like regular git branches: I specify the name
> > of the series and from then on all other commands act on that
> > series until told otherwise.
> 
> Thanks; I spent a while thinking about that part of the workflow.  I
> save the current series as a symbolic ref SHEAD, and everything operates
> on SHEAD.  (I should probably add support for running things like "git
> series log" or "git series format" on a different series, because right
> now "until told otherwise" doesn't include a way to tell it otherwise.)

Apologies for this delayed response,
I needed time to gather my thoughts,
and also to fix the perl libgit2 binding to allow me to use
your symbolic ref suggestion. :p

Though it turns out that libgit2 doesn't currently allow
me to write arbitrary data to a symbolic ref as git-symbolic-ref(1) will,
so this still needs to be fixed somehow.

> 
> One fun detail that took a couple of iterations to get right: I keep
> separate "staged" and "working" versions per-series, so even with
> outstanding changes to the cover letter, base, or series, you can always
> detach or checkout another series without losing anything.  If you
> switch back, all your staged and unstaged changes will remain staged and
> unstaged where you left them.  That solves the "checkout a different
> series with modifications to the current series" case.

Cool

> 
> > git-appraise looks as though it might also have this behaviour.
> > I think it's a nice way to do it, since you don't generally
> > perform more than one review simultaneously. So I may well
> > use this idea in git-candidate if it's okay. :)
> 
> By all means.  For a review tool like git-candidate, it seems like you'd
> want even more contextual information, to make it easier to specify
> things like "comment on file F line L".  For instance, what if you
> spawned the diff to review in an editor, with plenty of extra context
> and a file extension that'll cause most editors to recognize it as a
> patch (and specifically a git-candidate patch to allow specialized
> editor modes), and told people to add their comments after the line they
> applied to?  When the editor exits successfully, you can scan the file,
> detect the added lines, and save those as comments.  You could figure
> out the appropriate line by looking for the diff hunk headers and
> counting line numbers.

I really like this idea, the current interface for commenting is a little
tedious I find.

> 
> If you use a format-patch diff that includes the headers and commit
> message, you could also support commenting on those in the same way.
> Does the notedb format support commenting on those?

Comments in notedb are just a git note keyed on the sha of the
commit being commented on, I'm not certain what advantage a format-patch
diff provides in this case?

I've been closely following the 'patch submission process' thread,
and given the discussion there I'm having doubts over the value
of comments in git-candidate vs the mailing list. It seems to me that
git-candidate has many of the disadvantages of Github/Gitlab when it
comes to comments, for example, there is no threading.

Also the system would be less open than the mailing list, since,
as it stands currently you would require push access to the repository
to comment on anything.

It may be worth reflecting that one reason some organisations
have switched away from mailing list reviews to Github/Gitlab is that
they provide patch tracking, where the mailing list provides none,
so patches there can be 'lost'. So instead of trying to reimplement
an entire Gerrit/Github/Gitlab ui on the commandline, I wonder whether
it would be sufficient to add the minimum functionality necessary
to provide git with native patch tracking, and leave comments for the
mailing list. Ofcourse this is exactly what git-series seems to do,
so in some sense I may be advocating dropping my own work in favour of
improving git-series.

On the other hand, relying on the mailing list means that some of the
history of a series is left outside of the repository which is
anathema to the goal of git based/stored review, not least because
mail archives are centralised.
(which can obviously be problematic (as we've seen recently with gmane))

Maybe there's a better solution to this problem than git-candidate then,
maybe we can just invent some wonderful new subcommand that fetches
a mailing list archive into a git repo, for those that want that,
I don't know.

Out of interest, did you have any thoughts on Notedb itself with respect
to its suitability for git-series?

> 
> > I haven't found time to use the tool to do any serious review
> > yet, but I'll try and post some more feedback when I do.
> 
> Thanks!
> 

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Josh Triplett]

On August 9, 2016 11:37:31 PM HST, Richard Ipsum <richard.ipsum@codethink.co.uk> wrote:
>On Thu, Aug 04, 2016 at 12:40:58PM -1000, Josh Triplett wrote:
>> On Wed, Aug 03, 2016 at 08:12:02PM +0100, Richard Ipsum wrote:
>> > On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
>> > > I'd welcome any feedback, whether on the interface and workflow,
>the
>> > > internals and collaboration, ideas on presenting diffs of patch
>series,
>> > > or anything else.
>> > 
>> > One other nice thing I've noticed about this tool is the
>> > way series behave like regular git branches: I specify the name
>> > of the series and from then on all other commands act on that
>> > series until told otherwise.
>> 
>> Thanks; I spent a while thinking about that part of the workflow.  I
>> save the current series as a symbolic ref SHEAD, and everything
>operates
>> on SHEAD.  (I should probably add support for running things like
>"git
>> series log" or "git series format" on a different series, because
>right
>> now "until told otherwise" doesn't include a way to tell it
>otherwise.)
>
>Apologies for this delayed response,
>I needed time to gather my thoughts,
>and also to fix the perl libgit2 binding to allow me to use
>your symbolic ref suggestion. :p

Yeah, during git-series development I ended up doing some work on both libgit2 and git2-rs. :)

>Though it turns out that libgit2 doesn't currently allow
>me to write arbitrary data to a symbolic ref as git-symbolic-ref(1)
>will,
>so this still needs to be fixed somehow.

What arbitrary data do you need to write?

Also, note that you want to put your symbolic ref in refs/, not directly in .git, so that git takes it into account for object reachability.

>> > git-appraise looks as though it might also have this behaviour.
>> > I think it's a nice way to do it, since you don't generally
>> > perform more than one review simultaneously. So I may well
>> > use this idea in git-candidate if it's okay. :)
>> 
>> By all means.  For a review tool like git-candidate, it seems like
>you'd
>> want even more contextual information, to make it easier to specify
>> things like "comment on file F line L".  For instance, what if you
>> spawned the diff to review in an editor, with plenty of extra context
>> and a file extension that'll cause most editors to recognize it as a
>> patch (and specifically a git-candidate patch to allow specialized
>> editor modes), and told people to add their comments after the line
>they
>> applied to?  When the editor exits successfully, you can scan the
>file,
>> detect the added lines, and save those as comments.  You could figure
>> out the appropriate line by looking for the diff hunk headers and
>> counting line numbers.
>
>I really like this idea, the current interface for commenting is a
>little
>tedious I find.
>
>> 
>> If you use a format-patch diff that includes the headers and commit
>> message, you could also support commenting on those in the same way.
>> Does the notedb format support commenting on those?
>
>Comments in notedb are just a git note keyed on the sha of the
>commit being commented on, I'm not certain what advantage a
>format-patch
>diff provides in this case?

I meant for opening in an editor to write email-reply-style comments. The review tool and review storage format should allow commenting on commit messages, not just diffs.

>I've been closely following the 'patch submission process' thread,
>and given the discussion there I'm having doubts over the value
>of comments in git-candidate vs the mailing list. It seems to me that
>git-candidate has many of the disadvantages of Github/Gitlab when it
>comes to comments, for example, there is no threading.

That's not inherent, though. You could allow commenting on a comment easily enough. (Of course, at some point you've recreated email-style in-reply-to headers...)

>Also the system would be less open than the mailing list, since,
>as it stands currently you would require push access to the repository
>to comment on anything.

You'd need a federation mechanism.

>It may be worth reflecting that one reason some organisations
>have switched away from mailing list reviews to Github/Gitlab is that
>they provide patch tracking, where the mailing list provides none,
>so patches there can be 'lost'. So instead of trying to reimplement
>an entire Gerrit/Github/Gitlab ui on the commandline, I wonder whether
>it would be sufficient to add the minimum functionality necessary
>to provide git with native patch tracking, and leave comments for the
>mailing list. Ofcourse this is exactly what git-series seems to do,
>so in some sense I may be advocating dropping my own work in favour of
>improving git-series.

I think the two serve different (though related) functions. I'd love to be able to use a text editor and command-line tool to produce and submit comments to systems like Gerrit or GitHub.

>On the other hand, relying on the mailing list means that some of the
>history of a series is left outside of the repository which is
>anathema to the goal of git based/stored review, not least because
>mail archives are centralised.
>(which can obviously be problematic (as we've seen recently with
>gmane))

Agreed. You can always choose to *intentionally* discard history, or store it elsewhere, but having it in the repository allows you to make that decision with all the data really available (and easily backed up).

>Maybe there's a better solution to this problem than git-candidate
>then,
>maybe we can just invent some wonderful new subcommand that fetches
>a mailing list archive into a git repo, for those that want that,
>I don't know.

public-inbox seems to address that use case. I'd love to see a public-inbox version of LKML, with full history. I don't think that fully solves the review storage and interchange problem, but it seems like an *excellent* solution for email archiving, and for distribution of archives.

>Out of interest, did you have any thoughts on Notedb itself with
>respect
>to its suitability for git-series?

Seems like a potentially reasonable format for storing reviews. I think the two could work well together, with git-series storing all the historical versions of a series, and then a notedb could reference those commits.

I've given some thought to using git-series as a server-side storage format for something like a pull request. I think it might make sense for a tool like Gerrit or GitLab to allow pushing and pulling series branches (that must fast-forward) to a special ref (like Gerrit's refs/for/master).

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Eric Wong]

Josh Triplett <josh@joshtriplett.org> wrote:
> On August 9, 2016 11:37:31 PM HST, Richard Ipsum <richard.ipsum@codethink.co.uk> wrote:
> 
> >Maybe there's a better solution to this problem than git-candidate
> >then,
> >maybe we can just invent some wonderful new subcommand that fetches
> >a mailing list archive into a git repo, for those that want that,
> >I don't know.
> 
> public-inbox seems to address that use case. I'd love to see a
> public-inbox version of LKML, with full history. I don't think
> that fully solves the review storage and interchange problem,
> but it seems like an *excellent* solution for email archiving,
> and for distribution of archives.

Thanks, I'd like to see an LKML version, too :)  First, I want
to ensure public-inbox can handle large repos better, first.
public-inbox.org/git has been doing well so far, even on a
low-end VM with 2 cores and 2GB RAM.

I don't have anything close to full history of LKML, and
download.gmane.org is down, right now :<  I'd use NNTP, but
news.gmane.org gets overloaded from slrnpull and I even got
temporarily banned there before discovering download.gmane
:x

Maybe I'll do what was done with linux.git in 2005 and just
ignore old mail for a while...

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Simon Glass]

Hi Josh,

On 1 August 2016 at 12:37, Josh Triplett <josh@joshtriplett.org> wrote:
> On Mon, Aug 01, 2016 at 09:14:54AM -0600, Stephen Warren wrote:
>> On 07/29/2016 12:40 AM, Josh Triplett wrote:
>> > I'd like to announce a project I've been working on for a while:
>> >
>> > git-series provides a tool for managing patch series with git, tracking
>> > the "history of history". git series tracks changes to the patch series
>> > over time, including rebases and other non-fast-forwarding changes. git
>> > series also tracks a cover letter for the patch series, formats the
>> > series for email, and prepares pull requests.
>>
>> Just as an FYI, I wouldn't be surprised if there's some overlap, or
>> potential for merging of tools, between this tool and the "patman" tool
>> that's part of the U-Boot source tree:
>>
>> http://git.denx.de/?p=u-boot.git;a=blob;f=tools/patman/README;h=e36857dedea1d0dbafa41732aaf9bf0988d63f38;hb=HEAD
>
> Interesting tool; thanks for the link.
>
> As far as I can tell from that documentation, patman doesn't track old
> versions of a patch series; you rebase to modify patches or change
> patman tags (embedded in commit messages), and nothing preserves the
> previous version.  And it tracks the cover letter and similar in one of
> the commit messages in the series, so previous versions of that don't
> get saved either.  If you wanted to track the history of your changes,
> you'd have to use branch names or similar.

That's right. Normally you would keep the old branch around, or tag
it. Of course old branches are often based on older versions the
upstream repo, so they are not that useful for diiff, etc. But the
normal procedure when updating a series to a new version is:

git checkout -b wibble-v2 wibble
git rebase upstream/master
git commit --amend
# Edit commit to add 'Series-version: 2', update cover letter etc.

Of course any change log is preserved when you move to v3, since you
just add more 'Series-changes:' tags. The old version of the cover
letter, and the old version of the commits can be preserved with 'git
tag'.

>
> In addition, tracking metadata in commit messages only works with a
> patches-by-mail workflow where the messages get processed when
> generating patches; that doesn't work for please-pull workflows.

Can you explain what a please-pull workflow looks like, and what tags
are expected?

>
> patman does have quite a few interesting ideas, though.  git-series
> needs some way of handling To/Cc addresses for patches and the cover
> letter (beyond just scripts/get_maintainer.pl), and more automatic
> handling of series versioning (v2, v3, ...) and associated series
> changelogs.  Suggestions welcome.

Patman builds the cover letter change lists from the commits. The main
point of patman is to automate the error-prone process of submitting a
perfectly formed patch series.

In particular, patman requires no change to the normal workflow that
people use with git.

>
> - Josh Triplett

Regards,
Simon

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Josh Triplett]

On Mon, Aug 15, 2016 at 12:17:11PM -0600, Simon Glass wrote:
> On 1 August 2016 at 12:37, Josh Triplett <josh@joshtriplett.org> wrote:
> > On Mon, Aug 01, 2016 at 09:14:54AM -0600, Stephen Warren wrote:
> >> On 07/29/2016 12:40 AM, Josh Triplett wrote:
> >> > I'd like to announce a project I've been working on for a while:
> >> >
> >> > git-series provides a tool for managing patch series with git, tracking
> >> > the "history of history". git series tracks changes to the patch series
> >> > over time, including rebases and other non-fast-forwarding changes. git
> >> > series also tracks a cover letter for the patch series, formats the
> >> > series for email, and prepares pull requests.
> >>
> >> Just as an FYI, I wouldn't be surprised if there's some overlap, or
> >> potential for merging of tools, between this tool and the "patman" tool
> >> that's part of the U-Boot source tree:
> >>
> >> http://git.denx.de/?p=u-boot.git;a=blob;f=tools/patman/README;h=e36857dedea1d0dbafa41732aaf9bf0988d63f38;hb=HEAD
> >
> > Interesting tool; thanks for the link.
> >
> > As far as I can tell from that documentation, patman doesn't track old
> > versions of a patch series; you rebase to modify patches or change
> > patman tags (embedded in commit messages), and nothing preserves the
> > previous version.  And it tracks the cover letter and similar in one of
> > the commit messages in the series, so previous versions of that don't
> > get saved either.  If you wanted to track the history of your changes,
> > you'd have to use branch names or similar.
> 
> That's right. Normally you would keep the old branch around, or tag
> it. Of course old branches are often based on older versions the
> upstream repo, so they are not that useful for diiff, etc. But the
> normal procedure when updating a series to a new version is:
> 
> git checkout -b wibble-v2 wibble
> git rebase upstream/master

That's the workflow I used before git-series, as well.  Having to create
versioned branch names motivated creating git-series; the branch names
in the git-series documentation ("feature-v8-rebased-4.6-alice-fix") are
*reduced* versions of actual branch names used for internal projects.

> > In addition, tracking metadata in commit messages only works with a
> > patches-by-mail workflow where the messages get processed when
> > generating patches; that doesn't work for please-pull workflows.
> 
> Can you explain what a please-pull workflow looks like, and what tags
> are expected?

You push the branch somewhere, as a branch or tag, and then use git
request-pull or otherwise tell someone "please pull from here".  They
pull the *exact* commit hashes you pushed, including whatever you based
them on.  That means they get the exact commit messages you pushed.  So,
if you have any inline metadata in the commit message, that would end up
in the project history.  The Linux kernel and other projects object to
getting those kinds of bits in commit messages; I've seen many patches
rejected because they included a Gerrit Change-Id.

Tracking the history and cover letter in a separate string of "series
commits" allows the underlying patch series to contain the exact commits
you want upstream to pull, without any postprocessing required.

- Josh Triplett

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Jakub Narębski]

W dniu 11.08.2016 o 00:07, Josh Triplett pisze:
> On August 9, 2016 11:37:31 PM HST, Richard Ipsum
> <richard.ipsum@codethink.co.uk> wrote:
>> On Thu, Aug 04, 2016 at 12:40:58PM -1000, Josh Triplett wrote:
[...]

>>> If you use a format-patch diff that includes the headers and
>>> commit message, you could also support commenting on those in the
>>> same way. Does the notedb format support commenting on those?
>> 
>> Comments in notedb are just a git note keyed on the sha of the 
>> commit being commented on, I'm not certain what advantage a 
>> format-patch diff provides in this case?
> 
> I meant for opening in an editor to write email-reply-style comments.
> The review tool and review storage format should allow commenting on
> commit messages, not just diffs.

There is also cover letter and interdiff, and one would want to
be able to comment also on those.

So how notedb solve problem of in-diff comments, in-commit comments,
post-commit comments, whole series cover letter and cover-letter
comments, interdiff and interdiff message / comments?


Nb. GitHub Pull Requests include only some of those, compared to
the mailing list / Usenet news interface.
 
>> I've been closely following the 'patch submission process' thread, 
>> and given the discussion there I'm having doubts over the value of
>> comments in git-candidate vs the mailing list. It seems to me that 
>> git-candidate has many of the disadvantages of Github/Gitlab when
>> it comes to comments, for example, there is no threading.
> 
> That's not inherent, though. You could allow commenting on a comment
> easily enough. (Of course, at some point you've recreated email-style
> in-reply-to headers...)

I wonder if we could use 'parent' header of a commit message for this,
or equivalent...
 
>> Also the system would be less open than the mailing list, since, as
>> it stands currently you would require push access to the
>> repository to comment on anything.
> 
> You'd need a federation mechanism.

...which is as easy to set up and use as mailing list, for sending
patches, applying patches, and patch review.  And/or provide 
bi-directional interface to the mailing list (I think Debian 
infrastructure tries to be (inter)operable by email).

There are various federated technologies (like pump.io), the
problem might be their popularity.

>> It may be worth reflecting that one reason some organizations have
>> switched away from mailing list reviews to Github/Gitlab is that 
>> they provide patch tracking, where the mailing list provides none, 
>> so patches there can be 'lost'. So instead of trying to
>> reimplement an entire Gerrit/Github/Gitlab UI on the commandline, I
>> wonder whether it would be sufficient to add the minimum
>> functionality necessary to provide git with native patch tracking,
>> and leave comments for the mailing list. Of course this is exactly
>> what git-series seems to do, so in some sense I may be advocating
>> dropping my own work in favour of improving git-series.
> 
> I think the two serve different (though related) functions. I'd love
> to be able to use a text editor and command-line tool to produce and
> submit comments to systems like Gerrit or GitHub.

I think there are command-line tools that allow to submit comments
to GitHub.

-- 
Jakub Narębski