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 -- 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