3

When using Subversion, JIRA, and fisheye, it's easy enough to edit a log message to fix the JIRA number. With git, not so much. Once a commit is pushed to a shared repo, modifying the commit is fraught.

Is there some other mechanism in these products to allow for fixing the links between commits and JIRAs if someone typos and pushes?

bmargulies
  • 97,814
  • 39
  • 186
  • 310
  • In my experience, fisheye does not cope well with rewritten history, which git can do just fine. My team works around it by pushing to `wip/PROJECT-123` (where wip stands for work in progress and is a free-for-all) and then when changes are ready for Crucible review, we push to `topic/PROJECT-123`. Sometimes we need mulligans on `topic/blah-blah`, so we might use a name of the form `topic/PROJECT-123-take2`. – Greg Bacon Mar 01 '13 at 17:54
  • I'n not quite following. You're using the branch names as the fundamental tracking? As for rewriting, well, I can't shake the YouTube of Hitler talking about cherry-picking, I'm a coward. – bmargulies Mar 01 '13 at 18:14

1 Answers1

1

One mechanism is to use hooks to prevent pushes with typos.

A pre-commit hook on your local repo can check the pattern fits (but doesn't check remote jira so you keep offline capability). This prevents developers committing without a properly formed jira reference.

A pre-receive or update hook on the server does a more complete check (like ensuring all commits have a jira reference that is valid / open / assigned to them).

This isn't bulletproof but it should be good enough.

Gavin
  • 1,223
  • 15
  • 20