git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Josh Triplett <josh@joshtriplett.org>
Date
Aug 1, 2016, 08:59 UTC
Message-ID
<20160801085928.lw3ltdksyrjujutu@x>
In-Reply-To
<20160801075554.GA22222@starla>
On Mon, Aug 01, 2016 at 07:55:54AM +0000, Eric Wong wrote:
Show 21 quoted lines
> 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
Previous: Eric WongNext: Richard Ipsum
Message 11 of 23 in “[ANNOUNCE] git-series: track changes to a patch series over time”
  1. Josh TriplettJul 29, 2016
  2. Richard IpsumJul 29, 2016
  3. Josh TriplettJul 29, 2016
  4. Richard IpsumJul 29, 2016
  5. Josh TriplettJul 29, 2016
  6. Richard IpsumJul 31, 2016
  7. Stefan BellerJul 29, 2016
  8. Richard IpsumJul 31, 2016
  9. Christian CouderAug 1, 2016
  10. Eric WongAug 1, 2016
  11. Josh TriplettAug 1, 2016
  12. Richard IpsumAug 1, 2016
  13. Eric WongAug 1, 2016
  14. Stephen WarrenAug 1, 2016
  15. Josh TriplettAug 1, 2016
  16. Simon GlassAug 15, 2016
  17. Josh TriplettAug 15, 2016
  18. Richard IpsumAug 3, 2016
  19. Josh TriplettAug 4, 2016
  20. Richard IpsumAug 10, 2016
  21. Josh TriplettAug 10, 2016
  22. Eric WongAug 11, 2016
  23. Jakub NarębskiAug 24, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.