I have two projects "project-A" and "project-B". The issues are being reported in "project-A" but the actual development is going on in "project-B".
Referring "project-A" in every commit comment is challenging. I am exploring for a better option to link the issues of "project-A" to be linked to "project-B" code commits. A simple ask is if the developer commits with a comment "#23 fixed" in 'project-B', it should be visible in 'project-A's relevant issue comment history.
1. Transforming git commit messages:
From your workspace
$ cd myrepo
$ vi .git/hooks/commit-msg
Note that this is a client side hook. Now add the following content to it
#!/bin/sh
projecta_issues_link="https:\/\/github.com\/git\/git\/issues\/"
message=`cat $1 | sed "s/projecta/${projecta_issues_link}/g"`
echo ${message} > $1
exit 0
Then make a change to any file, and commit it with the following message:
git commit -m "This fixes projecta#1234"
Your commit message should be transformed to a link now.
2. Applying the client side hook on all repositories:
There's a really well-written answer to that here.
You can link to a commit or issue in a different repository by writing out its full GitHub URL. GitHub will shorten it appropriately when displaying it.
This works throughout the GitHub UI, including commit messages.
When the project began we setup repo project-A and it was communicated to client.
But later due to some issues we had to create another repo project-B and after sometime we realized client was using project-A repo for logging issues.
We don't want to ask client to change the repo
Thant means project-A can reference project-B as a submodule.
Not for the project-B sources, but for the ability to record the state of project-B main SHA1 as a commit in project-A repo.
And the comment of that commit (in the parent repo project-A) can be made automatically the one of the last commit of project-B.
So if a developer makes a new commit "Fix#123" in project-B, project-A can then automatically record a new commit, with the latest of project-B (tracking a branch: git submodule update --remote), with as a comment the comment of the last commit of project-B: "Fix#123".
No, both of them are completely different repositories but within the same organization
Seems only way to do this, is create a github bot or tweak around existing CI's such as travis, and close issue on other respository, if they are closed in commits of your current one.
I am not aware of any means for cross-referencing projects to reflect commits in the manner you are describing:
link the issues of "project-A" to be linked to "project-B" code commits.
I will state the obvious:
Even though perforce is not git, I have found the "perforce best practices" paper to be the best description of how to maintain release and development branch sanity. Go directly to page 4 and begin reading there.
As you fix bugs in your customer facing "project-A", which is maintained on a release branch, merge those changes to master as described in the reference document.
I am far less in favor of "git flow" but I might as well mention it.
Bottom line: You cannot get there from here. There is not a solution to your problem within the scope of any source control I have ever used to the best of my knowledge (subversion, ClearCase, perforce, git).
Since your customer facing project-A has priority (based on my reading of other comments) you will want to bring project-B into project-A's repo.
This will constitute its own challenge, and based on that, using git-flow might suit your needs as you would be bring project-B in as the develop branch.
The difficulty of doing so is dependent on:
However, the sooner you tackle the problem, the sooner to eliminate a major pain point for your team.
You can commit issue address directly.
git commit -m "This fixes https://github.com/auser/projecta/issues/1234"
