When building a tool that uses git I'm wondering if it is better practice to use git2go (https://github.com/libgit2/git2go) or to do what this author did which is wrap the git command line tool: https://github.com/google/git-appraise/blob/master/repositor...
Kudos to the author.
Clone the repo and then fetch notes manually:
git fetch origin refs/notes/*:refs/notes/*
There are notes from Jenkins and comments from developers as far as I can see.
Seems to be a little bit slow on my computer but the idea is really brilliant.
While I prefer to write code in my terminal, I like to switch settings for reviewing code — with GitHub’s Pull Requests, I can just do it in the browser. Can I use git-appraise in my browser? Is there a stand-alone tool?
I see that an advantage is that it doesn't require server-side setup. But wouldn't one require some sort of central repo to coordinate code reviews and CI tests?
This is distributed but more importantly it looks like it's more entangled/in-tune with git. It says it uses git notes , which appeals to me; they're a feature that are basically useless on their own, but seem to be included exactly for the use of something like git-appraise.
Regarding your comment about a central repo, I'd guess the idea is you use git-appraise like you use git today; it's decentralised in the technical layers, but you assign "central" repo in the human workflow layer.
The point is that you can do reviews locally, push them, and other reviews will fetch. Just as git does not require a central authority, neither does this implementation.
That being said you could still write a web frontend to all of this, ala gerrit.
CI tests could work in a similar way! Each CI runner is polling for new commits, running tests against them, and pushing the results as git-notes in the Git repo, just like for the reviews.
I would appreciate advices on introducing Gerrit to my team and make it somehow transparent in development workflow.
I recorded a video showing how it worked together:
Once you understand the workflow it's actually easy to adopt. The biggest challenge is getting people to think in terms of push requests instead of pull requests. If you configure the remote as "git config push HEAD:refs/for/master" then it becomes as simple as doing "git push" to upload changes.
Looks seriously cool and I am sad!