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

From: Stefan Beller <sbeller@google.com>
Date: Feb 15, 2017, 23:40 UTC
Message-ID: <CAGZ79kYyzFwqmjO1kZSS0-ARrnk+mhooCPrP5oHiff_2piwvzQ@mail.gmail.com>
In-Reply-To: <CAAj3zPx6uP5WbA68Co0yX_yh-e5C+jze2T1hJ0NYS7hHBzgdqg@mail.gmail.com>

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?