Pull Requests / Code Review / Patch Sets

[GoogleCodeExporter]

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!

Original issue reported on code.google.com by bret...@gmail.com on 6 Mar 2013 at 7:11

[GoogleCodeExporter]

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

Original comment by James.Mo...@gmail.com on 6 Mar 2013 at 12:56

[GoogleCodeExporter]

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.

Original comment by bret...@gmail.com on 6 Mar 2013 at 1:16

[GoogleCodeExporter]

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

Original comment by bret...@gmail.com on 6 Mar 2013 at 1:17

[GoogleCodeExporter]

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-impl
ementation

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.

Original comment by James.Mo...@gmail.com on 3 Jul 2013 at 3:28

• Changed title: Pull Requests / Code Review / Patch Sets

[GoogleCodeExporter]

Original comment by James.Mo...@gmail.com on 15 Jul 2013 at 5:36

• Added labels: Milestone-1.4.0

[GoogleCodeExporter]

Original comment by James.Mo...@gmail.com on 15 Jul 2013 at 5:36

• Changed state: Started

[GoogleCodeExporter]

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.

Original comment by alex.lew...@gmail.com on 24 Sep 2013 at 5:55

[GoogleCodeExporter]

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.

Original comment by James.Mo...@gmail.com on 24 Sep 2013 at 7:16

[GoogleCodeExporter]

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!

Original comment by alex.lew...@gmail.com on 30 Oct 2013 at 6:20

[GoogleCodeExporter]

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.

Original comment by martijn....@gmail.com on 11 Nov 2013 at 1:06

[GoogleCodeExporter]

Another vote from me on my end, this would be a very welcome feature. Gitblit 
is starting to become a big thing in our company.

Original comment by robindegen on 19 Nov 2013 at 10:28

[GoogleCodeExporter]

This feature alone will make our project move to gitblit. Just a simple way to 
ask for a pull request would be enough - no need for the social framework, just 
a notification that someone has contributed some code and would like it merged 
to a branch would be enough.

I have noticed that in the master branch there is some work on this. Is there 
any idea of when this feature might be incorporated? If it is soon to be out 
(even in beta form), I will probably just deploy gitblit now. Otherwise I'll 
have to go gitlabs or something not as good as gitblit.

Thank you so much for this wonderful software. If you have a link to give 
donations I would send something. Even more if we could send donations "for 
this specific feature".

Original comment by jsrjenk...@gmail.com on 28 Nov 2013 at 11:46

[GoogleCodeExporter]

I hope to have a preview of this capability in the next release.  When is the 
next release?  Hopefully by the end of December.  I try to aim for 3-4 months 
between major releases, with a few point releases as necessary.

What I am working on is a hybrid between Github's pull requests and Gerrit's 
patchsets.  The preview will be functional, but incomplete so expect rough 
edges and missing capabilities.  I ended up losing several weeks to refactoring 
the server codebase (landing soon) and several weeks to a directly related, 
independent (also rough) project developed under the umbrella of this feature.

Thanks for your donations offer, but it isn't necessary - this is a passion 
project for me.  Maybe you already contribute to some project I regularly 
use... or maybe your work will change someone's life for the better.  Either 
way, pay it forward - I'm doing alright. :)

Original comment by James.Mo...@gmail.com on 29 Nov 2013 at 2:26

[GoogleCodeExporter]

Hi we are interested in this feature and when will this be available? 

Would love to get an experience on this. Is a trunk or a work in progress 
version available?

Original comment by mani...@wso2.com on 2 Jan 2014 at 11:58

[GoogleCodeExporter]

Is this in the online demo already or only in trunk? I'm very curious to see 
this "hybrid" you're talking about. :)

Again: great work on GitBlit!

Original comment by martijn....@gmail.com on 13 Jan 2014 at 2:03

[GoogleCodeExporter]

I've been working very hard on getting this put together for early adopters.
I am very close to sharing - next 7-14 days I hope.  Stay tuned.

Original comment by James.Mo...@gmail.com on 13 Jan 2014 at 2:19

[GoogleCodeExporter]

Good news :) I'll see if we can test it internally in our company here.

Original comment by robindegen on 13 Jan 2014 at 2:25

[GoogleCodeExporter]

Hi James, 

This is great. 
Is this code committed to trunk/master? Can I find the work in progress code in 
https://code.google.com/p/gitblit/ so that I can test it with my application?

Thanks

Original comment by mani...@wso2.com on 16 Jan 2014 at 9:13

[GoogleCodeExporter]

