# how are "untracked working tree files" even possible in this case? 4 messages from 2017-02-15 to 2017-02-15. Participants: G. Sylvie Davies, Stefan Beller. Thread: https://gitlist.dev/t/45148 ## G. Sylvie Davies, 2017-02-15 20:36 Subject: how are "untracked working tree files" even possible in this case? Message-ID: URL: https://gitlist.dev/e/CAAj3zPx6uP5WbA68Co0yX_yh-e5C%2Bjze2T1hJ0NYS7hHBzgdqg%40mail.gmail.com ``` Hi, I have a script that runs the following sequence of commands within a clone: ----- /usr/bin/git rebase --abort (took 148ms) /usr/bin/git cherry-pick --abort (took 103ms) /usr/bin/git clean -d -f -x (took 2007ms) /usr/bin/git reflog expire --expire=now --all (took 106ms) /usr/bin/git reset --hard --quiet 181def85d58597dfb28729029b2ad76b9fbb09f5 -- (took 60103ms) /usr/bin/git merge --squash 333def1a1513f84c1eb79e5341ed6ebca0d359a1 (took 1795ms) Err: '/usr/bin/git merge --squash 333def1a1513f84c1eb79e5341ed6ebca0d359a1' Exit=128 error: The following untracked working tree files would be overwritten by merge: .gitignore [...many more files...] Please move or remove them before you can merge. Aborting ----- I don't understand how untracked working tree files are possible after "git clean -d -f -x" and "git reset --hard" ! I don't have access to this particular repo, but it's around 30GB when cloned (git directory plus working tree), and around 500,000 files in the working tree when checked out. Note: the "reset --hard" takes 60 seconds here. - Sylvie ``` ## G. Sylvie Davies, 2017-02-15 20:38 Subject: Re: how are "untracked working tree files" even possible in this case? Message-ID: URL: https://gitlist.dev/e/CAAj3zPyz8m3nGC_897k9SJOmfqvC2VczxFyphabkDho34nuPUw%40mail.gmail.com In-Reply-To: ``` On Wed, Feb 15, 2017 at 12:36 PM, G. Sylvie Davies wrote: > Hi, > > I have a script that runs the following sequence of commands within a clone: > > ----- > /usr/bin/git rebase --abort (took 148ms) > /usr/bin/git cherry-pick --abort (took 103ms) > /usr/bin/git clean -d -f -x (took 2007ms) > /usr/bin/git reflog expire --expire=now --all (took 106ms) > /usr/bin/git reset --hard --quiet > 181def85d58597dfb28729029b2ad76b9fbb09f5 -- (took 60103ms) > /usr/bin/git merge --squash 333def1a1513f84c1eb79e5341ed6ebca0d359a1 > (took 1795ms) > Err: '/usr/bin/git merge --squash 333def1a1513f84c1eb79e5341ed6ebca0d359a1' > Exit=128 > error: The following untracked working tree files would be overwritten by merge: > .gitignore > > [...many more files...] > > Please move or remove them before you can merge. > Aborting > ----- > > > I don't understand how untracked working tree files are possible after > "git clean -d -f -x" and "git reset --hard" ! > > I don't have access to this particular repo, but it's around 30GB when > cloned (git directory plus working tree), and around 500,000 files in > the working tree when checked out. Note: the "reset --hard" takes 60 > seconds here. > > p.s. environment is: Git-2.7.4 / Bitbucket-4.10.1 / Linux-4.4.0-59-generic (amd64) > > > - Sylvie ``` ## G. Sylvie Davies, 2017-02-15 20:44 Subject: Re: how are "untracked working tree files" even possible in this case? Message-ID: URL: https://gitlist.dev/e/CAAj3zPz7swme%2BfXXyWhhObk8u%2B8TL2A_QLR-uHkMhGzAWUFCow%40mail.gmail.com In-Reply-To: ``` On Wed, Feb 15, 2017 at 12:38 PM, G. Sylvie Davies wrote: > On Wed, Feb 15, 2017 at 12:36 PM, G. Sylvie Davies > wrote: >> Hi, >> >> I have a script that runs the following sequence of commands within a clone: >> >> ----- >> /usr/bin/git rebase --abort (took 148ms) >> /usr/bin/git cherry-pick --abort (took 103ms) >> /usr/bin/git clean -d -f -x (took 2007ms) >> /usr/bin/git reflog expire --expire=now --all (took 106ms) >> /usr/bin/git reset --hard --quiet >> 181def85d58597dfb28729029b2ad76b9fbb09f5 -- (took 60103ms) >> /usr/bin/git merge --squash 333def1a1513f84c1eb79e5341ed6ebca0d359a1 >> (took 1795ms) >> Err: '/usr/bin/git merge --squash 333def1a1513f84c1eb79e5341ed6ebca0d359a1' >> Exit=128 >> error: The following untracked working tree files would be overwritten by merge: >> .gitignore >> >> [...many more files...] >> >> Please move or remove them before you can merge. >> Aborting >> ----- >> >> >> I don't understand how untracked working tree files are possible after >> "git clean -d -f -x" and "git reset --hard" ! >> >> I don't have access to this particular repo, but it's around 30GB when >> cloned (git directory plus working tree), and around 500,000 files in >> the working tree when checked out. Note: the "reset --hard" takes 60 >> seconds here. >> >> > > p.s. environment is: Git-2.7.4 / Bitbucket-4.10.1 / > Linux-4.4.0-59-generic (amd64) > > Also, one of the "untracked files" that shows up is called ".gitmodules". Could submodules be causing this? (I have no experience with submodules). >> >> >> - Sylvie ``` ## Stefan Beller, 2017-02-15 23:40 Subject: Re: how are "untracked working tree files" even possible in this case? Message-ID: URL: https://gitlist.dev/e/CAGZ79kYyzFwqmjO1kZSS0-ARrnk%2BmhooCPrP5oHiff_2piwvzQ%40mail.gmail.com In-Reply-To: ``` On Wed, Feb 15, 2017 at 12:36 PM, G. Sylvie Davies wrote: > Hi, > > I have a script that runs the following sequence of commands within a clone: > > ----- > /usr/bin/git rebase --abort (took 148ms) > /usr/bin/git cherry-pick --abort (took 103ms) Is there more happening before? > /usr/bin/git clean -d -f -x (took 2007ms) > /usr/bin/git reset --hard --quiet I think the order is important: git add # add to the index git clean -dfx # is not untracked, hence not removed git reset --hard # is untracked now? So I would expect reset before running clean would fix the problem? ```