Project

General

Profile

Change Repository URL without losing manual-added commit-issue references

Added by Vito Marolda almost 11 years ago

Hello,

When someone in the team forgets to mention "IssueID #xxx" in the commit text, we manually add the link between the commit and the issue directly from Redmine, opening the "commit" page, and clicking "Add" in the "Related Issues" section.

Now, I am trying to migrate the git repository from a path to another, but doing "delete" and then "add" (with the same repository name and a different path) loses all the links between the commits and the issues that were made clicking "Add" in the commit's page in Redmine.

Am I doing something wrong?


Replies (3)

RE: Change Repository URL without losing manual-added commit-issue references - Added by Konstantin Tkachenko over 9 years ago

We have the same issue, but with subversion.

Our solution till now was: not only to add relation between commit and redmine issue, but also to modify the svn commit so that the next time it would be connected automatically.
We also about to implement an appropriate hook in svn to prevent commits from succeeding, if they do not contain a reference to the issue in redmine (without checking the existence of the issue - only the message format).

With git it could be a bit harder to modify commits, but I'm not so experienced in git to be sure about it. In the mercurial (hg) it would be near to impossible to modify commits afterwards or to implement push-hooks (depending on the usage).

At the end you probably have to write a program/script to save the relations to the "bad" commits and restore them after repository migration.
For us it was not worthwhile to implement such a script to be able to keep all of the relations.

RE: Change Repository URL without losing manual-added commit-issue references - Added by Anton Wiedermann about 9 years ago

It's not only about manually created references but also about references which were created in the past with another matching pattern (we changed it to be more restrictive and prevent another teams from linking their commits to our issues... More info here

    (1-3/3)