When I tried to a commit today, I got a message that said my files were over 10 meg??
Asked by john simpson:

I knew there was no way that my files could be that large. I searched and searched to try and find what is causing the commit to be so big. Well, I found it. It's in the .git folder in the Objects folder. It's about 17 meg. Is there anything I can do to fix this? I don't want to keep fighting this from here on out.

Thanks for any help.


Answers:
author: Tim Crall
body: I don't think that's it. Nothing in the .git folder should be part of your commit. There is almost certainly another file or files causing this.

Can you go to the command line and do a "git status" and look for all the files it says you've added and check the size of each of them?

If you've caught this before committing, you're lucky, because it's harder to cleanup after committing.

comments: author: john simpson
body: Hi again Tim, It's nice to be talking to you. The way I found out that my files were small and that the .git folders were so big, was I used the properties(right clicking on a folder). On my source code, there's it's not too big at all. but when I right clicked on the .git folder, it showed that it was 17 meg.

So.... the actual question that I have is how do you do the "git status" thing. I tried it at the command line and the OS didn't know what I was talking about (lol). I looked in source tree to see if I could do it there, but didn't see a way I could do it.

Hope you are doing great!

john


author: Tim Crall
body: Are you on a Windows machine?

Either way, the easiest way to get to a git command line, if you're used to SourceTree, is probably to click the "Terminal" button in the toolbar. That should open you up to a terminal window, using Git Bash if you're on a PC, in the correct directory.

From there you should be able to type "git status" and get a list of files that git thinks you've added, deleted, and modified since the last commit.

The .git folder is where git keeps all of its own files, including the compressed files of all the previous versions of your repo, etc. Nothing in the .git folder is being added to version control when you do a commit.


author: john simpson
body: Hi Tim. Yes, I'm on a windows pc. I tried to reply earlier, but the icon thing just kept spinning and never stopped so I couldn't write back. I did the "status" command in the terminal window and here's what I got...

On branch Getting_souce_back

Changes not staged for commit:

(use "git add/rm \<file\>..." to update what will be committed)

(use "git checkout -- \<file\>..." to discard changes in working directory)

modified: .vs/Snotes/v14/.suo

modified: Snotes/Priokat.vbproj

modified: Snotes/Utility.vb

modified: Snotes/bin/Debug/My Secret Life.exe

modified: Snotes/bin/Debug/My Secret Life.pdb

deleted: Snotes/bin/Debug/bak/Snotes.exe

deleted: Snotes/bin/Debug/bak/Snotes.exe.config

deleted: Snotes/bin/Debug/bak/Snotes.pdb

deleted: Snotes/bin/Debug/bak/Snotes.vshost.exe.config

deleted: Snotes/bin/Debug/bak/Snotes.vshost.exe.manifest

deleted: Snotes/bin/Debug/bak/Snotes.xml

modified: Snotes/frmEmail.vb

modified: Snotes/frmEnterPwd.vb

modified: Snotes/frmMain.vb

modified: Snotes/frmNew.Designer.vb

modified: Snotes/frmNew.resx

modified: Snotes/frmNew.vb

modified: Snotes/frmOpen.vb

modified: Snotes/frmOpenpass.vb

deleted: Snotes/frmUtilities - Copy.vb

modified: Snotes/frmUtilities.Designer.vb

modified: Snotes/frmUtilities.vb

modified: Snotes/myEncryption.vb

modified: Snotes/obj/x86/Debug/DesignTimeResolveAssemblyReferences.cache

modified: Snotes/obj/x86/Debug/DesignTimeResolveAssemblyReferencesInput.cache

modified: Snotes/obj/x86/Debug/My Secret Life.exe

modified: Snotes/obj/x86/Debug/My Secret Life.pdb

modified: Snotes/obj/x86/Debug/Priokat.vbproj.FileListAbsolute.txt

