Creating Crucible reviews when using GitHub 'fork' workflow

[Simon Harding]

Hi,

I'm currently in the process of evaluating fisheye + crucible for our development team and I have come across an issue when using it with git and GitHub. Our workflow at the moment is that we have one project origin branch, and all members of the team will 'fork' that branch, which can make creating reviews for their pushed code a little tricky, as I have fisheye just tracking the main repository (but it doesn't appear to track pull requests?)

The work around that I have in place, is that when a user makes a pull request, that they create a diff on it and paste that in as a pre-commit content into the review. However, this obviously loses the changeset history on the commits as "iterations". This method just seems lengthy!

I've used these tools before with Mercurial, and it worked absolutely brilliantly. I'm struggling to find a way to get these two working with git/GitHub the way it did for Mercurial...

Is there a better way? (Without changing the git workflow process)

If there isn't a way, I'll dig into "stash" to see what this can offer in terms of pull request code reviews instead of using Fisheye.

Many thanks,

Simon

[Piotr Swiecicki · Accepted solution]

Hi @Simon Harding,

Just to be clear, will the members of the team fork the whole repository into separate GitHub repository to prepare changes for review on the forked repository?

It would be still possible to create review for those changes in Crucible, if those forked repositories are added to Crucible.  Once they are added and indexed, one can easily create a review showing difference between selected feature and base branches, see https://confluence.atlassian.com/crucible/adding-content-to-the-review-298977455.html#Addingcontenttothereview-Branches

Alternatively, if you find adding each forked repository separately to Crucible and indexing them, you can consider making changes on the dedicated feature branch on the main repository, that would be merged back to the main branch once review is done.  That might be a change to your development process, not sure if feasible then.

Kind regards,
Piotr 

[Simon Harding]

Hi Piotr. Indeed, the members will have forked the entire repository, but the problem here would be that fisheye is limited to 5 repositories (cost is a factor here). Something would indeed need to change with the development process, and your idea on having a dedicated feature branch is worth considering with the team. I've had a look at Stash, which would be another solution without having to change the workflow. Thanks very much for your help. :-) Simon