how are "untracked working tree files" even possible in this case?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]