On Sat, May 28, 2022 at 5:24 AM Victoria Dye <vdye@xxxxxxxxxx> wrote:
>
> Junio C Hamano wrote:
> > Victoria Dye <vdye@xxxxxxxxxx> 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.
For me, the alternative provides a less frustrating experience.
Since it is more explicit (giving a message and directly saying NO).
Also, the `sparse-checkout` users should expect the moved file to be
missing in the working tree, as opposed to being present.
And the tweaked rule suggested by Junio [1] might need an extra
`git sparse-checkout reapply` to re-sparsify the file that moved out-of-cone
after staging its change?
[1] https://lore.kernel.org/git/xmqq8rqm3fxa.fsf@gitster.g/
--
Thanks & Regards,
Shaoxuan
