5

When git tfs could not create a merge commit, it says warning: this changeset 7504 is a merge changeset. But it can't have been managed accordingly because one of the parent changeset 7494 is not present in the repository! If you want to do it, fetch the branch containing this changeset before retrying...

As per the documentation, Note: if you see a warning, you could correct that by reseting the tfs remote to a previous commit. Then fetch the merged branch and retry to fetch the branch.

Can anyone please elaborate on reseting the tfs remote to a previous commit. Though, I've now fetched the merged branch, I don't understand how do I reset it to previous commit to the failed one. I'm not sure but do I have to git checkout <hash of the previous commit>?

IsmailS
  • 10,797
  • 21
  • 82
  • 134

1 Answers1

3

Yes, now git-tfs try to create merge commit when it encounter merge changesets (now that it has a satisfying branch support).

This message is just a warning message and when you see it, you have 2 options...

  • The first one is to do nothing because you know that it was, for exemple, an old feature branch that you will never work on that and MORE IMPORTANT that in the future you will never merge again in your parent branch.

  • The second one is if you really want to have this merge commit. Because you want a good history or MORE IMPORTANT because you still work on this branch and will have to merge it in the parent branch.

To do that, you will have to reset your tfs remote (because in fact the commit has already been created --to keep compatibility with how git-tfs works in previous version and for those that can't work with branches--).

To reset your remote, you must use reset-remote command.

Then intitialized the branch that is merged in the parent branch with branch --init.

Reset also the local branch to the tfs remote (due to an internal git-tfs optimization).

And fetch again the parent branch. Now that the merged branch exist and is fetch, git-tfs will find the parent changeset from the merged branch and you will have a beautiful merge commit in your git repository ;)

So, If you did this earlier

git tfs clone https://CompanyName.visualstudio.com/DefaultCollection "$/CompanyName/Main" KfGitMain --workspace="C:\TFS\Main"
cd GitMain
git tfs branch --init "$/CompanyName/Release/20140121.1" live20140121.1
git tfs branch --init "$/CompanyName/Release/20140121.1-hotfix" hotfix20140121.1

and if you received the warning for all the three due to code merges to and from each other, so you will have to

git checkout hotfix
git tfs reset-remote 5fb83335b8dfc6fbb96e0a54a48dc06c506e3277 ## previous commit of the first failed commit
git reset --hard tfs/hotfix
git tfs pull -i hotfix

git checkout live
git tfs reset-remote eba62a1446f3f81676d051336ca254fe54c37d74
git reset --hard tfs/live
git tfs pull -i live

git checkout master
git tfs reset-remote 72727737ec52f9b96d22d343770186a342c8b166
git reset --hard tfs/default
git tfs pull -i default

Note: if you don't have too many branches and/or strange tfs history, all that could be avoided using git clone with the option --with-branches that will init and fetch all the branches taking care of the merge changesets

Philippe
  • 28,207
  • 6
  • 54
  • 78
  • I've added the commands I used based on my understanding of your answer. Please correct if anything is wrong. – IsmailS Apr 07 '14 at 12:19
  • That's all good. Just updated to save one command (use pull instead of fetch + reset) and added a not to tell to use `git clone --with-branches` to avoid such cases... – Philippe Apr 08 '14 at 08:04
  • FYI, if you have v0.19.2, you can use option `-I` instead of `-i nameOfMyRemote` in all the git-tfs commands and it will choose the good remote to use.... – Philippe Apr 08 '14 at 08:13
  • Okies. Thanks. When are you merging your rename_branch to the main branch? I hit a scenario where renaming of files was handled properly by the rename_branch code but not with the master branch code of the original repo. – IsmailS Apr 09 '14 at 06:37
  • I want to release a new version of git-tfs before merging this branch because perhaps it will change how git-tfs works. And I need to work on that again to correct some things. But for the moment I work on another project :( I have to find motivation and time to work on that again... – Philippe Apr 09 '14 at 08:50
  • Can I ignore this warning message if it's due to a collaborator's feature branch (in TFS) and not from me? In other words, do I need to worry about whether *he* will work on that branch or merge it again? – redcurry Apr 14 '15 at 15:53
  • You could ignore the message except if you want an history **exactly** the same as the TFS one... – Philippe Apr 14 '15 at 20:37