Re: [PATCHv2 4/5] unpack-trees: factor file removal out of check_updates

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 10, 2017, 21:34 UTC
Message-ID: <xmqq37gqr43w.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kbXVCvZuj6rTckGwOfFtRSFpx9p611oKfFLAayTgB242Q@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 12 quoted lines

> As far as I understand the operations now, a working tree operation
> is done like this:
>
> * First compute the new index, how the world would look like
>   (don't touch a thing in the working tree, it is like a complete
>   dry run, that just checks for potential loss of data, e.g.
>   untracked files, merge conflicts etc)
> * remove all files to be marked for deletion
> * add and update all files that are new or change content.
>
> check_updates does the last two things listed here, which in the
> grand scheme of things looked odd to me.

In the grand scheme of things, the flow has always been understood more like this two-step process:

    - compute the result in core (rejecting an inconsistent result
      before touching the working tree)

    - reflect the result to the working tree

and the latter is done by check_updates().

Removing gone entries before instanciating possibly new entries is done in order to make room where we can create a new path D/F in the result, after removing an old path D [*1*]. But it is merely an implementation detail of the latter, i.e. "reflect the result to the working tree.

It is arguably true that check_updates() is not about "checking" but is about "doing", hence is misnamed.

[Footnote]

*1* If the result computed in-core wants to create D/F, it must have removal of D---otherwise the result is inconsistent.