Re: [WIP v2 5/5] mv: use update_sparsity() after touching sparse contents

From: Victoria Dye <vdye@github.com>
Date: May 27, 2022, 21:24 UTC
Message-ID: <d0ac1bea-6d98-140c-0e46-d7569e80b29d@github.com>
In-Reply-To: <xmqq8rqm3fxa.fsf@gitster.g>

Junio C Hamano wrote:

Show 15 quoted lines

> Victoria Dye <vdye@github.com> writes:
> 
>> Note that you'll also probably need to check out the file(s) (if moving into
>> the cone) or remove them from disk (if moving out of cone). If you don't,
>> files moved into cone will appear "deleted" on-disk, and files moved
>> out-of-cone that still appear on disk will have 'SKIP_WORKTREE'
>> automatically disabled (see [1]).
> 
> Does it also imply that we should forbid "git mv" of a dirty path
> out of the cone?  Or is that too draconian and it suffices to tweak
> the rule slightly to "remove from the worktree when moving a clean
> path out of cone", perhaps?  When a dirty path is moved out of cone,
> we would trigger the "SKIP_WORKTREE automatically disabled" behaviour
> and that would be a good thing, I imagine?
>

I like the idea of the modified rule as an option since it *does* complete the move in accordance with '--force', but doesn't result in silently lost information.

An alternative might be 'mv' refusing to move a modified file out-of-cone (despite '--force'), printing something like 'WARNING_SPARSE_NOT_UPTODATE_FILE' ("Path 'x' not uptodate; will not remove from working tree").

I'm not sure which would provide a more vs. less frustrating experience, but both are at least safe in terms of preserving unstaged changes.