Обсуждение: git cherry-pick timestamping issue
So my first attempt at using git cherry-pick didn't go so well.
The commit in master looks like
commit ee63981c1fe26299162b9c7f1218d7e3ef802409
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu Sep 23 15:34:56 2010 -0400
Avoid sharing subpath list structure when flattening nested AppendRels.
which is the correct timestamp, but all the back-patched ones look like
commit 4e60212ab5a956bcba89cfd465f945a9c8969f27
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu Sep 23 19:34:56 2010 -0400
Avoid sharing subpath list structure when flattening nested AppendRels.
Apparently somebody's confused between local and GMT time somewhere in
there.
This is with a vanilla build of 1.7.2.3. Anybody else see this type
of symptom?
regards, tom lane
On Thu, Sep 23, 2010 at 3:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Apparently somebody's confused between local and GMT time somewhere in > there. Ouch. That rather sucks. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
On Sep 23, 2010, at 1:02 PM, Robert Haas wrote: > On Thu, Sep 23, 2010 at 3:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Apparently somebody's confused between local and GMT time somewhere in >> there. > > Ouch. That rather sucks. Obviously, all committers must now relocate to the UK. Best, David
On 23 September 2010 22:20, David E. Wheeler <david@kineticode.com> wrote: > On Sep 23, 2010, at 1:02 PM, Robert Haas wrote: > >> On Thu, Sep 23, 2010 at 3:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Apparently somebody's confused between local and GMT time somewhere in >>> there. >> >> Ouch. That rather sucks. > > Obviously, all committers must now relocate to the UK. Yes, move here. I'll put the kettle on. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On Thu, 2010-09-23 at 22:22 +0100, Thom Brown wrote: > On 23 September 2010 22:20, David E. Wheeler <david@kineticode.com> wrote: > > On Sep 23, 2010, at 1:02 PM, Robert Haas wrote: > > > >> On Thu, Sep 23, 2010 at 3:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >>> Apparently somebody's confused between local and GMT time somewhere in > >>> there. > >> > >> Ouch. That rather sucks. > > > > Obviously, all committers must now relocate to the UK. > > Yes, move here. I'll put the kettle on. Better add some whiskey buddy... postgresql people can put it down. /me looks hard at dpage JD -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
At 2010-09-23 15:52:24 -0400, tgl@sss.pgh.pa.us wrote: > > Apparently somebody's confused between local and GMT time somewhere in > there. > > This is with a vanilla build of 1.7.2.3. Anybody else see this type > of symptom? Not me. I just tried various combinations of commit in one branch and cherry-pick in another, and the timestamp stays correct in every case. -- ams
On Thu, Sep 23, 2010 at 5:22 PM, Thom Brown <thom@linux.com> wrote: > On 23 September 2010 22:20, David E. Wheeler <david@kineticode.com> wrote: >> On Sep 23, 2010, at 1:02 PM, Robert Haas wrote: >> >>> On Thu, Sep 23, 2010 at 3:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>> Apparently somebody's confused between local and GMT time somewhere in >>>> there. >>> >>> Ouch. That rather sucks. >> >> Obviously, all committers must now relocate to the UK. > > Yes, move here. I'll put the kettle on. I'm not sure that's the simplest solution to the problem at hand, but I'm game... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
Abhijit Menon-Sen <ams@toroid.org> writes:
> At 2010-09-23 15:52:24 -0400, tgl@sss.pgh.pa.us wrote:
>> This is with a vanilla build of 1.7.2.3. Anybody else see this type
>> of symptom?
> Not me. I just tried various combinations of commit in one branch and
> cherry-pick in another, and the timestamp stays correct in every case.
Hm. What git version are you using?
(I see that 1.7.3 has become the "stable" release since last week,
so maybe I should update.)
regards, tom lane
At 2010-09-23 17:37:51 -0400, tgl@sss.pgh.pa.us wrote: > > Hm. What git version are you using? I'm using 1.7.3, yes. It has a bunch of timezone handling changes, but I'm not sure if there's anything related to your problem. If you don't have TZ set in your environment, I suppose the following patch *could* be relevant, since you're in -0400 and I'm in +0530. I haven't tried to verify this, but if cat-file -p on your backported commit shows an absurdly high timezone value, then that's the problem. Anyway, try 1.7.3 and see if it helps? -- ams commit 9ba0f0334dd505f78e0374bbe857c5e202f5a778 Author: Jeff King <peff@peff.net> Date: Sun Jul 4 07:00:17 2010 -0400 parse_date: fix signedness in timezone calculation When no timezone is specified, we deduce the offset by subtractingthe result of mktime from our calculated timestamp. However, our timestamp is stored as an unsigned integer, meaning we perform the subtraction as unsigned. For a negative offset, this means we wrap to a very high number, and our numeric timezone is in the millions of hours. You can see this bug by doing: $ TZ=EST \ GIT_AUTHOR_DATE='2010-06-01 10:00' \ git commit -a -m foo $ git cat-file -p HEAD | grep author author JeffKing <peff@peff.net> 1275404416 +119304128 Instead, we should perform this subtraction as a time_t, the same typethat mktime returns. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Excerpts from Robert Haas's message of jue sep 23 17:36:07 -0400 2010: > >> Obviously, all committers must now relocate to the UK. > > > > Yes, move here. I'll put the kettle on. > > I'm not sure that's the simplest solution to the problem at hand, but > I'm game... Hey, if it comes to that, I'm game too. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Abhijit Menon-Sen <ams@toroid.org> writes:
> I'm using 1.7.3, yes. It has a bunch of timezone handling changes, but
> I'm not sure if there's anything related to your problem. If you don't
> have TZ set in your environment, I suppose the following patch *could*
> be relevant, since you're in -0400 and I'm in +0530. I haven't tried
> to verify this, but if cat-file -p on your backported commit shows an
> absurdly high timezone value, then that's the problem.
Well, I do keep TZ set, but anyway an update to 1.7.3 seems like a good
idea on general principles. Will try it.
[ experiments a bit ... ] Hm, my Fedora 13 machine isn't showing this
behavior, even though it's also 1.7.2.3 and I don't see any
possibly-related patches being carried by Fedora. Odd.
regards, tom lane
On Thu, 2010-09-23 at 22:22 +0100, Thom Brown wrote: > On 23 September 2010 22:20, David E. Wheeler <david@kineticode.com> wrote: > > On Sep 23, 2010, at 1:02 PM, Robert Haas wrote: > > > >> On Thu, Sep 23, 2010 at 3:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >>> Apparently somebody's confused between local and GMT time somewhere in > >>> there. > >> > >> Ouch. That rather sucks. > > > > Obviously, all committers must now relocate to the UK. > > Yes, move here. I'll put the kettle on. Better add some whiskey buddy... postgresql people can put it down. /me looks hard at dpage JD -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
I wrote:
> Apparently somebody's confused between local and GMT time somewhere in
> there.
For the archives' sake: this turns out to be a portability issue not
handled by the git code. If you are running on a platform old enough
to have gmtime_r returning int rather than struct tm *, you need this
patch:
*** date.c~ Sat Sep 18 19:43:54 2010
--- date.c Fri Sep 24 10:57:28 2010
***************
*** 406,412 **** case '.': now = time(NULL); refuse_future = NULL;
! if (gmtime_r(&now, &now_tm)) refuse_future = &now_tm; if (num > 70) {
--- 406,412 ---- case '.': now = time(NULL); refuse_future = NULL;
! if (gmtime_r(&now, &now_tm) == 0) refuse_future = &now_tm; if (num > 70) {
***************
*** 469,475 **** */ if (num >= 100000000 && nodate(tm)) { time_t time = num;
! if (gmtime_r(&time, tm)) { *tm_gmt = 1; return end - date; }
--- 469,475 ---- */ if (num >= 100000000 && nodate(tm)) { time_t time = num;
! if (gmtime_r(&time, tm) == 0) { *tm_gmt = 1; return end - date; }
[ /me resolves to actually run a program's regression tests before
assuming it works ]
regards, tom lane