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
RIRichard Ipsum <richard.ipsum@codethink.co.uk>
Date
Jul 29, 2016, 12:44 UTC
Message-ID
<20160729124443.GA3686@salo>
In-Reply-To
<20160729110426.GA2945@x>

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

Show 6 quoted lines
> 
> 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.

Show 12 quoted lines
> 
> > 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.

Show 7 quoted lines
> 
> 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.

Show 7 quoted lines
> 
> > 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.
Show 5 quoted lines
> 
> 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.
Previous: Josh TriplettNext: Josh Triplett
Message 4 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.