Add gerrit support
guyzmo opened this issue · 5 comments
Note: tracked on @wikimedia's phabricator too: https://phabricator.wikimedia.org/T180962
I claimed this task on @wikimedia's phabricator and working on it now
Hey @Phantom-42, let's have a little discussion over here about the UX design of this PR. Currently you've implemented the following:
git gerrit request <project> create [--opts]
git gerrit request <project> fetch <ref>
usually, when adding a new service, what I start with are the basic operations:
- get a project (
clone
) - create a new project (
create
), - delete an existing project (
delete
), - add service's remote to current project (
add
), - fork the project (
fork
)
then I might play with some tougher APIs:
- list projects (
list
) - handle snippets/gists (when supported)
- handle requests (
create
/fetch
)
Now given the nature of gerrit, things might happen differently with it. But the questions are:
- how to match gerrit's workflow with the above toolbox, and
- what would be missing to add in that toolbox?
I believe that feedback work (generally speaking, commenting/reading/acting on issues (#104) and PRs) is the next must-have feature of git-repo
, but it's tough to actually design it right.
so as you're working on it, @Phantom-42, may I ask you for your opinion? (and @jayvdb as well, of course).
Well, the most actively used functions (clone
, patchset pushing / reviewing, changes list) are already implemented. Other frequently used functions will come soon.
create
, delete
, fork
, add
are basic operations, but we skipped them for now as these functions are used rarely.
There are not snippets/gists/etc on Gerrit, however we need to focus on developing functionality related to patchset reviewing instead.
I will think more about this and will notify if I have any thoughts.
Anyway, I believe @jayvdb has far more ideas about this.
I've had a thought about interactions. As far as I remember last time I used gerrit (that was when I contributed some patches to some obscure Qt library), the process was:
- add the gerrit remote to my local repository ;
- create a new request on gerrit ; (or fetches one from gerrit)
- add the remote ref and pull it as a branch locally ;
- push -f my changes to that remote ref up until patchset review is approved and over ;
so how I'd see things, that would be:
# I got a bunch of commit to submit for reviewing
git gerrit add # adds the gerrit remote to the current local repository
git gerrit request create # creates and fetches a new request as local ref
git co local/refs/of/patchset/being/reviewed
# make changes
git push -f gerrit
or
# I got a bunch of commit to submit for reviewing
git gerrit add # adds the gerrit remote to the current local repository
git gerrit request list # lists the requests being reviewed
git gerrit request fetch refs/of/patchset/being/reviewed # fetches a patchset to review
git co local/refs/of/patchset/being/reviewed
# make changes
git push -f gerrit
also, a nice to have feature, even though it's definitely not a must have, would be the git gerrit list
feature (to list all projects of the current user). Why I like that feature, it's because I often use it to check that my credentials still work for a given service ;)