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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html