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.
next prev parent 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).