On initial clone of git repository SourceTree shows pending files. Pending files are impossible to discard

Using SourceTree on Mac I just cloned a repository to a Samba mounted Linux drive.  Immediately SourceTree showed a file as having pending changes.  SourceTree isn't suggesting these are EOL changes, but actual edits introducing additional code.  I attempted to discard the file, but it simply never disappeared from showing as pending in SourceTree.

On the Linux machine, git from the shell showed a different git status.  'git status' showed the file SourceTree thinks had a few minor changes as having been 'deleted'.  git status also showed several other files as having 'typechange'.  Performing a 'git reset --hard' within Linux reset it so that 'git status' reports back "Your branch is up-to-date... nothing to commit, working directory clean".

However, back in SourceTree things have now gotten worse.  Now SourceTree is reporting the original report of a changed file, plus a tonne of files as being untracked, some deleted and a few more as also having changed.

I deleted the entire repository and did a fresh clone and SourceTree ended up right back where I started - incorrectly reporting the status of the repository.

3 answers

When I've seen behavior like this, it's because there have been files present in the source repo whose names differed only by case (i.e. foo.bar and FOO.BAR exist in the same directory).  By default, Macs will not allow file names to differ only by case (and this behavior is also standard on Windows computers).  Therefore when the clone operation occurs, only one or the other of the files will get copied onto the Mac.  But git knows that both files are supposed to be there.  It may show one as deleted or it may show that the contents of one have changed (to the other).

The best solution is to not have files whose names differ only by case in your repo.  This will give you the best compatibility  when people clone to workstations.  It's also possible to put your Mac into a mode where it will allow files that differ only by case (the same way linux will) - you can google for that, I don't know the steps off the top of my head but I know it can be done.  But then you'd still have this issue if you had a developer clone onto a Windows PC, so I think it's best to just fix the filenames on your remote repo.  You'll have to use a unix workstation that you can clone the repo to in order to fix the names.  

This is all assuming that I'm right about the source of your problem - but I bet I am.

Windows machines also have restrictions on files ending in a period or with certain special non alphanumeric characters in them, by the way, so it's best to avoid these also for maximum workstation compatibility. 

I should add that two other repositories on the same Samba shared drive don't exhibit this problem.  It seems particular to this one repository.

Suggest an answer

Log in or Sign up to answer
Atlassian Community Anniversary

Happy Anniversary, Atlassian Community!

This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.

Read more
Community showcase
Brian Ganninger
Published Jan 23, 2018 in Sourcetree

Tip from the team: workflow and keyboard shortcuts

Supported Platforms macOS Sourcetree has a lot to offer and, like many developer tools, finding and using it all can be a challenge, especially for a new user. Everyone might not love ...

647 views 0 4
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you