# Bug Report - Segmentation Fault on "git add --all" 2 messages from 2017-07-20 to 2017-07-20. Participants: Tillson Galloway, Martin Ågren. Thread: https://gitlist.dev/t/46425 ## Tillson Galloway, 2017-07-20 00:54 Subject: Bug Report - Segmentation Fault on "git add --all" Message-ID: URL: https://gitlist.dev/e/CAO1QjAFGnK%2BriGT_ZffM_-%3DymJm08U8adOfHV4wrhR9LJLhSAA%40mail.gmail.com ``` Context: We currently have a git project with a root directory ("~/project") for pipelines and deployment of a Node app, and then a subdirectory ("~/project/project-app"). After realizing that we didn't need the node app in a subdirectory, we moved the full app into the root directory (using the mv command). The Problem: Our node_modules folder is being tracked by git (173MB) and was moved into the root directory along with the other files. After moving the files, I ran "git add --all" in order to track the new files. Rather than the expected output of the (albeit very long) list of files, I was presented with a segmentation fault error. [1] 90837 segmentation fault git add --all Attempting to run other git commands (commit, add) now responds with: fatal: Unable to create '/Users/tillson/project/.git/index.lock': File exists. Running "git status" shows that git successfully tracked that the original files within ~/project/project-app were deleted, but it did not pick up the "newly created" files from moving. Removing .git/index.lock (an empty file) allows for me to run "git commit" but no changes are recorded ("no changes added to commit"). Running "git add --all" again causes a seg fault and repeats the cycle. I would assume that the cause of the seg fault was that node_modules held too much data for git to be able to handle in one go. I'm not sure if this is considered a (likely at this point known) bug or if it's just a caveat of using git. I am admittedly not an expert with git, so if there is anything useful (logs, config files, etc.) I can supply to help fix this, I'd be happy to. Thanks, Tillson Galloway ``` ## Martin Ågren, 2017-07-20 05:01 Subject: Re: Bug Report - Segmentation Fault on "git add --all" Message-ID: URL: https://gitlist.dev/e/CAN0heSrzdfpH%3DocQrC3SYLNF2K%3DagdKuRdscSPnnCgBMWhPRxg%40mail.gmail.com In-Reply-To: ``` On 20 July 2017 at 02:54, Tillson Galloway wrote: > Context: > We currently have a git project with a root directory ("~/project") > for pipelines and deployment of a Node app, and then a subdirectory > ("~/project/project-app"). > After realizing that we didn't need the node app in a subdirectory, we > moved the full app into the root directory (using the mv command). > [...] > > Running "git status" shows that git successfully tracked that the > original files within ~/project/project-app were deleted, but it did > not pick up the "newly created" files from moving. So you did "mv project-app/* ." and see something like Changes not staged for commit: (use "git add/rm ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) deleted: ... lots of files ... ? That means Git has *realized* that the files are gone, but it's not *tracking* that fact (yet). What if you restore the files and instead try "git mv project-app/* ."? It will move the files like "mv", but it will also do basically what you wanted to achieve with "git add --all". After that, you'll just have to "git commit". You'll probably want to "rmdir project-app/" once it's empty. If you have some structure like project-app/project-app/ the move might fail (should be possible to work around). This obviously doesn't address the problem you saw and on which I cannot comment, but I hope it helps you do what you actually wanted to do. :) Martin ```