Working copy changes issue

[Cristi Boariu]

In my git repository opened with SourceTree I see a lot (maybe all the files I have in the project) appearing in Working Copy Changes ares.

If I select any of these I can see on right side that there are only diffs regarding whitespaces. The issue is how I can discard all these "changes"? Ctrl+a to select all and pressing Discard still keeps them there...

[stevestreeting · Accepted solution]

Is this on Windows? If so what is the 'core.autocrlf' setting in your core .gitconfig?

For best management of line ending on windows, this should be set to 'true'. SourceTree defaults to setting that for you in the setup wizard, unless you uncheck the box to automatically handle line endings.

[Cristi Boariu]

Yes, I am on Windows and I have this in my git.config:

1 2 3 4

[apply] whitespace = nowarn [core] autocrlf = true

Sometimes "discarding" of these files works after a few tries, sometimes not.

[stevestreeting]

My best guess is that the files in question were committed by someone who had autocrlf=false, which means they ended up in the repo with extra CRs in them. The autcrlf option (and the equivalent .gitattributes settings) is a transform and works great, but only so long as it's applied consistently, once there's a mismatch in the repo you can only fix it by re-committing the files affected with the correct setting. So re-committing these files would probably fix it.

[Deleted user]

Sorry to re-open this thread, but I also have this exact issue and haven't been able to resolve it. It may well be a result of previously using the repository or someone making commits with the wrong autocrlf. My problem is that I can't re-commit the files to fix it.

All files in the repository are listed in the Working Copy Changes with green ticks, but I can't stage any of them (it does nothing), and I can't discard them (the option is greyed out). How do I remove these files from the list of Working Copy Changes? My command-line git behaves correctly and doesn't list any of these files when running git status.

Both my global .gitconfig and the one in the repository now has autocrlf=true. I've tried removing the repository and re-adding. I've tried both system git and embedded git. I've tried re-starting SourceTree. What action can I take to remove all the green-ticked files from the Working Copy Changes?

Thanks!

[JamesB]

I had the file in the "staging" area with green checks next to them. Tried all the advice here. Then I restarted SourceTree and they went away and I could complete the merge properly.

Hope that helps.

[Andreas L]

I have the same behavior, and to me it looks like a bug in SourceTree.

Right now I have the following setup.

This scenario works:

• I have one file changed,still not on stage.
• If I run "git status",I have one modified file no and no changes added to commit
• If I press Commit button in SourceTree, I get the change file listen in Working Copy Changes
• If I press "double arrow up" (stage all) in the Commit window, this single file is moved.to stage
• If I then commit, this single file is committed.

this scenario does not work:

But, under File Status and Log / History, the list "Working Copy Changes" is populated with a lot of incorrect files marked as unmodified. The one file that is actually changed is also present in the list but marked as "unmodified" instead of changed. I think that it may be ALL the tracked files in my repo (not the files in gitignore)

• I have one file changed,still not on stage.
• The list Working Copy Changes is populated with all files in my repo marked as "unmodified".
• The list Staged Changes is empty
• If I press Stage All here,no visual updates are done. All files remains in the lower box "Working Copy Changes". But the single file is actually moved to stage (verified with "git status" on command line).
• If I now press "double arrow down" (that miss quick tip text),the single file is NOT removed from stage.
• The list Working Copy Changes is still populated with all files in my repo, all marked as "unmodified".
  
  

SourceTree just got very hard to work with.

I have tried to remove my local repo entirely, remove the bookmark in SourceTree and clone the repo again, but the error persists..

[Deleted user]

@James: Unfortunately it doesn't work for me.

We have files (mostly build and configuration files) being tracked by git. More than one 100 of the show the green tick and a 'Clean' tooltip if you hover over them. There is no way to get rid of them beside using 'Stop tracking' and commiting them in SourceTree.

However... It's completely misleading because in the git command line (wheter I use the one from source tree or the one for github) shows no files when I run 'git status'. We have a team here that started with git only a couple weeks ago and they are VERY confused seeing these files.

[James Sullivan]

I was helping someone with this issue before and found that the answer is simple but unintuitive.

Git is keeping track of a file in your repo called .git/index which holds the status of your files. That file also keeps track of if file conversions happened to those files for autocrlf. If you already cloned and checked out your repo before you set your autocrlf setting, then it will show warnings for crlf>lf conversion and give you those unmodified files lines.

The way around it is to delete that .git/index file and manually run a git reset command to let git figure things out again.

[Cristi Boariu]

Steve,

Yes, I am on Windows and I have this in my git.config:

[apply]
	whitespace = nowarn
[core]
	autocrlf = true

Sometimes "discarding" of these files works after a few tries, sometimes not.