Git clone stops if changeset is rename

If a tfs checkin contains a deletion or rename of a directory (= is a rename checkin) the clone operation stopps at that changeset and doesn’t fetch newer changesets. Only workaround is to use the quick-clone command.

I think I identified the code that causes that bug but I am not sure, if there is some purpose behind this block. The following return causes the code to not fetch any newer commits than the one with the rename:

GitTfsRemote.cs Line 361

if (changeset.IsRenameChangeset && !isFirstCommitInRepository)
{
    if (renameResult == null || !renameResult.IsProcessingRenameChangeset)
    {
        fetchResult.IsProcessingRenameChangeset = true;
        fetchResult.LastParentCommitBeforeRename = MaxCommitHash;
        return fetchResult;
    }

    renameResult.IsProcessingRenameChangeset = false;
    renameResult.LastParentCommitBeforeRename = null;
}

Version used: current master branch Reproduction: Clone a repository with a changeset that contains a rename checkin. Command: clone (fetch should be affected too but I didn’t tested that) Output: see attachment CloneDebugOutput.txt

[lafe]

We have the same issue. In our case, the commit in question was an extensive change in the project architecture and we basically moved everything. The ChangeType value of the changes in the changeset all have a value that starts with 2000 and the root folder with git-Path “” has the value 2080. This causes the method RenameBranchCommmit of the ChangeSieve class to return true, because the value 2080 encodes the delete flag:

0000 1000 0010 0000     Value stored in changeset (2080; 0x0820)
0000 0000 0001 0000     Rename (0x0010)
0000 0000 0010 0000     Delete (0x0020)
0000 1000 0000 0000     SourceRename (0x0800)

As you can see, the other flag is set for SourceRename which is mentioned in Microsoft’s documentation of the ChangeType but is not yet included in the ChangeType enumeration of git tfs. The value 0x800 has been determined by looking into the Microsoft.TeamFoundation.VersionControl.Client assembly using dotPeek.

I temporarily modified the code of the RenameBranchCommmit class to this:

public bool RenameBranchCommmit
        {
            get
            {
                if (!_renameBranchCommmit.HasValue)
                {
                    _renameBranchCommmit = NamedChanges.Any(c =>
                        c.Change.Item.ItemType == TfsItemType.Folder
                            && c.GitPath == string.Empty
                            && c.Change.ChangeType.IncludesOneOf(TfsChangeType.Delete, TfsChangeType.Rename)
                            && !c.Change.ChangeType.IncludesOneOf(TfsChangeType.SourceRename));
                }
                return _renameBranchCommmit.Value;
            }
        }

(I also added SourceRename to the TfsChangeTypeEnum)

With this change, I was able to check out everything, however the changes performed in this problematic commit are not applied (so in our case, we have new and old code folders in the same directory).

I performed the analysis with the current master branch. The aforementioned pull request did not resolve the issue.

[MrBigDog2U]

We have encountered this same (or at least a related) issue. In our case, we moved several folders between TFS folders but made no other changes to the files. Git tfs clone did not pick up the folders that got moved into the new area.