Which commit to add issue/bug tracking ticket # to

Question

I have been committing changes in git for a project over the last several months. I would like to start integrating Trac into my workflow. Generally, I have the 'git flow' style of git repository. I maintain a master and develop, and I branch features and bug-fixes from the develop branch.

I see from answers in Which commit should close a Github issue when multiple commits are responsible? that I want to link the "merge commit" to the ticket.

Since I already have several features in the git repository, I'd like to go "back in time" to associate them with a ticket that was entered in Trac.

At this point, I have two choices:

1. Re-write history. I can use git rebase --interactive --preserve-merges. Then add the ticket information to the message.

2. Use git notes add <rev> to add a note.

I am looking for opinions on which is the better option. 1. allows me to be more in keeping with defacto-standards, while 2. allows me to keep ticket management separate from the code repository.

I have complete control over the repository, Trac server etc. Solo developer, no pushes (other than to a "backup", but I can rebuild that from the local)

Answer 1

All of them. If a commit is relevant for the fix of issues X and Y, and another for Y and Z, they should both be marked as such. Why would you want to "artificially" reduce the number of commits to 1? If Trac doesn't support that, I'd say it's most definitely a bug (or "missing obvious feature").

Regarding the second part, do it the pragmatic way: Which option is best supported by the tools you use (or want to use), taking into account that any changes to the history will lead to extra work for those who want to update their repo.