2

For a remote-worker without access to our TFS we cloned a TFS repository using git tfs. When we got back his repository we saw that he worked on a new feature branch.

Before trying to rcheckin his changes, we merged his feature branch into the master branch. Since he didn't commit anything to master, a fast forward took place, resulting in a single stream git log. Unfortunately, since the initial clone another (completely unrelated) checkin happened on TFS. When we try to rcheckin, we get the following error message:

Fetching changes from TFS to minimize possibility of late conflict...
error: New TFS changesets were found.
You may be able to resolve this problem.
- Try to rebase HEAD onto latest TFS checkin and repeat rcheckin or alternatively checkin s

I do not understand how the suggested rebase could help if we need all commits to reflect as checkins on TFS.

Is there any way to get all the git commits as individual TFS checkins in this situation?

paulroho
  • 1,234
  • 1
  • 11
  • 27
  • On a side note, why are you using the git-tfs plugin? Recent versions of TFS come with git support out of the box. Which version of TFS are you using? –  Apr 07 '14 at 20:22
  • @Cupcake Use git-tfs is a real gain over pure TFSVC! And we can use it even if that's not the choice of all the team (sometime) or the company (often). – Philippe Apr 08 '14 at 08:38
  • @Philippe git-tfs is an un-official plugin that is still on [prototype version `0.19.2`](https://github.com/git-tfs/git-tfs/tree/v0.19.2). I haven't used the most recent version of TFS, but I've heard that you can choose to use git with it. If TFS supports using git out-of-the-box, I would not use git-tfs. I've personally run into edge cases with git-tfs where it doesn't always work like you would expect, like not recording certain file merges, additions, and/or deletions...i.e. [***it has known bugs***](https://github.com/git-tfs/git-tfs/issues?sort=comments&state=open). –  Apr 08 '14 at 08:44
  • 2
    @Cupcake Let me laugh! We use git-tfs when we CAN'T use pure git. Giving advice to use pure git is a nonesens! Saying that git-tfs is a protoype because it's version number is just 0.19.2 is a sophism. Git-tf (same tool from Microsoft) is at v2 but is far behind in features and TFS support! Pointing to the issue list of github is also bullshit when it contains pull request, new ideas, old bug not reproduced, help... My team use git-tfs since 2 years without perhaps one problem! Git-tfs perhaps need to support some more horrible cases tfs let you do but that's perhaps the only thing lacking... – Philippe Apr 08 '14 at 09:10
  • @Philippe ok, fair enough. –  Apr 08 '14 at 09:21
  • @Philippe for what it's worth, I actually liked git-tfs. I even wanted to contribute stuff to it. But then I didn't have to use TFS anymore on a new project, so I stopped using git-tfs 1.5-2 years ago and haven't been keeping track of it ever since. –  Apr 08 '14 at 09:39
  • @Cupcake Being away of TFS, you should be an happy user ;) Yeah, moved a lot since 2 years... – Philippe Apr 08 '14 at 12:24
  • @Cupcake It's a customer policy to use TFS with tfs source control. git was just the vehicle to involve the remote worker. With new projects we might discuss using git (on TFS) from the beginning. – paulroho Apr 09 '14 at 08:26

2 Answers2

2

The answer of @Cupcake is good but I want to add some things...

If you want to be nearer than the tfs workflow when just checked in and solve your merge conflicts during this step, you could use:

git tfs rcheckin --quick --autorebase

which is equivalent to :

git tfs pull --rebase
git tfs rcheckin

It's not necessarily the better thing to do because, normally between the pull --rebase (where your changes and the one coming from tfs are 'merged') and the rcheckin (where you push your changes to tfs), you should at least build your solution and also run your unit tests.

But I recognized that sometimes it's a lot easier and my team (all old tfs users) only want to do that!

You should also be aware that's during the pull --rebase step that your changes are 'merged' with the ones of your team so that's where merged are done at the file level and like with tfs when you checked in, you will have to solve conflicts.

In the case of the rcheckin --quick --autorebase, if there is conflicts, the command will exit. You will have to solve them and lauch the command again.

Philippe
  • 28,207
  • 6
  • 54
  • 78
1

You can simply do what the plugin says and rebase the git repo's version of master, which contains the work of the remote-worker, on top of the new changes from TFS. The rebase will preserve the order of the original commits...though if there are conflicts, those will have to be resolved on the commits where the conflicts occur.

git tfs pull --rebase
git tfs rcheckin

You can also just use git tfs fetch and then use git's native rebase tools to do this, but that will involve more steps...the git-tfs command should take care of all of that for you.

Also, just in case, for some reason, the rebase ends up giving you a result that you don't want, put a temporary branch on the tip of master that you can hard reset to, if you need to:

git branch temp master
git tfs pull --rebase

# In case you don't like the rebase results:
git reset --hard temp

# Or if you like the results, check-in
git tfs rcheckin

Documentation for git-tfs pull.

  • Great, it's that easy. My fallacy was that thought I would have to rebase my git repo somehow, not to use the rebase on the `git tfs pull`. – paulroho Apr 09 '14 at 08:22