When merging from forked repositories, git commit messages are imported multiple times. How do I deal with this?

[Prateek Malhotra]

So based on this article, my team and I have started using forked repositories and pull requests to work on our application.

We have one main repository, this has our "master" branch and a "staging" branch. The staging branch is used when new pull requests are merged in, and once we have completed a working sprint within JIRA/GreenHopper, we test staging and merge it into master as our new version of the application. Each developer has their own fork of this main repository, and each of their repositories keeps its master branch tracking the main repository's staging branch. We branch off the master branch on our forked repositories for each new task we work on in JIRA.

This works great. Code is completely reviewed and tested and we can muck around in our local forks without worry of affecting the main repository.

However, we have JIRA linked to all of the repositories, and as such, git commit messages are repeated in said JIRA tasks many, many times. I think this is because JIRA adds the message for every merge and copy of the message in each of the forks. This is becoming troublesome since it will also add to the time logged and make looking through a tasks commit history confusing.

What's the best way to deal with this? I could stop tracking the fork's with JIRA, but then how will we keep updates on the tasks through commit messages (we'd have to login and log our work, add comments, etc, manually) and even then, when we merge into the main repository (which JIRA would still be tracking), the commit messages will add to the time again.

We want to be able to view progress on our tasks no matter what repository it originates from, but we don't want these duplications all over the place.

[Ivan Maduro · Accepted solution]

Hi Prateek,

This behaviour is an unfortunate limitation of the current version of the DVCS connector. JIRA treats each forked Repository as a new repo and thus processes all commit messages again. Our developers are aware of this, but until a fix is made there are two workarounds.

• - Disable Smart commits in either the Master Repo or in the Fork Repo.

You can set JIRA to not enable Smart Commits in new Repos, this will make sure that any forked Repo is not processed. But this is not useful if you want to track any changes made in your forks, in which case you can disable Smart Commits in your Master Repo. However, this will still process smart commits if you create new forks frequently.

• - Use Git built in branches, rather than Bitbuckets Forks.

Gits branches are properly handled by JIRA, JIRA will not process smart commits multiple times in Branches created in git with the Git Branch command. JIRA will display an icon for all commits made within Branches and you can still use Bitbuckets Pull requests to merge branches into your Master branch.

Lastly, which isn't really a workaround, is to disable smart commits alltogether and have users log their time manually in JIRA.

[Prateek Malhotra]

Well we do not fork new repos, its just done once per developer. Does the method in which we merge remote branches affect the way git messages are imported into JIRA? That is, if I upload a fix in my forked repository, do a pull request into the main repository, and then the other devs merge the fix from the main repostiory into their respective forked repos, will JIRA import said git commit message from every single repo or just once from my repo? It certainly feels like this happens, but not everytime (might be due to the way I merge in changes).

Switching to built in branches and sharing one repository seems like a possible solution, but I like the built-in saftey of code review and allowing only the lead developer write access to the main repository to ensure every line of code is reviewed before making it live. If we all share a repository, it can become burdensome if one person were to accidentally commit changes on branches they shouldn't be committing to and reverting those changes or branching the changes off.

[Ivan Maduro]

If smart commits are on in the Branches any merged change will indeed re-process for each person who owns a fork. Our developers are looking into fixing this soon so hopefully I can give a positive answer soon.

[TJ Baker]

Was any fix for this ever developed?