git-tfs: [v0.19] Reporting a case where a branch couldn't have been initialized during a `clone --with-branches`

You are here because you’ve got at least one branch that has not been initialized during a clone --branch=all (or in the past clone --with-branches).

Work have been done and merged to support as much merge cases as possible.

But it seems there is still cases not well managed.

One that seems not managed is the case where a branch that should be merged has been deleted and another one created with the same name.

At the moment, there is no plan to work on that for multiple reason.

What you could try:

download and try the last development version of master branch in case a fix has not yet been released. (you even could test some pull requests to see if someone proposed a fix)
If you think you can improve the support of such cases (you are the one that has the tfs history with such case!), feel free to dive in the code and do a pull request. We will be happy to review and merge it…
clone without branch support ( I know it’s not what you want 😦 but there is no solution yet) with clone --branch=none

About this issue

Original URL
State: closed
Created 11 years ago
Reactions: 3
Comments: 112 (39 by maintainers)

Most upvoted comments

@nk111 Is your patched version of git-tfs by any change available ? I think I have a similar issue on a repository with ~20 years of history. I would love to try your version on that repo and see what happens.

tibor-at-shell on Jan 11, 2022

Saw this error message - not sure what to do next reading the comments above

...
C504968 = e70bf32d3c65169d1211a97c2bf19451706872ee
=> Working on TFS branch : $/GF/Projects/GFSBS/Dev/BRZ_Cellular
Branches to Initialize successively :
-$/GF/Projects/GFSBS/Dev/BRZ_Cellular (489311)
The name of the local branch will be : Projects/GFSBS/Dev/BRZ_Cellular
        Fetching from dependent TFS remote 'Projects/GFSBS/Dev/CellularMerge'...
error: an error occurs when initializing the branch. Branch is ignored and continuing...
=> Working on TFS branch : $/GF/Projects/GFSBS/Release/GFSBS/V10.50_CLP
C500414 = 6004776be2ee7f0b516067ff9272b6afd937b8b5
C500416 = 3bc5fbe9fd4197daa38824b1b8262386ee9cc1a5
C500427 = 44f94c25e827bf052c7a4da6b621c1ad39441ad3
C501807 = d97f81a6bd025450a6aef43855f96da15ee42637
C501814 = 970f5acfe1091c429c335d1bc1a9c7f825815945
C501991 = a9480dceef1ccc8c137accbdff176555d09b9166
C502225 = d87a4f86855d2de53fba7d727aae8520d88e792f
C502335 = 3d68f325aceacb01f6adcc7d707ededa57facb58
C502338 = fa727ecca32d1f3db3792aa73a3611a1c5c1f629
=> Working on TFS branch : $/GF/Projects/GFSBS/Main
warning: Some Tfs branches could not have been initialized:
- $/GF/Projects/GFSBS/Dev/BRZ_Cellular

Please report this case to the git-tfs developers! (report here : https://github.com/git-tfs/git-tfs/issues/461 )
warning: Some Tfs branches could not have been initialized or entirely fetched due to errors:
- $/GF/Projects/GFSBS/Dev/BRZ_Cellular
   =>error:error: Couldn't fetch parent branch


Please report this case to the git-tfs developers! (report here : https://github.com/git-tfs/git-tfs/issues )

C:\P\git\GS>

Is there some kind of diagnostic message I can provide?

dgtlrift on Aug 17, 2017

Hi @nk111 just repeating @tibor-at-shell asked previously. Did you make your patched version of the code available anywhere?

digimangos on Oct 3, 2022

I was hit by the special case mentioned in post 1 of this thread.

“One that seems not managed is the case where a branch that should be merged has been deleted and another one created with the same name.”

We started with just a MAIN branch, then introduced a DEV branch, renamed DEV into INT a little later and finally branched a new DEV from INT.

When you do this, you’ll notice that TFS lists all changesets on the former DEV branch (renamed to INT) before the rename step still under the NEW DEV branch. So the branch renamed to INT starts with the rename changeset in history.

In this scenario git-tfs fails to parse the history tree. I know there is code in place that should track renames but it seems to fail here.

After like 4 days (and nights) of debugging and patching git-tfs i just completed the cloning of our 20 year old tfs repo without errors. My strategy was to actually ignore the rename but instead clone all the changes from the “old” DEV branch to the INT branch already. So basically if git-tfs searches for a change on INT before the rename from DEV to INT i replace /Int with /Dev in the search path. Of course this needed some magic here and there in the whole process. I have to test this with to other repos with a similar rename and re-use use case and will report back if it proved to work.

nk111 on Mar 15, 2021