Re: [PATCH 5/6] t7063: use POSIX find(1) syntax
- From
Danh Doan <congdanhqx@gmail.com>
- Date
- Mar 22, 2020, 00:37 UTC
- Message-ID
- <20200322003703.GA11801@danh.dev>
- In-Reply-To
- <20200320053730.GE499858@coredump.intra.peff.net>
On 2020-03-20 01:37:30-0400, Jeff King <peff@peff.net> wrote:
Show 46 quoted lines
> On Fri, Mar 20, 2020 at 08:41:42AM +0700, Danh Doan wrote:
>
> > On 2020-03-19 15:16:09-0700, Junio C Hamano <gitster@pobox.com> wrote:
> > > Jeff King <peff@peff.net> writes:
> > >
> > > > On Thu, Mar 19, 2020 at 09:00:06PM +0700, Đoàn Trần Công Danh wrote:
> > > >
> > > >> Since commit 6b7728db81, (t7063: work around FreeBSD's lazy mtime
> > > >> update feature, 2016-08-03), we started to use ls as a trick to update
> > > >> directory's mtime.
> > > >>
> > > >> However, `-ls` flag isn't required by POSIX's find(1), and
> > > >> busybox(1) doesn't implement it.
> > > >>
> > > >> Use an equivalence `-exec ls -dils {} +` instead.
> > > >
> > > > Makes sense. I wonder if we need all of "-dils", but it's not clear to
> >
> > From the original commit message, I think whichever flags that call
> > stat(2) would be do it. It's `-d` (to check is_directory), and `-i`
> > for inode number.
> >
> > This make make wonder, will it be enough to just use:
> >
> > find . -type d >/dev/null
>
> Perhaps we can get a friendly FreeBSD developer (cc'd) to run a quick
> test for us.
>
> Ed, the question is whether:
>
> diff --git a/t/t7063-status-untracked-cache.sh b/t/t7063-status-untracked-cache.sh
> index 190ae149cf..6791c6b95a 100755
> --- a/t/t7063-status-untracked-cache.sh
> +++ b/t/t7063-status-untracked-cache.sh
> @@ -18,7 +18,7 @@ GIT_FORCE_UNTRACKED_CACHE=true
> export GIT_FORCE_UNTRACKED_CACHE
>
> sync_mtime () {
> - find . -type d -ls >/dev/null
> + find . -type d >/dev/null
> }
>
> avoid_racy() {
>
> lets t7063 consistently pass on FreeBSD.I've tried myself with a FreeBSD VM which stays on top of an HDD, t7063 consistently pass for 1000 run.
I guess it should be fine
I'll resend with this while waiting for Ed's response.
-- Danh