Pull Requests / Code Review / Patch Sets

[gitblit]

Originally reported on Google Code with ID 215

Hi,

Sounds like some great software. I would just like to put in my vote, as mentioned
as an idea on your Roadmap, for pull request capability. I don't think this is asking
for a full-blown social tool, but even for my small team, I'd like for them to only
be able to make tentative pull requests, so I have a chance to review before accepting.

Thanks!

Reported by brettz9 on 2013-03-06 07:11:18

[gitblit]

What would you define as the minimum feature set necessary for pull requests?

Reported by James.Moger on 2013-03-06 12:56:27

[gitblit]

I think just the ability for a user to submit a pull request from any branch to a given
repo or repo owner, and the ability of the receiving repo owner to view a list of outstanding
pull requests with say a checkbox on each item to indicate which requests can be applied
and auto-closed.

A list of requests viewable by the submitter would certainly be very useful, but even
without that, it would be useful. Messages (whether for proposal, closing, or in the
interim) would be nice, but I think the commit message would be good enough for starters
as users could communicate out of band. Email notifications for new requests and closed
requests would be cool, but again, not critical.

Reported by brettz9 on 2013-03-06 13:16:19

[gitblit]

Also, with the checkboxes, the ability to dismiss and delete a pull request without
applying.

Reported by brettz9 on 2013-03-06 13:17:53

[gitblit]

I'm linking to a Google Plus thread which discusses pull requests.
https://plus.google.com/114464678392593421684/posts/Xt3SXpioTK1

And a blog post that pinpoints my complaints about pull requests.
http://julien.danjou.info/blog/2013/rant-about-github-pull-request-workflow-implementation

At the moment, I am leaning towards implementing a simplified Gerrit patchset mechanism
rather than GitHub-style pull requests.

I do have prototype code for both - although my patchsets code is further along.  After
I get the 1.3.0 release out-the-door I can get devote more time to this issue, polish
what I have, and solicit feedback.

Reported by James.Moger on 2013-07-03 15:28:39

[gitblit]

Reported by James.Moger on 2013-07-15 17:36:07

• Labels added: Milestone-1.4.0

[gitblit]

Reported by James.Moger on 2013-07-15 17:36:17

• Status changed: Started

[gitblit]

Hi, I hope you don't mind me adding my 2p's worth after reading the various discussions...

IMHO I wonder whether the PR and/or PS functionality should not really be in gitblit.
Possibly the ability to do a server-side merge of branches and/or a patch queue for
a branch would be convenient, with an API that allows those functions to be triggered
by an external client. I realise that's very similar to PR and PS but I think there's
a subtle difference. The actual request to "pull" a branch or apply a patch IMO should
be handled outside of the repository manager,I.e email, IM, talking to a colleague,
by whatever means is appropriate for the individuals or business. That means whatever
tools used for code review, auditing, etc. can be used in conjunction with gitblit,
albeit whether it's a manual step at the end of the process to merge the branch or
apply the patch or hopefully that external tool can have a plugin that allows you to
press a button and have that tool invoke that final step on gitblit automatically.


As I see it if PR (a-la github, Atlassian's Stash) or PS (gerrit) are implemented in
gitblit it'll either be a continual battle to keep up feature wise or a duplication
of effort. 

Sorry if I've got the wrong end of the stick and I hope I've made sense. I think gitblit
is fantastic.

Reported by alex.lewis001 on 2013-09-24 17:55:27

[gitblit]

Duplication of effort.  For sure it is.  But then so is all of Gitblit or Stash or Gerrit
or GitLab, etc.  They all essentially do the same thing as GitHub, BitBucket, BeanStalk,
whatever.

Gitblit aims to be a complete Git server solution.  That doesn't mean I plan to implement
1:1 what all others offer, but there are some things that I believe are expected of
a server solution: security, repo viewing, repo administration, activity notifications,
etc, and I think a collaboration mechanism (PR or PS or ??) - however primitive - is
on that list.

I think Gitblit should do more to facilitate collaboration and communication _somehow_.
 That doesn't mean this feature must be used by everyone or that everyone is going
to like my particular implementation.  So whenever it lands, it will be optional for
those who want to use other, more-capable, tools like Gerrit or Review Board or a manual
process that works well for them.

Up hill battle.  It already is.  Have you seen the rate that GitHub is adding staff
since the last round of VC funding??  Subscribe to their blog... it seems like 1 a
week.  Wow!  I can't compete with that.  :)

I think I understand your position and I'll keep that use-case in mind as I move forward.
 Thanks for giving this issue some thought.

Reported by James.Moger on 2013-09-24 19:16:03

[gitblit]

Thanks James for your response. 

To be honest after using GitBlit more aggressively I can see how a collaboration mechanism
is an expected feature. 

Personally I like Pull Requests (I have read the links you posted but I admit I need
to read them again) but maybe that's because they're easier to understand up front,
or more specifically they map better to the way in which I think about the history,
the branches, etc. The patchset mechanism just seems too disconnected from the repository,
but that's just me :)

p.s. Keep up the great work!

Reported by alex.lewis001 on 2013-10-30 18:20:35

[gitblit]

First of all: I *love* GitBlit. :)

Second: I'd like to give my vote for PR's. GitHub PR's are nice, but after seeing them
in BitBucket, I think they're great.

And to be honest, Gerrit seems to be overkill for my / our purposes.

Reported by martijn.niji on 2013-11-11 13:06:23