Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,463,448
Community Members
 
Community Events
176
Community Groups

"Uncommitted changes" yet nothing is pending

This happens from time to time for reasons I don't understand. I'll make some changes, commit all the changed files and push, but when it's done, it will still say "uncommitted changes" at the top, but there are NO pending files that need to be committed. Why does this happen (only about 1% of the time) and how do I get rid of it (or should I just ignore it, since the next time I make changes, it will actually be relevant)

3 answers

1 accepted

0 votes
Answer accepted
KieranA Rising Star Feb 26, 2013

This can happen for a number of reasons as we've seen in the past. The main culprits are

  1. You have many, many unstaged files in your working directory that get listed in SourceTree. This causes Git/Hg to take quite some time going through all the files, and so SourceTree waits on Git/Hg to report back.
  2. Your system specifications aren't quite up to scratch. Really you need about 20GB free disk space, and some decent memory backing you up.

SourceTree gets told to update the status of the working directory after a commit, so if it takes some time it's due to Git/Hg taking time to respond, and this usually happens for the reasons above. Take a look and see if either of those are causing a problem, if not feel free to ask more questions.

Thanks for the feedback--I'm not sure either of these two would be the culprit. I have a new MBP with 8GB ram and 150GB free disk space. Also, the repo I've been working on has been fine until now--I commit/push at regular intervals so there's never a ton of new files. I just did a commit to the dev branch and merged with QA and production, and I still have that empty "uncommitted changes" thing at the top. It's not really hindering me, I guess, but it IS annoying.

KieranA Rising Star Feb 26, 2013

When you select 'uncommitted changes' does it show anything at all? This sounds like Git/Hg being slow rather than SourceTree. One other option is to hit Cmd+R and see if it vanishes, it could be a timing issue with SourceTree.

KieranA Rising Star Feb 26, 2013

Ah ha, this is a temporary file created by hg to determine details of your file system. If the file doesn't get deleted then it's probably because something like a file scanner or something else was holding a lock on the file at the time hg was running so it fails to delete it. Could you try and run "hg debugfsinfo"? This *may* delete that file as it should re-create/delete the temp file. You should add this to your ignore list too, just everything below .hgcheck will do it. This issue should've been fixed in Hg 1.9, what version are you using? (Embedded or system, etc.)

Cmd+R didn't affect anything. So actually I went to the command line and did a "hg status" and got this:

? .hgcheck/hg-checkexec-Vsrwpy

So it looks like some mercurial-specific file has changed but doesn't show up on sourcetree?

did "hg debugfsinfo" and it did not get rid of the file.

Also, I'm using the system version of mercurial, 2.4.2

But I just set the ignore rule so hopefully that solves it =/

KieranA Rising Star Feb 26, 2013

It's Mercurial's responsibility to delete that file. If for some reason it didn't get deleted then it's either a bug in Mercurial, or that temp file is being locked at the point Mercurial is trying to delete it. It's no problem if it exists though, Mercurial does all kinds of things like this to regulate the proper feedback to the user. It should be fine now, the temp file (if it stays in your file system) will just be deleted/re-created when hg does its business.

I'm having the same problem and using both the embedded mercurial 1.9 and the latest one on my box didn't help. Moreover I've done everything listed previously in the comments above; hg status doesn't return anything in either the main or sub-repo. Is there something else that I'm missing? One thing that's interesting, this only happens when I set rebase to happen right after a pull.

I had similar problem. MercurialExclude extension was causing it, and some other problems, like not seeing some commits.

Thanks!  Had this problem in V2.0.3. Modifying my ignore list solved it. (You should add this to your ignore list too, just everything below .hgcheck will do it.)

if it is added to ignore list and in future it is modified, will it be listed in the uncommitted files?

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events