git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: jeffpc@josefsipek.net
To: Theodore Tso <tytso@MIT.EDU>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH] guilt: Make sure the commit time is increasing
Date: Mon, 5 Jul 2010 14:52:38 -0400	[thread overview]
Message-ID: <20100705185238.GS22659@josefsipek.net> (raw)
In-Reply-To: <67D0ABD4-BD1A-4B7A-B3EC-F48F21B5DD01@mit.edu>

On Mon, Jul 05, 2010 at 07:06:45AM -0400, Theodore Tso wrote:
> On Jul 4, 2010, at 10:59 PM, jeffpc@josefsipek.net wrote:
> > 
> > Am I understanding this right?  You want the timestamps to be monotonically
> > increasing?  
> 
> Yup, that's correct.  In more modern versions of git most (all?) of the places
> that depend on the committer time of the child commit to be greater than the
> committer time of its parents have been relaxed to accept up to a day's worth
> of clock skew, but in the interests of "be conservative in what you send",
> strictly increasing seemed like the best thing to do.

Alright, makes sense.

> > Is the +60 the most obvious choice?
> 
> It's somewhat arbitrary.  I figured a minute increase between commits was
> more aesthetically pleasing than a second, 5 minutes, or an hour, which
> were some other deltas that previous versions of my patch used while I
> was experimenting.

I think we might need a little bit more logic in this patch...

if I commit, and immediately after push 10 patches, wouldn't the HEAD end up
with a commit that's ~10 minutes in the future?

> > Can I get an example of how git can get confused?
> 
> This first one is explicitly my/guilt's fault (and it's when I learned that I
> was causing problems by how I was using guilt in the ext4 tree):
> 
> http://kerneltrap.org/mailarchive/git/2010/4/22/28928/thread
> 
> In this thread we see how the clock skew gets in the way of an optimization
> that speeds up "git tag --contains" by over two orders of magnitude, but it
> gets screwed over by extreme clock skew.  I suggested in that thread that 
> if git is going to depend on it, then maybe "git commit" should either warn
> or error out if the git committer timestamp goes backwards --- and that's when
> I decided maybe I should offer up a patch to guilt to fix this, either before or
> instead of fixing up "git commit" to throw a warning/error:

I do like the idea of git-commit warning/erroring, but I don't think that
guilt issuing a warning is necessary.  Afterall, it's only a timestamp
change.  It might be a bit of a shock for anyone looking at the timestamps
expecting them to be out of order (based on the patch times), but I think
it's better than warning all the time.

Jeff.

-- 
What is the difference between Mechanical Engineers and Civil Engineers?
Mechanical Engineers build weapons, Civil Engineers build targets.

  reply	other threads:[~2010-07-05 18:52 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-05  2:23 [PATCH] guilt: Make sure the commit time is increasing Theodore Ts'o
2010-07-05  2:51 ` tytso
2010-07-05  3:01   ` jeffpc
2010-07-05  2:59 ` jeffpc
2010-07-05 11:06   ` Theodore Tso
2010-07-05 18:52     ` jeffpc [this message]
2010-07-05 19:22       ` tytso
2010-07-06  8:03         ` Jonathan Nieder
2010-07-06 10:56           ` Theodore Tso
2010-07-06 15:09             ` Jonathan Nieder
2010-07-06 17:12               ` tytso
2010-07-06 17:29                 ` Jonathan Nieder
2010-07-06 13:53           ` Erik Faye-Lund
2010-07-06 14:29             ` Jeff King
2010-07-06 15:02               ` Erik Faye-Lund
2010-07-06 17:21                 ` tytso
2010-07-06 17:29         ` jeffpc
2010-07-06 18:57           ` tytso
2010-07-14  3:01         ` Josef 'Jeff' Sipek

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=20100705185238.GS22659@josefsipek.net \
    --to=jeffpc@josefsipek.net \
    --cc=git@vger.kernel.org \
    --cc=tytso@MIT.EDU \
    /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 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 NNTP newsgroup(s).