Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

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.

1 answer

1 accepted

4 votes
Answer accepted
Ivan Maduro Atlassian Team Feb 05, 2013

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.

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.

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 Atlassian Team Feb 06, 2013

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.

Was any fix for this ever developed?

Suggest an answer

Log in or Sign up to answer
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you