Distributed code review discussion

Are there any plans for supporting merge requests and code reviews natively in git?

What I mean is a distributed code review system where a merge request along with review comments would be stored within the git repository and allowed to be pushed and pulled between repository clones. This would allow users to retain the code review history without relying on centralized or proprietary third party solutions.

I am debating on creating a plugin for the current git suite starting
with a bash script as a proof of concept and eventually creating a GUI
via Tcl/Tk for best cross-platform support. The idea is to store the
code review metadata as empty commits within a branch. This is for a
number of reasons:
- Ensure backwards compatibility with all current git clients. Classic
git push, pull, merge commands will be able to move the code review
metadata around.
- Easy migration on and off of the distributed code review system. No
leftover metadata stored within the user's repository besides human
readable commits.
- If desired, empty commits can be easily squashed after merge or
summarized into a single commit to retain history.
- Commits can be created outside of the code review plugin.

Example commits: "## Open refs/heads/distributed-review -> refs/heads/master -- Distributed code review feature" "## Comment 71a3f9 src/review.c:412 -- Did you even compile this?" "## Close 71a3f9 -- This feature is horrible, closing..."

Questions:
- Are you interested in adding this sort of functionality to git? I
would be very interested in contributing instead of working alone.
- Am I crazy? Do you see an interest from the community in distributed
code reviews?
- Any other criticism?

Thank you, Matus Faro

On Sat, Jan 10, 2015 at 10:05 AM, Matus Faro <matusfaro@gmail.com> wrote:

I remember hearing that Gerrit is already going in that direction, except that their plan do not include contaminating the project's real history with the review metadata. You may want to study what they plan to do in order to make yours compatible, if you are planning to write a new one.

On Sat, Jan 10, 2015 at 01:05:35PM -0500, Matus Faro wrote:

You can do this today with pull-requests and code review happening in email, since you just have to distribute the mail archives to have a record of pull-requests and code review discussions (e.g. notmuch posts an mbox of it's list archives [1]). For better usability, you have a few more options borrowing from the notmuch workflow:

* Index messages in notmuch [2] (like notmuch does) and tag them so
  you know what branches are waiting on review [3] or author feedback
  [4].
* Use nmbug [5] to collaborate on tagging and distribute tags to
  interested parties.

Things I've been thinking about doing “at some point”:

* Use ssoma [6] or my ssoma-mda Python port [7] to store the list
  archives in Git using this format [8].  I'd like to teach notmuch to
  read messages directly from the ssoma archive, which would let you
  replace the mbox archive with something that's easier to collaborate
  on than an mbox archive (e.g. for removing duplicates or fixing
  typos).  If all interested parties are using ssoma-style storage for
  the archives, you don't have to worry about “oops, I didn't mean to
  hit send” types of errors, since it's easy to patch the archive
  itself.
* Provide a web-UI for browsing the archive and manipulating tags, so
  folks don't need to install Git / notmuch / ssoma to get involved in
  patch review.  I'd still have them submit comments via email, but
  you could have the web-app send email for them if you have
  anti-email users ;).

Cheers, Trevor

[1]: http://notmuchmail.org/archives/notmuch.mbox [2]: http://notmuchmail.org/ [3]: http://nmbug.tethera.net/status/#Review [4]: http://nmbug.tethera.net/status/#Moreinfo [5]: http://notmuchmail.org/nmbug/ [6]: http://ssoma.public-inbox.org/README [7]: http://git.tremily.us/?p=ssoma-mda.git [8]: http://ssoma.public-inbox.org/ssoma_repository.txt