Stefan Beller <sbeller@xxxxxxxxxx> writes:
> 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.