Unable to pull - uncommitted changes in working folder

Sep 6, 2012 at 7:25 PM

The command "git tf pull --rebase" is aborted with the error "the file has uncommitted changes in the working folder". The file mentioned does not have any local modifications. The file was changed and committed locally but not checked-in to TFS yet.

d:\dev\MyProject>git reset --hard
HEAD is now at 79d3120 refactoring

d:\dev\MyProject>git status
# On branch master
nothing to commit (working directory clean)

d:\dev\MyProject>git tf pull --rebase
Connecting to TFS...
jgit : Obtaining commits that need to be cherry-picked
jgit : Rewinding to commit Part Calculation - Updated Unit/Fit tests.
jgit : Applying warmup website batch file attempt
jgit : Applying change local port for MyProject.Core to 999
jgit : Aborting rebase: resetting to 79d31209bfb112365dd605bfc39cc8d80641d315
jgit : Resetting head to refs/heads/master
Fetching and merging changes in $/MyProject/Trunk at latest changeset: 100%, done.
All files were fetched to commit 4023254. The rebase operation was aborted with the following failures:
Config/default.config : the file has uncommitted changes in the working folder

d:\dev\MyProject>git status
# On branch master
# Unmerged paths:
#   (use "git reset HEAD ..." to unstage)
#   (use "git add/rm ..." as appropriate to mark resolution)
#       both modified:      Config/bob_white.config
#       both modified:      Config/default.config
#       both modified:      Config/qual.config
#       both modified:      FitTests/Passing/file1.xml
#       deleted by them:    FitTests/Passing/file2.xml
#       both modified:      Source/App/MyProject.Application/Domain/Car.cs
#       both modified:      Source/App/MyProject.Application/Domain/Invoice.cs
#       both modified:      Source/App/MyProject.Application/Domain/InvoiceApprover.cs
#       both modified:      Source/App/MyProject.Application/Domain/Part.cs
#       both modified:      Source/App/MyProject.Application/Domain/PartCalculator.cs
... more files excluded for brevity

Sep 6, 2012 at 7:29 PM

I'm not sure I understand your question...

It sounds like you - at some point - pulled from TFS to give you some git commit.  Then you made some changes locally, resulting in git commit 79d3120.  Then you did a git tf pull --rebase, which downloaded the latest changeset as 4023254...  Is this accurate?

Sep 6, 2012 at 8:16 PM


Correct. Yesterday I started working on a new feature in an existing git repo. At that time, the latest local commit was be8a1f from TFS. Then I did:

- made local changes
- git commit
- made local changes, in particular modified our source file: Config/default.config 
- git commit
- made local changes 
- git commit (this is commit 79d3120)
- get tf pull --rebase

I didn't pay attention to the output. I started working and noticed problems. It looked like there were dozens of conflicts which was unusual. I tried git reset --merge, then ran the commands in my first post to demonstrate the problem. Commit 4023254 is a TFS changeset that was downloaded with the last pull. It appears on a different branch at the moment.

Sep 6, 2012 at 8:42 PM

Noticed another strange behaviour: modified files on a freshly cloned repository. I was trying to reproduce the above issue on a new repository. I am using the 20120827 git tf version.

d:\dev>git tf clone http://myserver:8080 $/TRPS/Trunk d:\dev\git-test-shallow
Connecting to TFS...
Cloning $/TRPS/Trunk into D:\dev\git-test-shallow: 100%, done.
Cloned changeset 76798 as f80ac7a

d:\dev>cd git-test-shallow

d:\dev\git-test-shallow>git status
# On branch master
# Changes not staged for commit:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#       modified:   file1
#       modified:   file2
#       modified:   file3
no changes added to commit (use "git add" and/or "git commit -a")

git status

Sep 6, 2012 at 8:48 PM

I think both issues are related here. The problem is that the download operation (happening on clone and on fetch) is leaving 3 files uncommitted. This was reported previously here : http://gittf.codeplex.com/workitem/2 ... When pull --rebase is executed, a fetch is performed which downloads files into commits (due the issue/bug above) fetch_head will not have a clean working directory, thus when the rebase is executed you are seeing the dirty working tree issue.

Can you please provide us with more information regarding file1, file2 and file3 ? Are their encoding different than git default encoding, are their line ending different than git default line endings ?  Can you try running git fsck to see if there are any dangling objects ? Can you also try committing and finding what the difference is ?

Sep 6, 2012 at 9:20 PM

Thanks. I had autocrl=true. Differences were line endings. Does that explain both issues?

I will use a patch to move my changing into a fresh clone.

Sep 6, 2012 at 9:27 PM

If you have core.autocrlf = false and do a new clone, do you still see the uncommitted files ?

Sep 6, 2012 at 9:45 PM

Correct. A fresh clone with core.autocrlf = false and there are no uncommitted files. Thanks.

At the moment, I am trying to move my work to the fresh repo using patches.

Sep 6, 2012 at 9:47 PM

Yes this should be the issue affecting both .. this is exactly the same as issue http://gittf.codeplex.com/workitem/2 . We should address this issue soon, sorry for the inconvenience and thanks for working through this issue.

Sep 7, 2012 at 4:47 PM

All working again. Thanks.