* Re: bzr to git syncing
From: Alex Bennee @ 2009-08-28 17:47 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git, David Reitter
In-Reply-To: <fabb9a1e0908280919o412baeb1ka69968a93297ca59@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 862 bytes --]
2009/8/28 Sverre Rabbelier <srabbelier@gmail.com>:
> Heya,
>
> On Fri, Aug 28, 2009 at 09:02, Alex Bennee<kernel-hacker@bennee.com> wrote:
>> I've attached the fast-import crash I'm seeing. Are you seeing the
>> same sort of failure?
>
> The program you used to generate the stream (I assume git-bzr?) is
> generating an invalid mode, git understands '100644', '100755',
> '120000', and '160000'; the mode in the stream, '040000', is not
> something we understand.
Yeah, it seems in bzr land it mean new directory which we don't care
about. The following patch makes it work. Apologies for failure to
inline but Gmail would just corrupt it if I tried.
I also had to patch the ref check code to accept bzr style branch
names but I suspect that patch should be kept out of the repo.
--
Alex, homepage: http://www.bennee.com/~alex/
http://www.half-llama.co.uk
[-- Attachment #2: 0001-Handle-new-directory-commands-from-a-bzr-fast-export.patch --]
[-- Type: application/x-httpd-php, Size: 1071 bytes --]
[-- Attachment #3: 0002-Allow-in-a-branch-name.patch --]
[-- Type: application/x-httpd-php, Size: 1086 bytes --]
^ permalink raw reply
* Re: bzr to git syncing
From: Sverre Rabbelier @ 2009-08-28 17:49 UTC (permalink / raw)
To: Alex Bennee; +Cc: git, David Reitter, vcs-fast-import-devs
In-Reply-To: <b2cdc9f30908281047p76c12029u21b100ae6d88fe93@mail.gmail.com>
Heya,
[+vcs-fast-import-devs]
On Fri, Aug 28, 2009 at 10:47, Alex Bennee<kernel-hacker@bennee.com> wrote:
> 2009/8/28 Sverre Rabbelier <srabbelier@gmail.com>:
>> On Fri, Aug 28, 2009 at 09:02, Alex Bennee<kernel-hacker@bennee.com> wrote:
>>> I've attached the fast-import crash I'm seeing. Are you seeing the
>>> same sort of failure?
>>
>> The program you used to generate the stream (I assume git-bzr?) is
>> generating an invalid mode, git understands '100644', '100755',
>> '120000', and '160000'; the mode in the stream, '040000', is not
>> something we understand.
>
> Yeah, it seems in bzr land it mean new directory which we don't care
> about. The following patch makes it work. Apologies for failure to
> inline but Gmail would just corrupt it if I tried.
>
> I also had to patch the ref check code to accept bzr style branch
> names but I suspect that patch should be kept out of the repo.
This seems like a fine case for the new 'feature' command on bzr's export side.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Jeff King @ 2009-08-28 18:01 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Alex Riesen, David Reiss, git
In-Reply-To: <alpine.LFD.2.00.0908281307510.6044@xanadu.home>
On Fri, Aug 28, 2009 at 01:28:34PM -0400, Nicolas Pitre wrote:
> However I was hoping for a current time trickery solution that could
> live in test-date.c instead of interfering with the main code in such a
> way.
>
> Did a quick test to override the library version:
Thanks, that is a much better solution. And I don't know offhand of any
portability problems in overriding the library at link time.
-Peff
^ permalink raw reply
* [PATCH] post-receive-email: do not call sendmail if no mail was generated
From: Lars Noschinski @ 2009-08-28 17:39 UTC (permalink / raw)
To: git; +Cc: gitster, Lars Noschinski
contrib/hooks/post-receive-email used to call the send_mail function
(and thus, /usr/sbin/sendmail), even if generate_mail returned an error.
This is problematic, as the sendmail binary provided by exim4 generates
an error mail if provided with an empty input.
Therefore, this commit changes post-receive-email to only call sendmail
if generate_mail returned without error.
Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
---
contrib/hooks/post-receive-email | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
Obvious drawback of this solution is that the mails are kept in memory as a
whole. But the mails should be small enough, so that this does not hurt.
I'm not sure how to write a test for this bug, as the hook (correctly) uses an
absolute path to call sendmail.
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 2a66063..818a270 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -684,6 +684,9 @@ if [ -n "$1" -a -n "$2" -a -n "$3" ]; then
else
while read oldrev newrev refname
do
- generate_email $oldrev $newrev $refname | send_mail
+ mail="$(generate_email $oldrev $newrev $refname)"
+ if [ $? -eq 0 ]; then
+ printf '%s' "$mail" | send_mail
+ fi
done
fi
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Alex Riesen @ 2009-08-28 18:21 UTC (permalink / raw)
To: Jeff King; +Cc: David Reiss, git
In-Reply-To: <20090828171552.GA6821@coredump.intra.peff.net>
On Fri, Aug 28, 2009 at 19:15, Jeff King<peff@peff.net> wrote:
> On Fri, Aug 28, 2009 at 07:00:59PM +0200, Alex Riesen wrote:
>
>> On Fri, Aug 28, 2009 at 17:02, Jeff King<peff@peff.net> wrote:
>> > But that's the point: you can't do that without a race condition. Your
>> > test gets a sense of the current time, then runs git, which checks the
>> > current time again. How many seconds elapsed between the two checks?
>>
>> How _many_ do you need?
>
> I don't understand what you're trying to say. My point is that if you
> are checking results to a one-second precision, you need to know whether
> zero seconds elapsed, or one second, or two seconds, or whatever to get
> a consistent result.
Taking this particular case as an example, can't we just set the time
of the _commit_ back in time? We can.
And we don't need to know the difference precisely, it can be
something like /[0-9]+ ago/, can't it?
Ok, it is possible, that something goes terribly wrong and the test suite
freezes for an extended period of time, so the pattern above does
not apply anymore. In this case, wont you prefer the test suite to
break? Ok, maybe not, if the freeze was an Ctrl-Z pressed at
unlucky moment. Which involves an operator online and looking,
and action and reaction will be both visible.
So, yes, it is not absolutely safe, but this approach has no side effects
on the working code. And very low probability of something go wrong.
^ permalink raw reply
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Alex Riesen @ 2009-08-28 18:27 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Pitre, David Reiss, git
In-Reply-To: <20090828180158.GA6940@coredump.intra.peff.net>
On Fri, Aug 28, 2009 at 20:01, Jeff King<peff@peff.net> wrote:
> On Fri, Aug 28, 2009 at 01:28:34PM -0400, Nicolas Pitre wrote:
>
>> However I was hoping for a current time trickery solution that could
>> live in test-date.c instead of interfering with the main code in such a
>> way.
>>
>> Did a quick test to override the library version:
>
> Thanks, that is a much better solution. And I don't know offhand of any
> portability problems in overriding the library at link time.
>
Microsoft's compiler and libraries? MacOSX?
^ permalink raw reply
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Jeff King @ 2009-08-28 18:39 UTC (permalink / raw)
To: Alex Riesen; +Cc: Nicolas Pitre, David Reiss, git
In-Reply-To: <81b0412b0908281127h2c444770g411ceaf052952899@mail.gmail.com>
On Fri, Aug 28, 2009 at 08:27:06PM +0200, Alex Riesen wrote:
> > Thanks, that is a much better solution. And I don't know offhand of any
> > portability problems in overriding the library at link time.
>
> Microsoft's compiler and libraries? MacOSX?
Are you saying you know those to be platforms with problems, or are you
asking whether those platforms will have problems?
-Peff
^ permalink raw reply
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Alex Riesen @ 2009-08-28 18:42 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Pitre, David Reiss, git
In-Reply-To: <20090828183958.GA11488@coredump.intra.peff.net>
On Fri, Aug 28, 2009 at 20:39, Jeff King<peff@peff.net> wrote:
> On Fri, Aug 28, 2009 at 08:27:06PM +0200, Alex Riesen wrote:
>
>> > Thanks, that is a much better solution. And I don't know offhand of any
>> > portability problems in overriding the library at link time.
>>
>> Microsoft's compiler and libraries? MacOSX?
>
> Are you saying you know those to be platforms with problems, or are you
> asking whether those platforms will have problems?
Both: MS never had weak/vague linkage, but I don't know about MacOSX.
I suspect them to have the same deficiency, but I'd be glad to be wrong.
^ permalink raw reply
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Alex Riesen @ 2009-08-28 18:49 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Pitre, David Reiss, git
In-Reply-To: <81b0412b0908281142v7e1b73ddvb727abe915dace86@mail.gmail.com>
On Fri, Aug 28, 2009 at 20:42, Alex Riesen<raa.lkml@gmail.com> wrote:
> On Fri, Aug 28, 2009 at 20:39, Jeff King<peff@peff.net> wrote:
>> On Fri, Aug 28, 2009 at 08:27:06PM +0200, Alex Riesen wrote:
>>
>>> > Thanks, that is a much better solution. And I don't know offhand of any
>>> > portability problems in overriding the library at link time.
>>>
Hm, how about supplying show_date and approxidate with current time?
Like this:
/* exported */
const char *show_date_rel(unsigned long time, int tz, struct timeval *now)
{
... the DATE_RELATIVE path of show_date
}
const char *show_date(unsigned long time, int tz, enum date_mode mode)
{
struct timeval now;
if (mode == DATE_RELATIVE) {
gettimeofday(&now, NULL);
return show_date_rel(time, tz, &now);
}
... other paths of old show_date
}
Still affects the performance, but much less, and no side effects.
And you can test show_date_rel path in test-date.c
^ permalink raw reply
* gittogether '09
From: Brandon Casey @ 2009-08-28 18:53 UTC (permalink / raw)
To: Git Mailing List
I haven't heard much about this in a while.
Is it still going to happen?
-brandon
^ permalink raw reply
* Re: [PATCH v3] import-tars: Allow per-tar author and commit message.
From: Peter Krefting @ 2009-08-28 18:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vskfcd8ep.fsf@alter.siamese.dyndns.org>
Junio C Hamano:
> Don't you at least want to avoid misparsing a msg file that looks like
> this?
Good point... Will post a fixed version.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* [PATCH v4] import-tars: Allow per-tar author and commit message.
From: Peter Krefting @ 2009-08-26 19:26 UTC (permalink / raw)
To: git
If the "--metainfo=<ext>" option is given on the command line, a file
called "<filename.tar>.<ext>" will be used to create the commit message
for "<filename.tar>", instead of using "Imported from filename.tar".
The author and committer of the tar ball can also be overridden by
embedding an "Author:" or "Committer:" header in the metainfo file.
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
---
This version stops parsing the meta file for headers as soon as a
non-header line is seen, as requested by Junio.
contrib/fast-import/import-tars.perl | 56 +++++++++++++++++++++++++++++++--
1 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/contrib/fast-import/import-tars.perl b/contrib/fast-import/import-tars.perl
index 78e40d2..081694f 100755
--- a/contrib/fast-import/import-tars.perl
+++ b/contrib/fast-import/import-tars.perl
@@ -8,9 +8,20 @@
## perl import-tars.perl *.tar.bz2
## git whatchanged import-tars
##
+## Use --metainfo to specify the extension for a meta data file, where
+## import-tars can read the commit message and optionally author and
+## committer information.
+##
+## echo 'This is the commit message' > myfile.tar.bz2.msg
+## perl import-tars.perl --metainfo=msg myfile.tar.bz2
use strict;
-die "usage: import-tars *.tar.{gz,bz2,Z}\n" unless @ARGV;
+use Getopt::Long;
+
+my $metaext = '';
+
+die "usage: import-tars [--metainfo=extension] *.tar.{gz,bz2,Z}\n"
+ unless GetOptions('metainfo=s' => \$metaext) && @ARGV;
my $branch_name = 'import-tars';
my $branch_ref = "refs/heads/$branch_name";
@@ -109,12 +120,49 @@ foreach my $tar_file (@ARGV)
$have_top_dir = 0 if $top_dir ne $1;
}
+ my $commit_msg = "Imported from $tar_file.";
+ my $this_committer_name = $committer_name;
+ my $this_committer_email = $committer_email;
+ my $this_author_name = $author_name;
+ my $this_author_email = $author_email;
+ if ($metaext ne '')
+ {
+ # Optionally read a commit message from <filename.tar>.msg
+ # Add a line on the form "Committer: name <e-mail>" to override
+ # the committer and "Author: name <e-mail>" to override the
+ # author for this tar ball.
+ if (open MSG, '<', "${tar_file}.${metaext}")
+ {
+ my $header_done = 0;
+ $commit_msg = '';
+ while (<MSG>)
+ {
+ if (!$header_done && /^Committer:\s+([^<>]*)\s+<(.*)>\s*$/i)
+ {
+ $this_committer_name = $1;
+ $this_committer_email = $2;
+ }
+ elsif (!$header_done && /^Author:\s+([^<>]*)\s+<(.*)>\s*$/i)
+ {
+ $this_author_name = $1;
+ $this_author_email = $2;
+ }
+ else
+ {
+ $commit_msg .= $_;
+ $header_done = 1;
+ }
+ }
+ close MSG;
+ }
+ }
+
print FI <<EOF;
commit $branch_ref
-author $author_name <$author_email> $author_time +0000
-committer $committer_name <$committer_email> $commit_time +0000
+author $this_author_name <$this_author_email> $author_time +0000
+committer $this_committer_name <$this_committer_email> $commit_time +0000
data <<END_OF_COMMIT_MESSAGE
-Imported from $tar_file.
+$commit_msg
END_OF_COMMIT_MESSAGE
deleteall
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Nicolas Pitre @ 2009-08-28 19:00 UTC (permalink / raw)
To: Alex Riesen; +Cc: Jeff King, David Reiss, git
In-Reply-To: <81b0412b0908281142v7e1b73ddvb727abe915dace86@mail.gmail.com>
On Fri, 28 Aug 2009, Alex Riesen wrote:
> On Fri, Aug 28, 2009 at 20:39, Jeff King<peff@peff.net> wrote:
> > On Fri, Aug 28, 2009 at 08:27:06PM +0200, Alex Riesen wrote:
> >
> >> > Thanks, that is a much better solution. And I don't know offhand of any
> >> > portability problems in overriding the library at link time.
> >>
> >> Microsoft's compiler and libraries? MacOSX?
> >
> > Are you saying you know those to be platforms with problems, or are you
> > asking whether those platforms will have problems?
>
> Both: MS never had weak/vague linkage, but I don't know about MacOSX.
This is not about weak or vague linkage. This is plain basic linker
feature where no library object needs to be linked if there is no symbol
to resolve.
> I suspect them to have the same deficiency, but I'd be glad to be wrong.
Are you able to test it?
Nicolas
^ permalink raw reply
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Alex Riesen @ 2009-08-28 19:03 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, David Reiss, git
In-Reply-To: <alpine.LFD.2.00.0908281307510.6044@xanadu.home>
>From b51bc56816490c71cd37f52be73a06cef6b9bf14 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Fri, 28 Aug 2009 20:59:59 +0200
Subject: [PATCH] Add date formatting functions with current time explicitely formatted
It should allow safe testing of this part of the code.
---
Nicolas Pitre, Fri, Aug 28, 2009 19:28:34 +0200:
> On Fri, 28 Aug 2009, Jeff King wrote:
> > On Fri, Aug 28, 2009 at 09:58:27AM +0200, Alex Riesen wrote:
> >
> > > > I couldn't find any tests related to relative date processing, so it
> > > > would be really nice to have some. But I'm not sure of the best way to
> > > > do it without dealing with race conditions. Annoyingly, show_date calls
> > > > gettimeofday at a pretty low level, so there isn't a way of
> > > > instrumenting it short of LD_PRELOAD trickery (which is probably not
> > > > very portable).
> > >
> > > Maybe better prepare the _test_ so that it uses current time and time
> > > arithmetics then put yet another cludge in operational code? Especially
> > > when we already have a greate number of GIT_ environment variables,
> > > documented nowhere, with effects not immediately obvious:
> >
> > But that's the point: you can't do that without a race condition. Your
> > test gets a sense of the current time, then runs git, which checks the
> > current time again. How many seconds elapsed between the two checks?
> >
> > I guess it is good enough for testing large time spans, but I was hoping
> > for a comprehensive time test.
>
> I agree with your concern. This is why I created the --index-version
> switch to pack-objects.
>
This is what I mean with "supplying current time":
cache.h | 2 +
date.c | 130 ++++++++++++++++++++++++++++++++++----------------------------
2 files changed, 73 insertions(+), 59 deletions(-)
diff --git a/cache.h b/cache.h
index dd7f71e..3fb0166 100644
--- a/cache.h
+++ b/cache.h
@@ -731,9 +731,11 @@ enum date_mode {
};
const char *show_date(unsigned long time, int timezone, enum date_mode mode);
+const char *show_date_relative(unsigned long time, int tz, const struct timeval *now);
int parse_date(const char *date, char *buf, int bufsize);
void datestamp(char *buf, int bufsize);
unsigned long approxidate(const char *);
+unsigned long approxidate_relative(const char *date, const struct timeval *now);
enum date_mode parse_date_format(const char *format);
#define IDENT_WARN_ON_NO_NAME 1
diff --git a/date.c b/date.c
index 409a17d..08b4b49 100644
--- a/date.c
+++ b/date.c
@@ -84,6 +84,67 @@ static int local_tzoffset(unsigned long time)
return offset * eastwest;
}
+const char *show_date_relative(unsigned long time, int tz, const struct timeval *now)
+{
+ static char timebuf[100 /* TODO: can be optimized */];
+ unsigned long diff;
+ if (now->tv_sec < time)
+ return "in the future";
+ diff = now->tv_sec - time;
+ if (diff < 90) {
+ snprintf(timebuf, sizeof(timebuf), "%lu seconds ago", diff);
+ return timebuf;
+ }
+ /* Turn it into minutes */
+ diff = (diff + 30) / 60;
+ if (diff < 90) {
+ snprintf(timebuf, sizeof(timebuf), "%lu minutes ago", diff);
+ return timebuf;
+ }
+ /* Turn it into hours */
+ diff = (diff + 30) / 60;
+ if (diff < 36) {
+ snprintf(timebuf, sizeof(timebuf), "%lu hours ago", diff);
+ return timebuf;
+ }
+ /* We deal with number of days from here on */
+ diff = (diff + 12) / 24;
+ if (diff < 14) {
+ snprintf(timebuf, sizeof(timebuf), "%lu days ago", diff);
+ return timebuf;
+ }
+ /* Say weeks for the past 10 weeks or so */
+ if (diff < 70) {
+ snprintf(timebuf, sizeof(timebuf), "%lu weeks ago", (diff + 3) / 7);
+ return timebuf;
+ }
+ /* Say months for the past 12 months or so */
+ if (diff < 360) {
+ snprintf(timebuf, sizeof(timebuf), "%lu months ago", (diff + 15) / 30);
+ return timebuf;
+ }
+ /* Give years and months for 5 years or so */
+ if (diff < 1825) {
+ unsigned long years = (diff + 183) / 365;
+ unsigned long months = (diff % 365 + 15) / 30;
+ int n;
+ n = snprintf(timebuf, sizeof(timebuf), "%lu year%s",
+ years, (years > 1 ? "s" : ""));
+ if (months)
+ snprintf(timebuf + n, sizeof(timebuf) - n,
+ ", %lu month%s ago",
+ months, (months > 1 ? "s" : ""));
+ else
+ snprintf(timebuf + n, sizeof(timebuf) - n,
+ " ago");
+ return timebuf;
+ }
+ /* Otherwise, just years. Centuries is probably overkill. */
+ snprintf(timebuf, sizeof(timebuf), "%lu years ago", (diff + 183) / 365);
+ return timebuf;
+
+}
+
const char *show_date(unsigned long time, int tz, enum date_mode mode)
{
struct tm *tm;
@@ -95,63 +156,9 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)
}
if (mode == DATE_RELATIVE) {
- unsigned long diff;
struct timeval now;
gettimeofday(&now, NULL);
- if (now.tv_sec < time)
- return "in the future";
- diff = now.tv_sec - time;
- if (diff < 90) {
- snprintf(timebuf, sizeof(timebuf), "%lu seconds ago", diff);
- return timebuf;
- }
- /* Turn it into minutes */
- diff = (diff + 30) / 60;
- if (diff < 90) {
- snprintf(timebuf, sizeof(timebuf), "%lu minutes ago", diff);
- return timebuf;
- }
- /* Turn it into hours */
- diff = (diff + 30) / 60;
- if (diff < 36) {
- snprintf(timebuf, sizeof(timebuf), "%lu hours ago", diff);
- return timebuf;
- }
- /* We deal with number of days from here on */
- diff = (diff + 12) / 24;
- if (diff < 14) {
- snprintf(timebuf, sizeof(timebuf), "%lu days ago", diff);
- return timebuf;
- }
- /* Say weeks for the past 10 weeks or so */
- if (diff < 70) {
- snprintf(timebuf, sizeof(timebuf), "%lu weeks ago", (diff + 3) / 7);
- return timebuf;
- }
- /* Say months for the past 12 months or so */
- if (diff < 360) {
- snprintf(timebuf, sizeof(timebuf), "%lu months ago", (diff + 15) / 30);
- return timebuf;
- }
- /* Give years and months for 5 years or so */
- if (diff < 1825) {
- unsigned long years = (diff + 183) / 365;
- unsigned long months = (diff % 365 + 15) / 30;
- int n;
- n = snprintf(timebuf, sizeof(timebuf), "%lu year%s",
- years, (years > 1 ? "s" : ""));
- if (months)
- snprintf(timebuf + n, sizeof(timebuf) - n,
- ", %lu month%s ago",
- months, (months > 1 ? "s" : ""));
- else
- snprintf(timebuf + n, sizeof(timebuf) - n,
- " ago");
- return timebuf;
- }
- /* Otherwise, just years. Centuries is probably overkill. */
- snprintf(timebuf, sizeof(timebuf), "%lu years ago", (diff + 183) / 365);
- return timebuf;
+ return show_date_relative(time, tz, &now);
}
if (mode == DATE_LOCAL)
@@ -866,19 +873,17 @@ static const char *approxidate_digit(const char *date, struct tm *tm, int *num)
return end;
}
-unsigned long approxidate(const char *date)
+unsigned long approxidate_relative(const char *date, const struct timeval *tv)
{
int number = 0;
struct tm tm, now;
- struct timeval tv;
time_t time_sec;
char buffer[50];
if (parse_date(date, buffer, sizeof(buffer)) > 0)
return strtoul(buffer, NULL, 10);
- gettimeofday(&tv, NULL);
- time_sec = tv.tv_sec;
+ time_sec = tv->tv_sec;
localtime_r(&time_sec, &tm);
now = tm;
for (;;) {
@@ -899,3 +904,10 @@ unsigned long approxidate(const char *date)
tm.tm_year--;
return mktime(&tm);
}
+
+unsigned long approxidate(const char *date)
+{
+ struct timeval tv;
+ gettimeofday(&tv, NULL);
+ return approxidate_relative(date, &tv);
+}
--
1.6.4.1.261.gf9874
^ permalink raw reply related
* Re: [BUG] git stash refuses to save after "add -N"
From: Jeff King @ 2009-08-28 19:05 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <54e098c45bffbf870bdfcee26b9ddecc.squirrel@intranet.linagora.com>
On Fri, Aug 28, 2009 at 01:02:23PM +0200, Yann Dirson wrote:
> $ echo foo > bar
> $ git add -N bar
> $ ./git --exec-path=$PWD stash save
> bar: not added yet
> fatal: git-write-tree: error building trees
> Cannot save the current index state
>
> Maybe it would require some magic in git-stash to detect/save/restore that
> particular state, or "just" to cause "add -N" to insert an empty file
> instead ?
Yes, there needs to be some magic in git-stash to handle this. There are
actually two calls to write-tree: one to save the index and one to save
the working tree. I think the working tree one should be OK, because we
"git add -u" right beforehand, which means "intent-to-add" files will
be saved properly.
For the index case, we unfortunately cannot represent the situation in
the index using a tree, which means we cannot have a stash that doesn't
lose information. So we have to choose either dropping those index
entries, inserting them as blank files, or inserting them with
working-tree contents.
When you apply the stash, if they were:
- dropped, then you may be surprised to find that those files are now
untracked
- inserted as working-tree content, then you may not realize that you
had not _actually_ added that content to the index earlier, and just
commit it
- inserted as blank files, then you may be a bit surprised by the fact
that it looks like you added a blank version, but at least you will
still see a diff against the working tree file, alerting you to the
fact that maybe they weren't entirely ready for commit.
So I think of the three, the last one is the least surprising. The other
option is to die and force the user to resolve the issue, which is what
we do now. It does actually tell you the problem "bar: not added yet",
though we could perhaps improve on that message a bit. I think that
would require a new 'ls-files' flag to list intent-to-add files.
-Peff
^ permalink raw reply
* Re: [RFC PATCH] upload-pack: expand capability advertises additional refs
From: Junio C Hamano @ 2009-08-28 19:07 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: git, Nicolas Pitre, Julian Phillips, Daniel Barkalow,
Johannes Schindelin
In-Reply-To: <20090828173007.GX1033@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> static void upload_pack(void)
> {
> + git_config(upload_pack_config, NULL);
> + if (!configured_advertise)
> + push_advertise("refs/*");
> +
> + head_ref(scan_ref, NULL);
> + for_each_ref(scan_ref, NULL);
> +
> reset_timeout();
> - head_ref(send_ref, NULL);
> - for_each_ref(send_ref, NULL);
> - packet_flush(1);
> + send_refs();
> receive_needs();
> if (want_obj.nr) {
> get_common_commits();
> @@ -652,6 +764,7 @@ int main(int argc, char **argv)
>
> git_extract_argv0_path(argv[0]);
> read_replace_refs = 0;
> + push_advertise("HEAD");
>
> for (i = 1; i < argc; i++) {
> char *arg = argv[i];
> @@ -667,6 +780,10 @@ int main(int argc, char **argv)
> daemon_mode = 1;
> continue;
> }
> + if (!prefixcmp(arg, "--expand=")) {
> + push_advertise(arg + 9);
> + continue;
> + }
> if (!strcmp(arg, "--")) {
> i++;
> break;
This arrangement of push_advertise() calls are rather curious. I think
your design guidelines are:
- We do want to advertise HEAD, so it can (and should) be unconditional;
- We may want to restrict with configuration, or use "refs/*" as the
fallback default;
- We may want to (extend|replace) advertised set configured in the
configuration file.
I would naively expect the above to be implemented in this order:
- In main, first thing is to do the git_config() bit; if to_advertise is
non-empty after git_config() returns, we have seen upload.advertise.
Otherwise we haven't. Push "refs/*" in the latter case.
- Then, parse the command line. Do we see "--expand="? If so:
. When handling the first "--expand=", clear to_advertise list. This
step is optional---necessary only if we want to make config variable
override-able ;-);
. Then, push the pattern in.
- And finally push "HEAD" in unconditionally.
Which would mean a few things:
- Your version always extends what is read from the configuration with
--expand=, but I think replacing would be the right thing to do.
- configured_advertise global variable can go.
- Instead, to implement "--expand= replaces", we need a local variable in
main() to remember if we already cleared to_advertise of the patterns
read from the configuration file, and use it in the part that parses
"--expand=".
But I may not be thinking clearly; I was up all night because I couldn't
sleep under loud noises of fire-fighting helicopters...
^ permalink raw reply
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Alex Riesen @ 2009-08-28 19:08 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, David Reiss, git
In-Reply-To: <alpine.LFD.2.00.0908281458370.6044@xanadu.home>
On Fri, Aug 28, 2009 at 21:00, Nicolas Pitre<nico@cam.org> wrote:
>> >> Microsoft's compiler and libraries? MacOSX?
>> >
>> > Are you saying you know those to be platforms with problems, or are you
>> > asking whether those platforms will have problems?
>>
>> Both: MS never had weak/vague linkage, but I don't know about MacOSX.
>
> This is not about weak or vague linkage. This is plain basic linker
> feature where no library object needs to be linked if there is no symbol
> to resolve.
Maybe I missed something, but wasn't the idea to overwrite gettimeofday
with a public gettimeofday, defined in one of the object files?
And shouldn't a linker complain regarding duplicated symbols, unless
the other (library) symbol is defined as a weak symbol, allowing
overriding it with another symbol of stronger linkage?
>> I suspect them to have the same deficiency, but I'd be glad to be wrong.
>
> Are you able to test it?
>
Only the MS, but it is not interesting.
^ permalink raw reply
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Jeff King @ 2009-08-28 19:15 UTC (permalink / raw)
To: Alex Riesen; +Cc: Nicolas Pitre, David Reiss, git
In-Reply-To: <20090828190319.GA9233@blimp.localdomain>
On Fri, Aug 28, 2009 at 09:03:19PM +0200, Alex Riesen wrote:
> +unsigned long approxidate(const char *date)
> +{
> + struct timeval tv;
> + gettimeofday(&tv, NULL);
> + return approxidate_relative(date, &tv);
> +}
This now always calls gettimeofday, whereas the original approxidate
only did if parse_date failed.
I think you could also make this patch much smaller by just wrapping the
whole function and using a '0' sentinel for "you need to fill in the
time." Like:
---
diff --git a/date.c b/date.c
index 409a17d..b084d19 100644
--- a/date.c
+++ b/date.c
@@ -86,6 +86,14 @@ static int local_tzoffset(unsigned long time)
const char *show_date(unsigned long time, int tz, enum date_mode mode)
{
+ struct timeval now;
+ now.tv_sec = 0;
+ show_date_at_time(time, tz, mode, &now);
+}
+
+const char *show_date_at_time(unsigned long time, int tz, enum date_mode mode,
+ struct timeval now)
+{
struct tm *tm;
static char timebuf[200];
@@ -96,8 +104,8 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)
if (mode == DATE_RELATIVE) {
unsigned long diff;
- struct timeval now;
- gettimeofday(&now, NULL);
+ if (!now.tv_sec)
+ gettimeofday(&now, NULL);
if (now.tv_sec < time)
return "in the future";
diff = now.tv_sec - time;
On the other hand, refactoring the relative date code into its own
function is probably a good thing in the long run.
-Peff
^ permalink raw reply related
* Re: gittogether '09
From: Shawn O. Pearce @ 2009-08-28 19:17 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List
In-Reply-To: <B4HB1FEv7c_CIWG-9fK8wLMj4F7i2ueS_jaxoD63gy5Bh46mgkoxGg@cipher.nrlssc.navy.mil>
Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil> wrote:
>
> I haven't heard much about this in a while.
> Is it still going to happen?
Yes. I need to get started on this, its about that time. :-)
--
Shawn.
^ permalink raw reply
* [PATCH] git submodule add: make the <path> parameter optional
From: Jens Lehmann @ 2009-08-28 19:19 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, git
When <path> is not given, use the "humanish" part of the source repository
instead.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
With this patch, git submodule add behaves like git clone in this respect.
Documentation/git-submodule.txt | 8 ++++++--
git-submodule.sh | 7 ++++++-
t/t7400-submodule-basic.sh | 16 ++++++++++++++++
3 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 5ccdd18..4ef70c4 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git submodule' [--quiet] add [-b branch]
- [--reference <repository>] [--] <repository> <path>
+ [--reference <repository>] [--] <repository> [<path>]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
@@ -69,7 +69,11 @@ add::
to the changeset to be committed next to the current
project: the current project is termed the "superproject".
+
-This requires two arguments: <repository> and <path>.
+This requires at least one argument: <repository>. The optional
+argument <path> is the relative location for the cloned submodule
+to exist in the superproject. If <path> is not given, the
+"humanish" part of the source repository is used ("repo" for
+"/path/to/repo.git" and "foo" for "host.xz:foo/.git").
+
<repository> is the URL of the new submodule's origin repository.
This may be either an absolute URL, or (if it begins with ./
diff --git a/git-submodule.sh b/git-submodule.sh
index bfbd36b..0c617eb 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,7 +5,7 @@
# Copyright (c) 2007 Lars Hjemli
dashless=$(basename "$0" | sed -e 's/-/ /')
-USAGE="[--quiet] add [-b branch] [--reference <repository>] [--] <repository> <path>
+USAGE="[--quiet] add [-b branch] [--reference <repository>] [--] <repository> [<path>]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
or: $dashless [--quiet] init [--] [<path>...]
or: $dashless [--quiet] update [--init] [-N|--no-fetch] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
@@ -160,6 +160,11 @@ cmd_add()
repo=$1
path=$2
+ if test -z "$path"; then
+ path=$(echo "$repo" |
+ sed -e 's|/$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g')
+ fi
+
if test -z "$repo" -o -z "$path"; then
usage
fi
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 0f2ccc6..a0cc99a 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -306,4 +306,20 @@ test_expect_success 'submodule <invalid-path> warns' '
'
+test_expect_success 'add submodules without specifying an explicit path' '
+ mkdir repo &&
+ cd repo &&
+ git init &&
+ echo r >r &&
+ git add r &&
+ git commit -m "repo commit 1" &&
+ cd .. &&
+ git clone --bare repo/ bare.git &&
+ cd addtest &&
+ git submodule add "$submodurl/repo" &&
+ git config -f .gitmodules submodule.repo.path repo &&
+ git submodule add "$submodurl/bare.git" &&
+ git config -f .gitmodules submodule.bare.path bare
+'
+
test_done
--
1.6.4.1.246.g7bae7.dirty
^ permalink raw reply related
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Alex Riesen @ 2009-08-28 19:20 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Pitre, David Reiss, git
In-Reply-To: <20090828191521.GA12292@coredump.intra.peff.net>
On Fri, Aug 28, 2009 at 21:15, Jeff King<peff@peff.net> wrote:
> On Fri, Aug 28, 2009 at 09:03:19PM +0200, Alex Riesen wrote:
>
>> +unsigned long approxidate(const char *date)
>> +{
>> + struct timeval tv;
>> + gettimeofday(&tv, NULL);
>> + return approxidate_relative(date, &tv);
>> +}
>
> This now always calls gettimeofday, whereas the original approxidate
> only did if parse_date failed.
Oh, bugger...
> On the other hand, refactoring the relative date code into its own
> function is probably a good thing in the long run.
Exactly.
^ permalink raw reply
* Re: [BUG] git stash refuses to save after "add -N"
From: Jeff King @ 2009-08-28 19:22 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20090828190531.GB11488@coredump.intra.peff.net>
On Fri, Aug 28, 2009 at 03:05:31PM -0400, Jeff King wrote:
> For the index case, we unfortunately cannot represent the situation in
> the index using a tree, which means we cannot have a stash that doesn't
> lose information. So we have to choose either dropping those index
> entries, inserting them as blank files, or inserting them with
> working-tree contents.
Actually, you _could_ try representing the information by shoe-horning
it into the tree. For example, by allocating a bit of the mode as
"intent-to-add". That seems pretty ugly to me, though.
You could also try to stick the information in the stash's commit
message and recreate it during "stash apply". But again, that feels kind
of ugly.
-Peff
^ permalink raw reply
* Generating patches/Cherry Picking for a large number of commits
From: Alydis @ 2009-08-28 19:26 UTC (permalink / raw)
To: git
Hi,
Newly converted git user here. I've stopped working with Subversion
ever since working with the Linux kernel has introduced me to git, and
never looked back!
I am currently working on a project in which I'm trying to backport
the powerpc boot-wrapper and device tree handling from Linux 2.6.30
into Linux 2.6.21. We have some third party vendor code that is not
ready for the (new) completely fair scheduler just yet. Yet, our BSP
relies on cuImage and the DTS files.
The approach I'm taking is to try to cherry-pick any commits between
v2.6.21 and v2.6.30 on the Linux kernel git repository that touch any
file in the arch/powerpc/boot directory into a v2.6.21 branch (and
pray that the conflicts are manageable).
I've tried something along these lines:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
cd linux-2.6
git checkout -b mybranch v2.6.21
git format-patch -o patches v2.6.21..v2.6.30 arch/powerpc/boot
git am -3 patches/*
But, to my dismay, format-patch here tears apart the commits and
applies ONLY the hunks that apply to the arch/powerpc/boot directory.
What I'd much rather do is obtain a list of commits that apply to
arch/powerpc/boot; but, then apply the entire patch.
I'm a bit lost at how to proceed at this point? Do I need to write my
own script that uses git-log to grab the commit hashes that I want,
then call format-patch (or diff/apply/etc) individually on each of
them? I realize I'll have to handle patch numbering myself, if I were
to do that (luckily, I believe format-patch allows you to specify the
starting number). I also know at some point, I'll have to drill down
into individual commits and do some more detailed cherry picking to
form the desired patch series. This script seems like a good deal of
work for me... so before I go off and start it, I was wondering if the
git gurus have any clever solutions for me?
Thanks,
Tommy Wang
^ permalink raw reply
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Nicolas Pitre @ 2009-08-28 19:27 UTC (permalink / raw)
To: Alex Riesen; +Cc: Jeff King, David Reiss, git
In-Reply-To: <81b0412b0908281208h20aa6e81od3d6567fdffa0dec@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1618 bytes --]
On Fri, 28 Aug 2009, Alex Riesen wrote:
> On Fri, Aug 28, 2009 at 21:00, Nicolas Pitre<nico@cam.org> wrote:
> >> >> Microsoft's compiler and libraries? MacOSX?
> >> >
> >> > Are you saying you know those to be platforms with problems, or are you
> >> > asking whether those platforms will have problems?
> >>
> >> Both: MS never had weak/vague linkage, but I don't know about MacOSX.
> >
> > This is not about weak or vague linkage. This is plain basic linker
> > feature where no library object needs to be linked if there is no symbol
> > to resolve.
>
> Maybe I missed something, but wasn't the idea to overwrite gettimeofday
> with a public gettimeofday, defined in one of the object files?
Yes, in test-date.o.
> And shouldn't a linker complain regarding duplicated symbols, unless
> the other (library) symbol is defined as a weak symbol, allowing
> overriding it with another symbol of stronger linkage?
Normally a linker would search for new objects to link only when there
are still symbols to resolve. If the library is well architected (mind
you I don't know if that is the case on Windows or OS X) you should find
many small object files in a library, so to have only related functions
together in a single object for only the needed code to be linked in the
final binary. Hence the printf symbol should be in a separate object
file than gettimeofday, etc.
Only if the library's object file containing gettimeofday also contains
another symbol pulled by the linker will you see a duplicated symbol
error. But this is still a possibility. So your proposal is probably
cleaner.
Nicolas
^ permalink raw reply
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Alex Riesen @ 2009-08-28 19:33 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Pitre, David Reiss, git
In-Reply-To: <81b0412b0908281220o1c378d5dn6ed52c8d55a9cdec@mail.gmail.com>
From fe67532bdf095dc9ebc0c7dd67be384e807a197c Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Fri, 28 Aug 2009 20:59:59 +0200
Subject: [PATCH] Add date formatting functions with current time explicitely formatted
It should allow safe testing of this part of the code.
---
Alex Riesen, Fri, Aug 28, 2009 21:20:50 +0200:
> On Fri, Aug 28, 2009 at 21:15, Jeff King<peff@peff.net> wrote:
> > On Fri, Aug 28, 2009 at 09:03:19PM +0200, Alex Riesen wrote:
> >
> >> +unsigned long approxidate(const char *date)
> >> +{
> >> + struct timeval tv;
> >> + gettimeofday(&tv, NULL);
> >> + return approxidate_relative(date, &tv);
> >> +}
> >
> > This now always calls gettimeofday, whereas the original approxidate
> > only did if parse_date failed.
>
> Oh, bugger...
>
Rather like this, I mean :)
cache.h | 2 +
date.c | 150 ++++++++++++++++++++++++++++++++++++--------------------------
2 files changed, 89 insertions(+), 63 deletions(-)
diff --git a/cache.h b/cache.h
index dd7f71e..3fb0166 100644
--- a/cache.h
+++ b/cache.h
@@ -731,9 +731,11 @@ enum date_mode {
};
const char *show_date(unsigned long time, int timezone, enum date_mode mode);
+const char *show_date_relative(unsigned long time, int tz, const struct timeval *now);
int parse_date(const char *date, char *buf, int bufsize);
void datestamp(char *buf, int bufsize);
unsigned long approxidate(const char *);
+unsigned long approxidate_relative(const char *date, const struct timeval *now);
enum date_mode parse_date_format(const char *format);
#define IDENT_WARN_ON_NO_NAME 1
diff --git a/date.c b/date.c
index 409a17d..171e68f 100644
--- a/date.c
+++ b/date.c
@@ -84,6 +84,67 @@ static int local_tzoffset(unsigned long time)
return offset * eastwest;
}
+const char *show_date_relative(unsigned long time, int tz, const struct timeval *now)
+{
+ static char timebuf[100 /* TODO: can be optimized */];
+ unsigned long diff;
+ if (now->tv_sec < time)
+ return "in the future";
+ diff = now->tv_sec - time;
+ if (diff < 90) {
+ snprintf(timebuf, sizeof(timebuf), "%lu seconds ago", diff);
+ return timebuf;
+ }
+ /* Turn it into minutes */
+ diff = (diff + 30) / 60;
+ if (diff < 90) {
+ snprintf(timebuf, sizeof(timebuf), "%lu minutes ago", diff);
+ return timebuf;
+ }
+ /* Turn it into hours */
+ diff = (diff + 30) / 60;
+ if (diff < 36) {
+ snprintf(timebuf, sizeof(timebuf), "%lu hours ago", diff);
+ return timebuf;
+ }
+ /* We deal with number of days from here on */
+ diff = (diff + 12) / 24;
+ if (diff < 14) {
+ snprintf(timebuf, sizeof(timebuf), "%lu days ago", diff);
+ return timebuf;
+ }
+ /* Say weeks for the past 10 weeks or so */
+ if (diff < 70) {
+ snprintf(timebuf, sizeof(timebuf), "%lu weeks ago", (diff + 3) / 7);
+ return timebuf;
+ }
+ /* Say months for the past 12 months or so */
+ if (diff < 360) {
+ snprintf(timebuf, sizeof(timebuf), "%lu months ago", (diff + 15) / 30);
+ return timebuf;
+ }
+ /* Give years and months for 5 years or so */
+ if (diff < 1825) {
+ unsigned long years = (diff + 183) / 365;
+ unsigned long months = (diff % 365 + 15) / 30;
+ int n;
+ n = snprintf(timebuf, sizeof(timebuf), "%lu year%s",
+ years, (years > 1 ? "s" : ""));
+ if (months)
+ snprintf(timebuf + n, sizeof(timebuf) - n,
+ ", %lu month%s ago",
+ months, (months > 1 ? "s" : ""));
+ else
+ snprintf(timebuf + n, sizeof(timebuf) - n,
+ " ago");
+ return timebuf;
+ }
+ /* Otherwise, just years. Centuries is probably overkill. */
+ snprintf(timebuf, sizeof(timebuf), "%lu years ago", (diff + 183) / 365);
+ return timebuf;
+
+}
+
const char *show_date(unsigned long time, int tz, enum date_mode mode)
{
struct tm *tm;
@@ -95,63 +156,9 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)
}
if (mode == DATE_RELATIVE) {
- unsigned long diff;
struct timeval now;
gettimeofday(&now, NULL);
- if (now.tv_sec < time)
- return "in the future";
- diff = now.tv_sec - time;
- if (diff < 90) {
- snprintf(timebuf, sizeof(timebuf), "%lu seconds ago", diff);
- return timebuf;
- }
- /* Turn it into minutes */
- diff = (diff + 30) / 60;
- if (diff < 90) {
- snprintf(timebuf, sizeof(timebuf), "%lu minutes ago", diff);
- return timebuf;
- }
- /* Turn it into hours */
- diff = (diff + 30) / 60;
- if (diff < 36) {
- snprintf(timebuf, sizeof(timebuf), "%lu hours ago", diff);
- return timebuf;
- }
- /* We deal with number of days from here on */
- diff = (diff + 12) / 24;
- if (diff < 14) {
- snprintf(timebuf, sizeof(timebuf), "%lu days ago", diff);
- return timebuf;
- }
- /* Say weeks for the past 10 weeks or so */
- if (diff < 70) {
- snprintf(timebuf, sizeof(timebuf), "%lu weeks ago", (diff + 3) / 7);
- return timebuf;
- }
- /* Say months for the past 12 months or so */
- if (diff < 360) {
- snprintf(timebuf, sizeof(timebuf), "%lu months ago", (diff + 15) / 30);
- return timebuf;
- }
- /* Give years and months for 5 years or so */
- if (diff < 1825) {
- unsigned long years = (diff + 183) / 365;
- unsigned long months = (diff % 365 + 15) / 30;
- int n;
- n = snprintf(timebuf, sizeof(timebuf), "%lu year%s",
- years, (years > 1 ? "s" : ""));
- if (months)
- snprintf(timebuf + n, sizeof(timebuf) - n,
- ", %lu month%s ago",
- months, (months > 1 ? "s" : ""));
- else
- snprintf(timebuf + n, sizeof(timebuf) - n,
- " ago");
- return timebuf;
- }
- /* Otherwise, just years. Centuries is probably overkill. */
- snprintf(timebuf, sizeof(timebuf), "%lu years ago", (diff + 183) / 365);
- return timebuf;
+ return show_date_relative(time, tz, &now);
}
if (mode == DATE_LOCAL)
@@ -866,19 +873,13 @@ static const char *approxidate_digit(const char *date, struct tm *tm, int *num)
return end;
}
-unsigned long approxidate(const char *date)
+static unsigned long approximation(const char *date, const struct timeval *tv)
{
int number = 0;
struct tm tm, now;
- struct timeval tv;
time_t time_sec;
- char buffer[50];
- if (parse_date(date, buffer, sizeof(buffer)) > 0)
- return strtoul(buffer, NULL, 10);
-
- gettimeofday(&tv, NULL);
- time_sec = tv.tv_sec;
+ time_sec = tv->tv_sec;
localtime_r(&time_sec, &tm);
now = tm;
for (;;) {
@@ -899,3 +900,26 @@ unsigned long approxidate(const char *date)
tm.tm_year--;
return mktime(&tm);
}
+
+unsigned long approxidate_relative(const char *date, const struct timeval *tv)
+{
+ char buffer[50];
+
+ if (parse_date(date, buffer, sizeof(buffer)) > 0)
+ return strtoul(buffer, NULL, 10);
+
+ return approximation(date, tv);
+}
+
+unsigned long approxidate(const char *date)
+{
+ struct timeval tv;
+ char buffer[50];
+
+ if (parse_date(date, buffer, sizeof(buffer)) > 0)
+ return strtoul(buffer, NULL, 10);
+
+ gettimeofday(&tv, NULL);
+ return approximation(date, &tv);
+}
+
--
1.6.4.1.261.gf9874
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox