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:
Re-write history. I can use
git rebase --interactive --preserve-merges
. Then add the ticket information to the message.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)