Will Stash automatic merge ever work?

[jason wang]

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!

[jason wang]

Adam, thanks for the timely response. You answer makes perfect sense! But I got some follow-up quetsions that need your help:

1. I actually do NOT want to always merge the whole branch, I would prefer just to merge the changeset. I assumed the PR flow forced you to do it -- looks like I am wrong. How do I make sure only the changeset is merged automatically into the newer release branches?

2. How do you guys deal with long lasting feature branches? Say, a major feature that would last a couple of weeks. Merging back can be a pain in the bum. I am considering automate the merge from the remote-tracking branch (I guess for the branching model Stash uses, all feature branches will be off master) for every single commit. That means your feature branch will be always up to date and the merge back to mater will be FF only. Can you please share your view on this?

3. Assuming you have a few release branches already, say, 3.1 and 3.2, master is on 3.3-snapshot. If you just introduced git and stash now, and you want the bugfixes to 3.0 automatically flow into 3.1,3.2 and master, can you safely do a git merge --strategy into 3.1 and 3.2 NOW? If not, whats the way out?

Many thanks,

Jason

[jason wang]

Sorry, @Adam, I dont know if I am supposed to continuing the discussion by asking those followup questions. Should I start a new thread? Whats the best way to get some answers? Support channel? Many thanks, Jason

[jason wang]

test a comment