Can gerrit be used with Stash?

[Brian Jones]

That is, can I have a Stash-hosted git repository flow changes through gerrit?

I think the answer is 'no' but thought I'd ask.

[cofarrell · Accepted solution]

Hi Brian,

That really depends on Gerrit. If you can configure it to push changes after a review to another Git server, there shouldn't be any reason why that destination couldn't be Stash. This looks like it might be useful:

http://gerrit.googlecode.com/svn/documentation/2.0/config-replication.html

Of course, being a Stash developer, I'd also suggest trying out our (awesome) Pull Requests which we introduced in 1.3, which I think would be roughly equivalent to Gerrit reviews. ;-)

Cheers,

Charles

[Brian Jones]

Charles,

Thanks for the link. I gave the stash pull requests feature a test drive today. It's heading in the right direction. We are developing on feature branches which are delivered into release windows at which time they roll into master if their release criteria is met. It seems like the stash pull request fits part of this. What I really need to be able to do is select a collection of feature branches and see if they merge/build together with the ability to change the feature set as business needs change over time. I'm not quite sure how to implement this up yet.

Brian

[cofarrell]

Hi Brian,

That's a tricky one. Sounds like you need to regularly create/destroy temporary branches and possibly run a build against the result. You could certainly write a script to do that, and run it every day/week/whatever. There is obviously the change of multiple merge conflicts. If you created pull requests to a release branch, Stash will certainly keep track of the merge state for each one, but doesn't really give you a way to 'administer' them as a collection; that's not really their purpose. I'm afraid I haven't had enough experience with Gerrit to comment on whether it would be better at that or not.

Let me know if you find something that helps with this workflow. We're always on the look-out on how to improve/extend Stash to help with different business requirements.

Cheers,

Charles

[Brian Jones]

Thanks Charles,

Yes, it currently seems that our build process will need to use on-the-fly temp branches and merge/build.

Here is a blue sky thought -- What if Jira issues know how to branch themselves in git and assume they are developed on feature branches, one issue/branch. Then, when a developer starts working on an issue, Jira and Stash know how to setup that branch. Jira also knows what issues are targeted for a given release given the Jira roadmap. A plan in Bamboo could then be to take all the Jira feature branches for a given release and merge/build them. The sticky part is when merge failures occur. Rerere would need to be worked into the workflow to address that.

Brian

[cofarrell]

Hi Brian,

We are certainly in discussion around tighter integration around Stash/Jira and Bamboo, although I couldn't give you any concrete timeframes around when it would ship.

The tricky part is, as you point out, handling the merges and conflicts. I suspect we would probably delegate to an external/extra plugin handle that custom/extra workflow of merging mutliple feature branches, but it's early days yet. Rerere wouldn't really help Stash as you would always have to do the merges locally.

Thanks again for the suggestion. If you like feel free to raise an issue on JIRA so we can track the feature request further.

https://jira.atlassian.com/browse/STASH

Cheers,

Charles

[David Pinn]

Hi Brian. I'll be releasing a Stash add-on very soon called Rendezvous, which allows you to define collections of branches, and monitor their eventual merging. A subsequent release will provide the ability to fire off actions when a rendezvous point has been reached. Hopefully, Rendezvous will get you a little further towards the workflow that you are after.

[Brian Jones]

David, that sounds very interesting. Does the Rendezvous project have a web presence I can follow? I'd like to understand what use cases you are targeting.

Brian

[David Pinn]

Brian, a home page for the Rendezvous add-on is yet to come, but here's a brief summary:

With Rendezvous you can..

• Group related branches under named Rendezvous Points.
• View the state of a rendezvous point in terms of the merges yet to be completed.
• See at a glance which branches remain 'independent' (un-merged).
• Receive email notification when a rendezvous point is reached.
• Register yourself as a watcher of someone else's Rendezvous Point
• Set a pattern for a Rendezvous Point and have branches automatically added to it if their names match the pattern.

[Brian Jones]

David,

Thanks--that looks promising. We also would be interested in the ability to

* Move a feature to a later merge point

* Move a feature to an earlier merge point

* Have parallel development. Say a release cycle takes 4 weeks and one release cycle is started every two weeks. At any given time this means that there are two releases in play. One release is being fished up and another is being started. For each, there is a deadline of when the merge must take place but prior to that, features can be rescheduled to an earlier or later release date.

The above may just be a function of the DVCS, I'm not sure how it will end up playing out in our case.

Brian

[David Pinn]

Hi Brian. Rendezvous has been released. More workflow features will follow. Cheers.