On Fri, Jun 17, 2022 at 12:42 AM Victoria Dye <vdye@xxxxxxxxxx> wrote:
*Truncated messages*
> > 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.
> >
>
> Good point, since the sparseness of the destination file would be different
> depending on whether it had local modifications or not (with no indication
> from 'mv' of the different treatment).
>
> If you're interested, maybe there's a middle-ground option? Suppose you want
> to move a file 'file1' to an out-of-cone location:
>
> 1. If 'file1' is clean, regardless of use of '--force', move the file & make
> it sparse.
> 2. If 'file1' is *not* clean and '--force' is *not* used, refuse to move the
> file (with a "Path 'file1' not uptodate; will not move. Use '--force' to
> override." type of error).
> 3. If 'file1' is *not* clean and '--force' is used, move the file but do not
> make it sparse.
>
> That way, '--force' really does force the move to happen, but users are
> generally warned against it. I'm still not sure what the "right" approach
> is, but to your point I think it should err on the side of not surprising
> the user.
I generally think this middle-ground option is good. Though I think the sort
of options that "messing with sparse contents" should be handled by
'--sparse', instead
of '--force', since the latter is used to "force move/rename even if
target exists".
Mixing the usage may cause syntax confusion?
> > 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?
> >
>
> Just so I understand correctly, do you mean 'git sparse-checkout reapply'
> *as part of* the 'mv' operation? Or are you thinking that a user might want
> to manually run 'git sparse-checkout reapply' after running 'mv'?
>
> If it's the former (internally calling 'git sparse-checkout reapply' in
> 'mv'), then no, you wouldn't want to do that. In Junio's suggestion, he said
> (emphasis mine):
>
> > 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?*
>
> We don't want the file moved out-of-cone to be sparse again because it has
> local (on-disk) modifications that would disappear (since a file needs to be
> removed from disk to be "sparse" in the eyes of 'sparse-checkout'). It's
> *completely valid* behavior to have an out-of-cone file become non-sparse if
> a user does something to cause that; it doesn't cause any bugs/corruption
> with the repo. And, even if you did want to make the file sparse, it should
> be done by manually setting 'SKIP_WORKTREE' and individually removing the
> file from disk (for all the reasons I mentioned in my upthread comment [1]).
>
> On the other hand, if you're talking about a user manually running 'git
> sparse-checkout reapply' after the fact, that wouldn't work either - they'd
> get an error:
> warning: The following paths are not up to date and were left despite sparse patterns:
> <out-of-cone modified file>
This is what I meant, a user manually running `git sparse-checkout reapply`.
Though I did say users should only do this "after staging its change".
I propose this solution which sounds good to me:
1. If 'file1' is clean, iff with the use of '--sparse', move the file & make
it sparse.
2. If 'file1' is dirty, iff with the use of '--sparse', move the file
& *do not* make
it sparse, instead advise something like
"file1 is not up to date, keep it non-sparse.
Stage file1 then run `git sparse-checkout reapply` to re-sparsify it."
> [1] https://lore.kernel.org/git/077a0579-903e-32ad-029c-48572d471c84@xxxxxxxxxx/
>
> > [1] https://lore.kernel.org/git/xmqq8rqm3fxa.fsf@gitster.g/
> >
--
Thanks & Regards,
Shaoxuan
