Will Stash automatic merge ever work?

jason wang10

Hi all,

We have setup Stash the same way the Stash dev team does (hopefullly), by following this blog http://blogs.atlassian.com/2013/10/inside-atlassian-feature-branching-on-the-stash-team/.

A quick sumary about the setup for those who do not have time to read the blog:

Its essentially a feature branch model, simailr to the gitflow model but without the long lasting 'develop' branch -- master is the develop branch.

We use the default naming convention suggested by Stash:

Now, here comes the question: we enabled the automatic merging, hope our bug fixes that go against stable-9.9.0 will fly into stable-10.0.0 as well as master (11.0.0).

The automatic merge got triggered as expected, the PR against 9.9.0 went in, however the automatic merge to 10.0.0 failed due to conflicts.

If looking into the details of the conflict, beside the files changed as part of the fix, it lists every single difference between the 9.9.0 release branch and the 10.0.0 branch.

Those changes including the pom.xmls for maven -- 9.9.0 has version number 9.9.0 whereas 10.0.0 has 10.0.0 defined in the pom.

This pretty much means, there is no way the automatic merge will ever work due to those conflicts.

So, what have I missed? What are the usecases Stash have in mind for this auto merge feature

Was this caused by the PR against a older release branch was created off that branch?

As the PR actually contains the entire branch, not only the changeset, hence the auto-merge fails due to there are indeed changes. If the merge, behaves like cherry-pick, or the PR contains just the patch not the entire branch, this should work.

Oh, btw, we are still on stash v2.10.1. But will update to 3 very soon.

Thanks in adance.

Jason

Adam

It's probably worth us adding an addendum about how we work, but here's the key bit:

When we release a new version of Stash, we manually merge the commit that updates the poms. We do this with the "ours" strategy.

git checkout master
git merge  --strategy=ours 3.2.0

This ensures that the pom.xml changes for 3.2.0 are registered as having been merged up into master already, and having been ignored in that merge. So when real changes come in (like bugfixes), you won't see those pom changes in the diff, and won't see conflicts in the merge.

I'd note that you _do_ want to always merge the whole branch up and not just one changeset. For anything you don't want to actually end up on the "downstream" branches, --strategy=ours is the way to fix it - you explicit mark the change as do-not-merge. Otherwise the differences between them get messier and messier until you don't know which fix is on which branches (Did you intend to not merge that bugfix up, or just forget to do so?). It bleeds into the next person's merge too (as you can tell from the dirty automerges you are getting in Stash).

Hope that helps!