Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

How to select git commits for a review of a feature branch with updates?

We have a workflow where devs do feature branches, and update from (that is, merge in) the master branch occasionally. [Rebases are not an option.]

So, we have two states A and B on the master branch. dev starts its branch off A, does work in F and G, then updates from the later master commit B resulting in merge commit M, and finally does some more stuff as P. [See pic (linked) below]

Now, what commits would I select when creating a crucible review. Then (apparently naive) guess would be F, G, P, as those contain the work the dev did. But the resulting overall diff is the same as with F, G, M, P - it includes all the new features that got merged in in the update. Not what I want.

The original F,G,P selection does not even allow me to review the change of P separately - the commits available in the selection bead line are only A,F,G,P, so I can only see the diff from G to P which puts together the merge differences (M) and the dev's last change (P).

As the total change I want to review is B...P I finally try to give M and P, but stupidly in this case crucible is using the first parent of M (which is G) as the starting commit of the review, not B, so my review offers no possibility to see the effective diff the dev did with his work.

So basically there seems no way to create a single (or even a set of) review(s) that can show exactly the changes the dev created - it always suffer from the flattening of the actual git commit graph into a single bead line (the red/gray thing that allows review range selecton) plus the fact that a review is not defined by start and end point but rather by naming a set of commits.

After writing that discussion my expectation is that the commit bead line shouldn't be a line but indeed a graph, and the default pair of commits to diff over should be B..P, so I can see the full dev's diff, and also watch (and discuss) intermediate changes he did.

tl;dr crucible should take into account the branching structure of git, and especially it should allow for merge commits to select the parent against which to diff.

So, how do I work around this?

Branch graph:dag (

1 answer

Second one of these I find today. With NO answer!

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events