git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Duy Nguyen <pclouds@gmail.com>
Cc: "Torstem Bögershausen" <tboegi@web.de>,
	"git@vger.kernel.org" <git@vger.kernel.org>,
	"e@80x24.org" <e@80x24.org>
Subject: Re: [PATCH] t7063: work around FreeBSD's lazy mtime update feature
Date: Tue, 02 Aug 2016 10:17:24 -0700	[thread overview]
Message-ID: <xmqqfuqnf5uj.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20160802153715.GA25286@duynguyen> (Duy Nguyen's message of "Tue, 2 Aug 2016 17:37:15 +0200")

Duy Nguyen <pclouds@gmail.com> writes:

> OK how about this squashed in? The name was taken from fbsd definition
> IN_LAZYMOD.

I am sorry that I didn't spot this possiblity earlier, but do we
need anything conditional?  Either FREEBSD or LAZYMOD prerequisite
tells very little what the "Work around lazy mtime update" is and
where it triggers (I think the conclusion of your investigation was
that the timestamp on the containing directory, but that is ONLY
recorded in the log message, i.e. readers need to run 'git blame'
to find out).

It might be a better approach to have a helper function with
descriptive name and comment early in t7063, e.g.

	# On some filesystems (e.g. FreeBSD's ext2 and ufs) this
        # and that happens when we do blah, which forces the
        # untracked cache code to take the slow path.  A test
        # that wants to make sure the fast path works correctly
        # should call this helper to make mtime of the containing
        # directory in sync with the reality after doing blah and
        # before checking the fast path behaviour
	test_sync_directory_mtime () {
		ls -ld . >/dev/null
        }

and then call it at strategic places without any prerequisite.

The helper may turn out to be useful outside the context of 7063
later, at which time we can move it to test-lib-functions, but that
is a separate step.

> Off topic. Since I found this macro defined twice, in ext2 and ufs,
> but not in zfs (found its source!), I assume zfs does not have this
> particular feature (but I didn't test it). Untracked cache may be more
> effecient there.


> -- 8< --
> diff --git a/t/t7063-status-untracked-cache.sh b/t/t7063-status-untracked-cache.sh
> index 08fc586..8bb048a 100755
> --- a/t/t7063-status-untracked-cache.sh
> +++ b/t/t7063-status-untracked-cache.sh
> @@ -419,7 +419,7 @@ test_expect_success 'create/modify files, some of which are gitignored' '
>  	rm base
>  '
>  
> -test_expect_success FREEBSD 'Work around lazy mtime update' '
> +test_expect_success LAZYMOD 'Work around lazy mtime update' '
>  	ls -ld . >/dev/null
>  '
>  
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 3c730a2..1fc5266 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -962,7 +962,7 @@ case $(uname -s) in
>  	test_set_prereq GREP_STRIPS_CR
>  	;;
>  *FreeBSD*)
> -	test_set_prereq FREEBSD
> +	test_set_prereq LAZYMOD
>  	test_set_prereq POSIXPERM
>  	test_set_prereq BSLASHPSPEC
>  	test_set_prereq EXECKEEPSPID
> -- 8< --
>
> --
> Duy

  reply	other threads:[~2016-08-02 17:22 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-18 22:30 t7063 failure on FreeBSD 10.3 i386/amd64 Eric Wong
2016-07-18 22:54 ` Eric Wong
2016-07-19 16:12   ` Duy Nguyen
2016-07-20  3:02     ` Eric Wong
2016-07-20 14:57       ` Duy Nguyen
2016-07-27 17:33     ` Duy Nguyen
2016-07-30 13:31       ` Duy Nguyen
2016-07-30 13:54         ` Duy Nguyen
2016-07-30 18:20 ` [PATCH] t7063: work around FreeBSD's lazy mtime update feature Nguyễn Thái Ngọc Duy
2016-07-31  0:15   ` Eric Wong
2016-07-31  1:07     ` Eric Wong
2016-07-31 14:30       ` Duy Nguyen
2016-08-01  1:37   ` Torstem Bögershausen
2016-08-01 17:10     ` Duy Nguyen
2016-08-01 21:04       ` Junio C Hamano
2016-08-02 15:37         ` Duy Nguyen
2016-08-02 17:17           ` Junio C Hamano [this message]
2016-08-03 16:05   ` [PATCH v2] " Nguyễn Thái Ngọc Duy
2016-08-03 16:16     ` Junio C Hamano
2016-08-03 16:25       ` Duy Nguyen
2016-08-03 17:45     ` [PATCH v3] " Nguyễn Thái Ngọc Duy
2016-08-03 17:52       ` Junio C Hamano
2016-08-03 19:07         ` Junio C Hamano
2016-08-04 15:46           ` Duy Nguyen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqfuqnf5uj.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=e@80x24.org \
    --cc=git@vger.kernel.org \
    --cc=pclouds@gmail.com \
    --cc=tboegi@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).