On Wed, Aug 3, 2016 at 9:07 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> If you mean to tell the user "I won't describe it in detail, if you
>> really want to know,
>> go run blame yourself", spell it out like so. I was hoping that you
>> can summarize
>> in-line there to help the readers here.
>
> Here is a proposed fixup.
Great! Sorry I only have one or two hours these days and could not
propose something else quicker.
> t/t7063-status-untracked-cache.sh | 16 ++++++++++------
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/t/t7063-status-untracked-cache.sh b/t/t7063-status-untracked-cache.sh
> index d31d080..e0a8228 100755
> --- a/t/t7063-status-untracked-cache.sh
> +++ b/t/t7063-status-untracked-cache.sh
> @@ -4,12 +4,16 @@ test_description='test untracked cache'
>
> . ./test-lib.sh
>
> -# 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
> +# On some filesystems (e.g. FreeBSD's ext2 and ufs) directory mtime
> +# is updated lazily after contents in the directory changes, which
> +# forces the untracked cache code to take the slow path. A test
> +# that wants to make sure that the fast path works correctly should
> +# call this helper to make mtime of the containing directory in sync
> +# with the reality before checking the fast path behaviour.
> +#
> +# See <20160803174522.5571-1-pclouds@xxxxxxxxx> if you want to know
> +# more.
> +
> sync_mtime () {
> find . -type d -ls >/dev/null
> }
--
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html