Re: git: 848263aad129 - main - cp: fix some cases with infinite recursion

On Thu, Jan 27, 2022 at 12:02 PM Kyle Evans <kevans@freebsd.org> wrote:
>
> The branch main has been updated by kevans:
>
> URL: https://cgit.FreeBSD.org/src/commit/?id=848263aad129c8f9de75b58a5ab9a010611b75ac
>
> commit 848263aad129c8f9de75b58a5ab9a010611b75ac
> Author:     Kyle Evans <kevans@FreeBSD.org>
> AuthorDate: 2022-01-27 18:02:17 +0000
> Commit:     Kyle Evans <kevans@FreeBSD.org>
> CommitDate: 2022-01-27 18:02:17 +0000
>
>     cp: fix some cases with infinite recursion
>
>     As noted in the PR, cp -R has some surprising behavior.  Typically, when
>     you `cp -R foo bar` where both foo and bar exist, foo is cleanly copied
>     to foo/bar.  When you `cp -R foo foo` (where foo clearly exists), cp(1)
>     goes a little off the rails as it creates foo/foo, then discovers that
>     and creates foo/foo/foo, so on and so forth, until it eventually fails.
>
>     POSIX doesn't seem to disallow this behavior, but it isn't very useful.
>     GNU cp(1) will detect the recursion and squash it, but emit a message in
>     the process that it has done so.
>
>     This change seemingly follows the GNU behavior, but it currently doesn't
>     warn about the situation -- the author feels that the final product is
>     about what one might expect from doing this and thus, doesn't need a
>     warning.  The author doesn't feel strongly about this.
>
>     PR:             235438
>     Reviewed by:    bapt
>     Sponsored by:   Klara, Inc.
>     Differential Revision:  https://reviews.freebsd.org/D33944
>

Thinking about this some more, I think it's still wrong but less wrong
than it was before. Specifically, I think:

- `cp -R foo foo` -> now does the right thing, we copy foo/* into
foo/foo but we don't end up with a foo/foo/foo
- `cp -R foo foo/subdir` -> is still wrong, if foo/subdir/x existed
then we should end up with foo/subdir/foo/subdir/x but not
foo/subdir/foo/subdir/foo

I'm going to leave it since it's less bad than before (infinite
recursion), but I intend to iterate on it once more...

thanks,

Kyle Evans