modified: Snotes/obj/x86/Debug/Priokat.vbproj.GenerateResource.Cache

modified: Snotes/obj/x86/Debug/TempPE/My Project.Resources.Designer.vb.dll

modified: Snotes/obj/x86/Debug/TempPE/Resources.Resource1.Designer.vb.dll

deleted: Snotes/obj/x86/Debug/sNotes.frmUtilities.resources

deleted: codecanyon-4592971-metro-icon-generator.zip

Untracked files:

(use "git add \<file\>..." to include in what will be committed)

.vs/config/

Snotes/Folder.vbs

Snotes/UnHideFolder.vbs

Snotes/bin/Debug/HideFiles.vbs

Snotes/bin/Debug/UnHideFolder.vbs

Snotes/bin/Debug/UnhideFiles.vbs

Snotes/bin/Debug/email.png

Snotes/bin/Debug/hideFolder.vbs

Snotes/frmUtilities - Copy.vb.bak

Snotes/frmUtility/

Snotes/hideFolder.vbs

no changes added to commit (use "git add" and/or "git commit -a")

I'm not really sure what this means, but you should be able to tell that it shouldn't be as big as they say it was... and it's not :smile:

So..I would appreciate some help on this issue. How can I resolve this? You know more than I do for sure.

as always, thanks a bunch


author: Tim Crall
body: So I see a lot of files there that you definitely (in my opinion) shouldn't be including in your commit, such as the \*.exe and \*.dll files. Make sure that when you're on the SourceTree commit screen, you're not staging those files. Probably you should have a .gitignore file to ignore \*.exe, \*.dll, and other file types which you're not intending to track in source control.

Beyond that, if you can post a screenshot of the SourceTree message you're getting and the state of the commit window when you get it, that might be helpful.


author: john simpson
body: Ok. I've already looked at the files I could omit. I certainly don't want an exe or dll in there. I will to come up with other things as well. I will try and work on it again today and let you know how it works out.

I really appreciate your help.


author: Tim Crall
body: Ok, so, as I look at this list again, the fact that it shows those binary files (exe's and dll's) as modified means that they were at one point added to your repo. And once they're in there, they're in there - even if you remove them from the repo moving forward, they are still part of the repo because they are present in past commits, unless you use some plumbing commands to rip them out from the past commits. This is a powerful reason why large binary files should never be added to repos in the first place.  

The easiest way to remove them altogether is probably BFG, see this link: <https://confluence.atlassian.com/bitbucket/reduce-repository-size-321848262.html>

[](https://confluence.atlassian.com/bitbucket/reduce-repository-size-321848262.html)Once you've removed them, you should absolutely create a .gitignore to ignore them in the future. You can also do this within SourceTree.

What are you using as your remote repository? Bitbucket or something else?  

<br />


author: john simpson
body: Ok... I'm losing my mind.. I tried doing a commit this morning just so I could make you a screen shot and everything worked like a charm. No compliments at all. So I apologize for taking up your time. I didn't have that in mind.

However, since I already have your attention, how do I do a "ignore" file or command. After I understand that, I'll leave you alone \<g\>


author: Tim Crall
body: You can find a lot of references online for this, but the quick basics are: you can create a file called .gitignore in your repo and add either filenames or patterns (\*.exe) as separate lines. Git will ignore UNTRACKED files that match the name. Untracked means a file that has not previously been added to the repo. Basically all "ignore" means is that Git/SourceTree will stop reporting the presence of the untracked file.

Within SourceTree it's even easier, you can just right-click on an untracked file and select 'Ignore'. It will then let you choose whether to ignore just that file or all files with that extension and also whether to ignore those files just in this repo or in all repos (global ignore).  

Ignore is appropriate for use with log files, binary build result files, IDE configuration files, etc - anything that is present in the working directory but shouldn't be considered part of source control.

Typically the .gitignroe file itself is added to the repo so that all collaborators will ignore the same file.s