threads / discuss / 45148

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

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

## tl;dr

4 messages between Feb 15, 2017 and Feb 15, 2017.

replies: 3people: 2as markdown or json

G. Sylvie Davies· Feb 15, 2017, 20:36 UTC · lore

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· Feb 15, 2017, 20:38 UTC · re: G. Sylvie Davies · lore

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

On Wed, Feb 15, 2017 at 12:36 PM, G. Sylvie Davies <sylvie@bit-booster.com> wrote:

Show 34 quoted lines

> 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· Feb 15, 2017, 20:44 UTC · re: G. Sylvie Davies · lore

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

On Wed, Feb 15, 2017 at 12:38 PM, G. Sylvie Davies <sylvie@bit-booster.com> wrote:

Show 41 quoted lines

> On Wed, Feb 15, 2017 at 12:36 PM, G. Sylvie Davies
> <sylvie@bit-booster.com> 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· Feb 15, 2017, 23:40 UTC · re: G. Sylvie Davies · lore

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

On Wed, Feb 15, 2017 at 12:36 PM, G. Sylvie Davies <sylvie@bit-booster.com> wrote:

Show 7 quoted lines

> 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 <file> # add to the index
    git clean -dfx # <file> is not untracked, hence not removed
    git reset --hard # <file> is untracked now?

So I would expect reset before running clean would fix the problem?