Hi Manisha,

Your enthusiasm is noted.  Since it's been 2 days since I wrote that I'd share 
in the next 7-14 days, I'll update that and say I'll share within the next 5-12 
days. :)

-J

Original comment by James.Mo...@gmail.com on 16 Jan 2014 at 2:16

[GoogleCodeExporter]

Hi James, 

I can see the 5-12 days is over by now ;)
Is there a downloadable distribution or a source code available in the repo?

We are eagerly waiting on this feature, which would be extremely useful for us. 

Thanks
Manisha

Original comment by mani...@wso2.com on 28 Jan 2014 at 4:47

[GoogleCodeExporter]

Ok, ok. Pencils down.

<cue ass-kicking, blood-pumping music>

The Tickets feature... (in no particular order)

- is not finished, but is functional
- is not thoroughly tested, but I continuously dogfood it
- is not GitHub issues/pull requests,
  is not BitBucket issues/pull requests,
  is not Gerrit Change Review,
  but does combine aspects of those three with extra flavoring
- is not (yet?) a commit review tool
- is not based on an SQL database
- is focused on commit collaboration, communication, & status workflow
- allows rewriting history AND makes that a first-class feature

This is new and different.  If you've used Gerrit, some of this will seem 
familiar although the mechanics are not the same.  If you've never used Gerrit 
this may seem alien.  The command-line UI can easily be improved with a simple 
helper script or tool.  One was started (mentioned in docs, but is no longer 
suitable for use - needs redesign).  A simple Python or Bash wrapper would go a 
long way here and would be welcome since in my spare time (hahahaha) I'm trying 
to learn Python.  :)

This patchset is big.  There are changes in there which need to be split-out 
into pre-Tickets-patchset commits because they are tweaks or fixes to some of 
the rest of the codebase.  I'll do that in time.

This patchset has cruft (although I've eliminated most).  This code has been 
rebased, squashed, and amended several hundred times in the last 8 months.  
Still, there are rough edges, remnants of design iterations, and just ugly 
shortcuts that need to be cleaned-up.

If you want to play with it, you'll have to build from source.  If you are or 
have been a Gitblit contributor, ping me for an account on this server.  You 
can help me dogfood it.

NOTE: I frequently deploy to this server so it may be unavailable from 
time-to-time, but it is generally online more reliably than OpenShift. :|

Live instance & current patchset.
https://dev.gitblit.com/tickets/gitblit.git/1

Documentation, such as it is.
https://dev.gitblit.com/blob/gitblit.git/refs!tickets!01!1!6/src!site!tickets_ov
erview.mkd
https://dev.gitblit.com/blob/gitblit.git/refs!tickets!01!1!6/src!site!tickets_us
ing.mkd
https://dev.gitblit.com/blob/gitblit.git/refs!tickets!01!1!6/src!site!tickets_se
tup.mkd

Original comment by James.Mo...@gmail.com on 28 Jan 2014 at 3:02

[GoogleCodeExporter]

James, all I gotta say:

You deserve a medal, dude!

Original comment by sundayfu...@outlook.com on 28 Jan 2014 at 8:41

[GoogleCodeExporter]

Very sorry that, as the original poster, I cannot help test, but this sounds 
like a very exciting development! Kudos to all your work!

Original comment by bret...@gmail.com on 28 Jan 2014 at 9:08

[GoogleCodeExporter]

@brettz9: I consider OPs as contributors and I list them in release 
announcements.  Your in, if you want.  dev.gitblit.com is my production machine 
- it's not a playground although we'll make a playground repo for messing 
around.  That is my primary motivation for restricting server access.

Original comment by James.Mo...@gmail.com on 29 Jan 2014 at 1:29

[GoogleCodeExporter]

This looks good!

I hope to see it in a stable release soon.

Hats off to your work James!

Original comment by dhara...@gmail.com on 30 Jan 2014 at 5:07

[GoogleCodeExporter]

Thanks for the announcement James. Being busy with some other commitments 
delayed me from testing this. 
 Since I am not a GB committer, I will build from source and test this. 
Eager to see the feature. 

Thanks
Manisha

Original comment by mani...@wso2.com on 5 Feb 2014 at 4:29

[GoogleCodeExporter]

Merged to master.

Original comment by James.Mo...@gmail.com on 4 Mar 2014 at 2:41

• Changed state: Queued

[GoogleCodeExporter]

1.4.0 released.

Original comment by James.Mo...@gmail.com on 9 Mar 2014 at 6:06

• Changed state: Done