Git Repo / TFS Discrepancy Resolution

[Dan Rigby]

I have a local git repository I've been using git-tfs with. I've noticed that somewhere in the middle of a large number of change sets pulled from TFS, there is now a file that exists in TFS that doesn't exist in git. 

git tfs verify also shows this missing file.

How do I force my local git repo to be back in sync with TFS?

If I try to add the file to git and commit it, my next push to TFS fails with an error indicating that there should have been 1 change, but none were found.

Thanks,

-Dan

[Matt Burke]

If you rebase the commit so that it's an ancestor of tfs/default, then
git-tfs will ignore it.

I'm curious why git-tfs missed the file. Is there anything special
about it? Like, is it a branch of another file? Or was it ignored
during `git tfs clone`? I assume the file was added once in TFS, and
not ever edited? Was there anything unusual about how the file got
added to TFS? Any information you can dig up would be great!

> --
> You received this message because you are subscribed to the Google Groups
> "git-tfs-dev" group.
> To post to this group, send email to git-t...@googlegroups.com.
> To unsubscribe from this group, send email to
> git-tfs-dev...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/git-tfs-dev?hl=en.

[Dan Rigby]

Matt,

The file as added as part of a pull of several change sets, it wasn't present in the initial clone.

The only "interesting" thing about this file & it's history is that it was renamed in TFS at one point.

Specifically the action listed for the change set (1137) is "rename, source rename" and then the change set can be expanded in TFS (I'm guessing this means it's a parent to another change set) which reveals two children the first of which (1136) has an action of "add" and then 1137 which has an action of "delete, source rename".

Here's a screenshot:

In git, I can see 1136 and 1137. 1136's changes are all present and correct (the new file, LeaderboardViewView.xaml.cs, is added), but in 1137, the git change set deletes both LeaderboardView.xaml.cs and LeaderboardViewView.xaml.cs instead of deleting the first and renaming the latter.

I'm going to see if I can create a simple repro case, but if I had to guess, it's the combination of delete and rename in one commit that is causing the problem.

Thanks,

-Dan

[Dan Rigby]

Matt,

You indicate that I can rebase the commit so that it's an ancestor of tfs/default, how would I go about doing that? 

tfs/default is a remote tracking branch and not a local branch, so I don't know how to modify it.

Thanks,

-Dan

[Matt Burke]

I would use this sparingly, because, like any of the git history rewriting stuff, you can pretty easily get into a really painful situation if you're not really careful about it.

Also, while I've done all of these things individually, I haven't done them all together on a repo that I'm using with git-tfs, so hopefully this doesn't screw up your repo.

The goal of the rebase is to take the commit that fixes up your repo, and make it an ancestor of tfs/default so that git-tfs doesn't notice it. git-tfs wants tfs/default to have the git-tfs-id in it, but it doesn't look past it.

To do the rebase, you'll want to start with a branch that is tfs/default plus the commit that fixes it up. Then `git rebase -i HEAD~~` (interactive rebase, starting two commits ago), swap the two "pick" lines, save+exit. Now, `git update-ref refs/remotes/tfs/default HEAD` to make the rebase result the new TFS head.

As an alternative, you could add the 'git-tfs-id:' line from your tfs/default to the fixup commit, and `git update-ref` that into 'refs/remotes/tfs/default'.

[Matt Burke]

Dan,

Interesting. I don't understand what that tree is showing... why it has 4 different change types, apparently for the same item?

Anyway, could you debug through a fetch and see what `_changeset.Changes` looks like for changeset 1137 at https://github.com/git-tfs/git-tfs/blob/master/GitTfs/Core/TfsChangeset.cs#L32 ? You may have to dive into Changes to find the original object that TFS returned, to get the actual ChangeType (the TfsChangeType is just git-tfs's translation of it).

On Sat, Jan 5, 2013 at 12:30 AM, Dan Rigby <d...@danrigby.com> wrote:

[Dan Rigby]

Matt,

Specifically what happened was in 1136, a new file was added: LeaderboardViewView.xaml.cs. At this point there was a LeaderboardView.xaml.cs and  LeaderboardViewView.xaml.cs.

In 1137, LeaderboardView.xaml.cs was deleted and LeaderboardViewView.xaml.cs was renamed to LeaderboardView.xaml.cs.

The change types seem to make sense given this order of events.

Thanks,

-Dan

[Dan Rigby]

Matt,

The funny thing is, I'm trying to replicate the actions the developer appears to have taken in TFS, and TFS won't let me rename a file to the same name as a file deleted in the same commit.

I have no clue how this happened in source control.

Thanks

-Dan