Re: how are "untracked working tree files" even possible in this case?
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?
Re: how are "untracked working tree files" even possible in this case?
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
Re: how are "untracked working tree files" even possible in this case?
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
