All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Robin H. Johnson" <robbat2@gentoo.org>
To: Junio C Hamano <gitster@pobox.com>,
	Git Mailing List <git@vger.kernel.org>
Cc: "Robin H. Johnson" <robbat2@gentoo.org>,
	"Michał Górny" <mgorny@gentoo.org>, "Jeff King" <peff@peff.net>,
	"Lars Schneider" <larsxschneider@gmail.com>,
	"Marc Branchaud" <marcnarc@xiplink.com>
Subject: Re: [RFC PATCH] checkout: Force matching mtime between files
Date: Wed, 25 Apr 2018 07:13:38 +0000	[thread overview]
Message-ID: <robbat2-20180425T060717-325652820Z@orbis-terrarum.net> (raw)
In-Reply-To: <xmqqtvs18p9o.fsf@gitster-ct.c.googlers.com>

[-- Attachment #1: Type: text/plain, Size: 3330 bytes --]

On Tue, Apr 24, 2018 at 08:41:07AM +0900, Junio C Hamano wrote:
> "Robin H. Johnson" <robbat2@gentoo.org> writes:
> 
> > On Fri, Apr 13, 2018 at 07:01:29PM +0200, Michał Górny wrote:
> >> Currently git does not control mtimes of files being checked out.  This
> >> means that the only assumption you could make is that all files created
> >> or modified within a single checkout action will have mtime between
> >> start time and end time of this checkout.  The relations between mtimes
> >> of different files depend on the order in which they are checked out,
> >> filesystem speed and timestamp precision.
> >> ...
> > Junio: ping for review or inclusion of this patch?
> 
> I personally did not think this is a good idea and not worth any
> code contamination with calls to utime().  Is there anybody sane who
> thought this was a good idea in the discussion thread?
Nobody responded to the original message until after I pinged about it
again.

Since that, one person DID respond, stating that it fixed an issue they
had previously reported 6 years ago.

In the thread from 6 years ago, you asked about tar's behavior for
mtimes. 'tar xf' restores mtimes from the tar archive, so relative
ordering after restore would be the same, and would only rebuild if the
original source happened to be dirty.

This behavior is already non-deterministic in Git, and would be improved
by the patch.

On a machine with high resolution timestamps or large enough repo that
checkout takes a long time, an initial checkout of multiple files does
not guarantee the ordering of mtimes of those files. Checking out (A,B)
could wind up with them having a different relative mtimes.

For this example, we are doing a checkout of two files A,B being written
(either due to initial checkout, or both have changed for some reason).

The example system has this as a property:
- "touch A B" => mtime(A) < mtime(B)
- "touch B A" => mtime(A) > mtime(B)
[touch should not re-order arguments, nor apply the same mtime to all
files. Linux touch at this point makes the syscall of 'utimensat(0,
NULL, NULL, 0)' on each file descriptor]

Existing behavior:
mtime(A), mtime(B) are independent of each other, and depend on the
exact order of file checkout, along with the resolution of timestamps
and how much other work is taking place. If the filesystem has low
resolution of timestamps, or the checkout is sufficiently small/fast,
the mtimes are likely to be identical already.

New behavior:
Strictly mtime(A) == mtime(B)

Example makefile rule:
B: A

Human explanation of makefile rule:
file B depends on file A

If the build system triggers on:

* mtime(A) > mtime(B): [strictly greater]
** Old Behavior: It will depend on the exact checkout order. Sometimes
   it will already not rebuild.
** New Behavior: always rebuild, as mtime(A) == mtime(B)

* mtime(A) >= mtime(B): [greater or equal]
** Old Behavior: it will depend on the exact checkout order. Sometimes it
   will, sometimes it won't.
** New Behavior: will not rebuild, as mtime(A) == mtime(B)

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]

  reply	other threads:[~2018-04-25  7:13 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-13 17:01 [RFC PATCH] checkout: Force matching mtime between files Michał Górny
2018-04-23 20:07 ` Robin H. Johnson
2018-04-23 23:41   ` Junio C Hamano
2018-04-25  7:13     ` Robin H. Johnson [this message]
2018-04-25  8:48       ` Junio C Hamano
2018-04-25 15:18         ` Marc Branchaud
2018-04-25 20:07           ` Robin H. Johnson
2018-04-26  1:25           ` Junio C Hamano
2018-04-26 14:12             ` Marc Branchaud
2018-04-26 14:46             ` Michał Górny
2018-04-28 14:23               ` Duy Nguyen
2018-04-28 19:35                 ` Michał Górny
2018-04-26 16:43           ` Duy Nguyen
2018-04-26 17:48             ` Robin H. Johnson
2018-04-26 18:44               ` Duy Nguyen
2018-04-29 23:56                 ` Junio C Hamano
2018-04-30 15:10                   ` Duy Nguyen
2018-04-27 17:03           ` Duy Nguyen
2018-04-27 21:08             ` Elijah Newren
2018-04-28  6:08               ` Duy Nguyen
2018-04-29 23:47               ` Junio C Hamano
2018-04-27 21:08             ` Marc Branchaud
2018-04-28  6:16               ` Duy Nguyen
2018-04-27 17:18           ` Michał Górny
2018-04-27 19:53             ` Ævar Arnfjörð Bjarmason
2018-04-25  8:41     ` Ævar Arnfjörð Bjarmason
2018-04-26 17:15       ` Duy Nguyen
2018-04-26 17:51         ` Robin H. Johnson
2018-04-26 17:53         ` SZEDER Gábor
2018-04-26 18:45           ` Duy Nguyen
2018-04-24 14:41 ` Marc Branchaud
2018-04-25  6:58 ` Robin H. Johnson
2018-04-25  7:13   ` Michał Górny
2018-05-05 18:44 ` Jeff King
2018-05-06  3:37   ` Junio C Hamano

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

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

  git send-email \
    --in-reply-to=robbat2-20180425T060717-325652820Z@orbis-terrarum.net \
    --to=robbat2@gentoo.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=larsxschneider@gmail.com \
    --cc=marcnarc@xiplink.com \
    --cc=mgorny@gentoo.org \
    --cc=peff@peff.net \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.