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

Re: [PATCH 0/2] git-candidate: git based patch tracking and review

From
Michael Haggerty <mhagger@alum.mit.edu>
Date
Nov 11, 2015, 09:55 UTC
Message-ID
<5643107B.20501@alum.mit.edu>
In-Reply-To
<1447160198-23296-1-git-send-email-richard.ipsum@codethink.co.uk>
On 11/10/2015 01:56 PM, Richard Ipsum wrote:
Show 6 quoted lines
> I've continued my work[1] to add patch tracking and candidate review capability
> to git.
> 
> git-candidate now has a more git-like user interface, so remote candidates
> can now be specified in a similar way to remote refs (e.g. origin/candidate)
> as well as various other improvements, such as versioned metadata.

This is a really interesting project. I've seen a blog post or two proposing to store bug tracker information in Git in a distributed way, but I don't recall anything about doing the same for code review information.

I would be interested to hear about the design of your system at an abstract technical level. What do you store in Git and in what layout? Do you need to record any extra metadata within the commits that are merged to master? How do you merge and/or reconcile code review comments that come from multiple sources (or are they just tabulated)? Can your system handle the rebasing of topic branches? What about nonlinear topic branches (branches branches that themselves include merges)?

All that being said, my gut feeling is that a system like this should not be developed within the Git project itself. Code review is a complicated thing, and I expect that different people will have very different ideas about how it should work. It would be a bad idea for the Git project to "bless" one system by including it in our source tree. (Earlier in the Git's history it was easier to get something accepted into "contrib", but that has gotten much harder over time.)

If, someday, one system becomes crushingly dominant, then conceivably it would make sense for it to be distributed along with Git for the convenience of users. Or if a bunch of review systems standardize on a single data model for storing review information in a Git repo, it might make sense for the plumbing for handling that data to reside in git-core for performance and data integrity reasons. Until then, I think it would be better for code review systems to live on their own, as independent projects.

In my opinion it would be fine to discuss the design of your system and solicit feedback about the design on the Git mailing list, and also to publish occasional announcement emails when you release new versions or whatever. You might also want to list your system on the Git SCM wiki, for example here [1].

Yours, Michael

[1] https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools
-- 
Michael Haggerty
mhagger@alum.mit.edu
Previous: Sebastian SchuberthNext: Richard Ipsum
Message 8 of 14 in “git-candidate: git based patch tracking and review”
  1. 0/2 git-candidate: git based patch tracking and reviewRichard Ipsum, Nov 10, 2015
  2. 1/2 contrib: Add git-candidate subcommandRichard Ipsum, Nov 10, 2015
  3. 2/2 contrib/git-candidate: Add READMERichard Ipsum, Nov 10, 2015
  4. David TurnerNov 10, 2015
  5. Richard IpsumNov 11, 2015
  6. David TurnerNov 11, 2015
  7. Sebastian SchuberthJan 6, 2016
  8. Michael HaggertyNov 11, 2015
  9. Richard IpsumNov 11, 2015
  10. Jeff KingNov 14, 2015
  11. Junio C HamanoNov 14, 2015
  12. Jonathan NiederDec 1, 2015
  13. Dave BorowitzDec 1, 2015
  14. Richard IpsumJan 6, 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.