Smart Commits: apply only for specific branches?

[Inxmail Administrators]

We use Fisheye and Jira with smart commits to transition issues, and we use git. Our workflow uses feature branches and git rebasing, and this causes a problem:

when a feature branch is rebased on master, and then pushed to the remote repository that is watched by fisheye, then the smart commit commands are applied again, even though the same commits have already been pushed to the master branch, and the commands were executed.

Is there any way to ensure that a smart commit command is only executed once? My preferred idea to achieve that is to configure the branches in which smart commits are active, but I'm open for other approaches as well.

[jhinch (Atlassian)]

Hi,

Have you considered merging instead of rebasing? This will both fix your problem and have your repository better represent the structure of how the development was actually done (i.e. in parrallel with an integration/merge step).

Rebasing actually rewrites history destroying the old commits and creating new ones. These are no longer the same commits so quite rightly new commit events are triggered for them and your smart commits will be retriggered.

That said you could manage to achieve what you are asking for by creating your own smart commit plugin which filters commits which aren't on a particular branch and delegate to handlers based on that but you cannot do it out of the box with the current smart commit plugins available.

The quickest and best win I would suggest though is to merge instead of rebase.

[Mike Jansen]

Have you considered merging instead of rebasing? This will both fix your problem and have your repository better represent the structure of how the development was actually done (i.e. in parrallel with an integration/merge step).

But this won't better represent the structure of how the development was actually done if your workflow includes rebasing from master throughout your feature development to keep up with new changes and minimize problems when merging longer-running feature branches back into master.

I know rebases are considered by many to be bad practice, but that is only the case for certain workflows. Rebasing a feature branch on master is a perfectly acceptable usage of rebase, especially if that's the published workflow for your development. And the only history that gets re-written is the feature branch's history, so it's not like you're changing the source history of anything that has been released.

Now a legitimate reason to hesitate doing this request is that identifying rebase commits, while fairly straight-forward for a straight-forward no-squash, no-conflict rebase would be, um, fairly straight-forward, handling the exceptions might get a bit tricky. Having said that, it would be interesting to poll who uses rebases as part of a standard workflow where it makes sense and see if there's enough interest to make it worth investigating.

BTW, I landed here searching for a solution to JIRA re-showing my commits when I rebase my feature branches on master and push the branch up to BitBucket. I think rebase identification would be a valuable tool to have, but a reliable one may require some changes in git to help out, perhaps a commit note listing the original commit hash or some other pointer.