Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am considering implementing the following policy and would like to run it by the community before implementing it:

All mercurial commits must have a bug id corresponding to our bug reporting database.

All commits immediately preceding a push for a new feature must have a bug id (it's a new feature but the id is still a "bug id" in the database)

This will do several things. First, it will ensure that an entry is always put into the bug database for all code changes. Second, it will provide a diff of each change made for each bug fix. This would also simplify commenting in the mercurial commits and put most details about the commit into the bug report.

Do you know of any reasons why this would be a bad idea? Also, do you think I should make some additions to this policy?

share|improve this question
up vote 5 down vote accepted

You definitely do not want to enforce this policy on all commits. One advantage of DVCS is that developers can commit and promote changes to private branches at any time. It's a reasonable policy for commits to production code in the central repository.

share|improve this answer
+1 for pointing out this is only useful on a subset of commits. – Spencer Rathbun Mar 7 '12 at 19:10
I like this. My intention is for this to only be done for the central repository. However, the way we have this setup is everyone is supposed to push their bug fixes and new features to the central repo as soon as they are done. Are you recommending that they have their own branches, then do a merge into a another wc, then commit that merge with the bug id before pushing? – Jonathan Henson Mar 7 '12 at 19:11
@JonathanHenson: Certainly they should work on their own branches, and commit as often as they like. Before pushing, presumably they should merge with current production code and retest. Only now is the change "done", and ready to push. – kevin cline Mar 7 '12 at 20:10
We enforce commits with comment string matching a tracking ID. For private branches, the dev is able to raise a ticket if they want, or use a place holder we have allocated specifically for untracked changes. A push to the master repo rejects the placeholder as well any that do not have a valid ticket. (We use GIT, but the workflow is the same) The idea of the "all commits" is it creates a good habit/no exceptions policy (easy to implement and explain). – mattnz Mar 7 '12 at 23:40
-1 I'm sorry but this is not the case, commits cannot be renamed in mercurial (without a large amount of work), so any commit that will ever be pushed into the main branch should have a case number attached, regardless of whether it's in a "private" branch. If you've got work DVCS workflow correct you don't ever commit directly onto a production repo, you should push to it. – Ed Woodcock Mar 8 '12 at 10:37

We do this where I work (in theory).

It's genuinely really helpful when people do it right, as you can go into the cases in our particular bug-tracker-of-choice and see that you're getting the right changesets for a particular release based on the case IDs of the features you're adding. Your point about keeping the comments on the case is another plus, as in my experience no-one will read your commit messages.

However, it's a pain when people either put the wrong case ID on or just plain don't bother, so I'd say if you're going to do it make sure you have a staging repo where you're able to change the case ID before you push it into your trunk, and add a policy to the remote end to reject changesets without a case ID on them.

share|improve this answer
  1. Documenting all changes in form of tickets is, in common, good style
  2. Direct links ticket-changesets is good


  1. Some changeset may be indirectly related to issue (1-st CS - changes for ticket, 2-nd+ - fixes for CS 1)
  2. Flat history with only commit-messages doesn't provide nice interface for filtering from VCS-side
  3. Branch-per-feature workflow hide side-effects of 1 and 2 and make marking all changesets obsolete even from issue-tracker side - referenced maybe only first and last commit
share|improve this answer
What then would you recommend as modification of the policy? – Jonathan Henson Mar 7 '12 at 19:22
@JonathanHenson - as usual, "it depends"... From habits, team culture, workflow, even used VCS and client-tools. For flat history in one my project I use ticket-id relation in commit-messages (where it applicable), in another I have 2 separate branches for different tasks and branch-name only is enough for orientation. Right choice is your personal headache as PM, colleague – Lazy Badger Mar 7 '12 at 19:44

People do not look in bug databases to see code diffs for bugs. They look in version control. Therefore, it makes sense to require a bug id for the last commit that fixes a bug, so you can make a note in the bug tracker and identify what build bug fixes are in, but every single commit is overkill.

If people are committing features you don't want, you have a whole other problem, and probably need some sort of gatekeeper workflow. I'd highly recommend you look into more integrated solutions like kiln or bitbucket.

share|improve this answer
I agree, the idea is for devs to be able to look in the VC for diffs and see the entire history for the bug in the issue tracking if they need to know what the commit was for--not the other way around. Also, while a team is looking at a bug in the tracker that has been marked as resolved, another dev, or project admin could look and easily find the changes for the bug fix. – Jonathan Henson Mar 7 '12 at 19:21
Lots of people look in bug databases for code diffs. It's the reason that every non-distributed VCS has some form of this feature, whether baked in or added on. – Ross Patterson Mar 8 '12 at 12:21

The more obstacles you put in the way of me committing, the less often I'll commit. That really defeats the point of a DVCS.

You're really trying to solve a symptom with this approach rather than trying to fix the root cause. You have a team of developers who:

  • Don't understand the value of the bug tracker;
  • Don't seem to communicate very well, and repeat work that other developers have already done;
  • Veer off-task and write code that hasn't been discussed and hasn't been authorised.

You could enforce this policy. However, if the developers are already dysfunctional, what is this policy really going to achieve? Is it suddenly going to give you a focused, communicative team who maintain an excellent set of bug reports?

No. It will give you an awful lot of bug fixes checked in against the wrong bug report.

You need to address the issues in your team by managing them. Show them how they are stepping on each other's toes. Hold daily standup meetings so that Bob can tell the team that he's fixing bug X so that Dave won't start work on the same thing. Explain the value of the bug tracker. If your developers come to see that what you're trying to achieve is a good thing they'll do it automatically.

share|improve this answer
But, suppose I didn't want people committing code that isn't a bug fix or a feature we talked about adding. I am growing tired of miscellaneous "new features" being added because someone thought it would be good that then causes a bug. If they don't push, they can do what the hell they want with the code. If someone wants to add a new feature, the team as a whole needs to be consulted--especially the architect. – Jonathan Henson Mar 7 '12 at 18:08
Suppose I'm fixing bug 12345 and spot another bug. I can either a) take 15 minutes out to commit what I'm doing, open the bug tracker, create a new bug report, fix the bug, commit and go back to bug 12345, b) commit to bug 12345, commit a fix for the other bug and not log it, and go back to bug 12345, c) fix the bug silently and commit when 12345 is fixed, or d) ignore the bug. You want me to do a. I want to do b. If I'm forced to commit I'll do c or d. Breaking the commit process isn't a good way to fix a broken bug tracking process. You'll have two broken processes and an unhappy team. – Ant Mar 7 '12 at 18:53
@JonathanHenson - managing and using issue-tracker is another story (of weak management) – Lazy Badger Mar 7 '12 at 19:00
@Ant - nobody interested in that you want. You get money for job, which you must to do according to defined rules*. Setup your rules at own home, not at work – Lazy Badger Mar 7 '12 at 19:04
@Jonathan: Help, help, I'm being oppressed! – Ant Mar 8 '12 at 18:29

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.