We use TFS 2010 at work, and I use git-tfs so I can use git locally. I've recently upgraded my machine, and copied all my local repository folders across.
I seem to be able to pull from TFS and commit locally. However when I do git tfs rcheckin, I now get the error:
TF26198: The work item does not exist, or you do not have permission to access it.
It does however work when using git tfs checkintool.
I presumed that I was getting this error because the original git tfs clone was done on another computer. Reading the git-tfs docs, it sounds like I should be doing a git clone from my old machine (rather than copy), then a git tfs bootstrap. However, when trying this, I still get the same error.
Any ideas what could be causing this? The only other difference I can think of is that my old machine has VS2010 and VS2012 installed, whereas my new machine has just VS2012 installed.
git-tfs parses your commit comments to provide work item associations with your changesets. By default, if you enter #1234, then the git-tfs checkin and rcheckin commands will attempt to associate work item 1234 with the checkin.
If you are using #1234 in your commit messages in order to associate these with a different bug tracking system, this is obviously in conflict. In this particular case, git-tfs cannot find the TFS work item and is providing you with this message.
As of recently, you can provide a configuration value:
git-tfs.work-item-regex
in order to override the #1234 behavior. While there is no way to disable this functionality, you can set it to something you would be unlikely to conflict with. For example:
git-tfs.work-item-regex=TFS WORK ITEM:(?<item_id>\d+)
I presumed that I was getting this error because the original git tfs clone was done on another computer. Reading the git-tfs docs, it sounds like I should be doing a git clone from my old machine (rather than copy), then a git tfs bootstrap. However, when trying this, I still get the same error.
It will change nothing because it's a problem when git-tfs interact with TFS...
Any ideas what could be causing this? The only other difference I can think of is that my old machine has VS2010 and VS2012 installed, whereas my new machine has just VS2012 installed.
Update: See the other answer by @ethomson which is indeed the good answer...
