* 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: [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
* [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 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
* 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] 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
* 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: 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: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: 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
* [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: 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
* 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: 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
* [RFC PATCH] upload-pack: expand capability advertises additional refs
From: Shawn O. Pearce @ 2009-08-28 17:30 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nicolas Pitre, Julian Phillips, Daniel Barkalow,
Johannes Schindelin
In-Reply-To: <20090826021057.GL1033@spearce.org>
The expand capability and associated command permits the client
to ask for information about refs which were not in the initial
advertisement sent when the connection was first opened.
In the below exchange the server initially only advertises its
current HEAD, refs/heads and refs/tags namespaces. However,
the client has been instructed to fetch anything which matches
refs/remotes/jc/*.
Since no matching refs appeared in the initial advertisement,
the client requests the server to expand the desired pattern,
and terminates its expand request list with a flush.
Upon receiving a flush from the client, the server displays any
local refs which match any of the expand patterns requested,
and then closes this secondary advertisement list with a flush.
If no refs matched, the server immediately returns a flush.
If multiple expand patterns match the same ref, the ref is returned
only once in the secondary advertisement, avoid confusing the client
with duplicate results.
S: 008f... HEAD\0...include-tag expand
S: 0043... refs/heads/build-next
S: 0040... refs/tags/v1.6.4.1
S: 0043... refs/tags/v1.6.4.1^{}
S: 0000
C: 001dexpand refs/remotes/jc/*
C: 0000
S: 0043... refs/remotes/jc/maint
S: 0044... refs/remotes/jc/master
S: 0000
C: 0031want ...
C: 0000
Repository owners can control the set of refs which are sent as part
of the initial advertisement by configuring upload.advertise in the
repository configuration file. If not set this is assumed to be
"refs/*", matching the prior behavior of advertising every local ref.
Fetch clients which are not using the anonymous git:// protocol
and which do not support the expand protocol extension may still
force the server to expand its configured upload.advertise set by
passing the --expand=<pattern> command line flag as part of the
--upload-pack= command line given to clone or fetch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Shawn O. Pearce <sop@google.com>
---
This is roughly my final server side version of this proposal.
I still need to write the client code, but want to at least get
this out there for further discussion.
Documentation/config.txt | 10 +++
Documentation/git-upload-pack.txt | 10 +++-
upload-pack.c | 131 +++++++++++++++++++++++++++++++++++--
3 files changed, 143 insertions(+), 8 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 5256c7f..07907b6 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1489,6 +1489,16 @@ transfer.unpackLimit::
not set, the value of this variable is used instead.
The default value is 100.
+upload.advertise::
+ The default set of refs to advertise when a fetch or
+ clone client connects to this repository. Additional
+ local refs not in the default advertisement can still
+ be guessed and requested by clients through additional
+ network round trips. Refs may be expressed as a complete
+ name ("refs/heads/master") or as a pattern expected by
+ remote.<name>.fetch (such as "refs/heads/*"). If not
+ specified, all refs are advertised ("refs/*").
+
url.<base>.insteadOf::
Any URL that starts with this value will be rewritten to
start, instead, with <base>. In cases where some site serves a
diff --git a/Documentation/git-upload-pack.txt b/Documentation/git-upload-pack.txt
index b8e49dc..4cd9cc0 100644
--- a/Documentation/git-upload-pack.txt
+++ b/Documentation/git-upload-pack.txt
@@ -8,7 +8,7 @@ git-upload-pack - Send objects packed back to git-fetch-pack
SYNOPSIS
--------
-'git upload-pack' [--strict] [--timeout=<n>] <directory>
+'git upload-pack' [--strict] [--timeout=<n>] [--expand=<pattern> ...] <directory>
DESCRIPTION
-----------
@@ -30,6 +30,14 @@ OPTIONS
--timeout=<n>::
Interrupt transfer after <n> seconds of inactivity.
+--expand=<pattern>::
+ Expand the requested pattern and advertise matching refs,
+ even if those refs were not matched by upload.advertise.
+ This option may be repeated to request expansion of more
+ than one pattern. This option is intended only as an
+ escape hatch for older clients to fetch from a server
+ which has hidden interesting refs.
+
<directory>::
The repository to sync from.
diff --git a/upload-pack.c b/upload-pack.c
index 4d8be83..890c1c5 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -10,6 +10,8 @@
#include "revision.h"
#include "list-objects.h"
#include "run-command.h"
+#include "remote.h"
+#include "string-list.h"
static const char upload_pack_usage[] = "git upload-pack [--strict] [--timeout=nn] <dir>";
@@ -30,6 +32,19 @@ static int multi_ack, nr_our_refs;
static int use_thin_pack, use_ofs_delta, use_include_tag;
static int no_progress, daemon_mode;
static int shallow_nr;
+
+struct adv_ref {
+ struct adv_ref *next;
+ char *name;
+ unsigned pattern:1;
+};
+static struct adv_ref *to_advertise;
+static struct adv_ref **advertise_tail = &to_advertise;
+static int configured_advertise;
+
+static struct ref *local_refs;
+static struct ref **refs_tail = &local_refs;
+
static struct object_array have_obj;
static struct object_array want_obj;
static unsigned int timeout;
@@ -470,6 +485,69 @@ static int get_common_commits(void)
}
}
+static void push_advertise(const char *name)
+{
+ struct adv_ref *adv = xcalloc(1, sizeof(*adv));
+ adv->name = xstrdup(name);
+ adv->pattern = !!strchr(adv->name, '*');
+ *advertise_tail = adv;
+ advertise_tail = &adv->next;
+}
+
+static int upload_pack_config(const char *var, const char *value, void *cb)
+{
+ if (strcmp(var, "upload.advertise") == 0) {
+ configured_advertise = 1;
+ push_advertise(value);
+ return 0;
+ }
+
+ return git_default_config(var, value, cb);
+}
+
+static int send_ref(struct string_list_item *item, void *cb_data);
+static void send_refs(void)
+{
+ struct ref *to_send = NULL, **tail = &to_send;
+ struct ref *ref;
+ struct adv_ref *adv, *next_adv;
+ struct string_list sorted_names;
+
+ for (adv = to_advertise; adv; adv = next_adv) {
+ struct refspec spec;
+
+ memset(&spec, 0, sizeof(spec));
+ spec.pattern = adv->pattern;
+ spec.src = adv->name;
+ spec.dst = adv->name;
+ next_adv = adv->next;
+ get_fetch_map(local_refs, &spec, &tail, 1);
+
+ free(adv->name);
+ free(adv);
+ }
+ to_advertise = NULL;
+ advertise_tail = &to_advertise;
+
+ /* We may have duplicate copies of the same ref above, if
+ * two advertise records matched the same local name. To
+ * avoid sending the same ref twice to the client, we put
+ * them into a sorted list and then skip duplicates as we
+ * output them.
+ */
+ memset(&sorted_names, 0, sizeof(sorted_names));
+ for (ref = to_send; ref; ref = ref->next)
+ string_list_append(ref->name, &sorted_names)->util = ref;
+ sort_string_list(&sorted_names);
+
+ ref = NULL;
+ for_each_string_list(send_ref, &sorted_names, &ref);
+
+ string_list_clear(&sorted_names, 0);
+ free_refs(to_send);
+ packet_flush(1);
+}
+
static void receive_needs(void)
{
struct object_array shallows = {0, 0, NULL};
@@ -484,11 +562,22 @@ static void receive_needs(void)
unsigned char sha1_buf[20];
len = packet_read_line(0, line, sizeof(line));
reset_timeout();
- if (!len)
+ if (!len) {
+ if (to_advertise) {
+ send_refs();
+ continue;
+ }
break;
+ }
if (debug_fd)
write_in_full(debug_fd, line, len);
+ if (!prefixcmp(line, "expand ")) {
+ if (line[len - 1] == '\n')
+ line[len - 1] = 0;
+ push_advertise(line + 7);
+ continue;
+ }
if (!prefixcmp(line, "shallow ")) {
unsigned char sha1[20];
struct object *object;
@@ -603,13 +692,22 @@ static void receive_needs(void)
free(shallows.objects);
}
-static int send_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
+static int send_ref(struct string_list_item *item, void *cb_data)
{
static const char *capabilities = "multi_ack thin-pack side-band"
" side-band-64k ofs-delta shallow no-progress"
- " include-tag";
- struct object *o = parse_object(sha1);
+ " include-tag expand";
+ struct ref **last_ref = cb_data;
+ struct ref *ref = item->util;
+ const char *refname = ref->name;
+ const unsigned char *sha1 = ref->new_sha1;
+ struct object *o;
+
+ if (*last_ref && !strcmp(refname, (*last_ref)->name))
+ return 0;
+ *last_ref = ref;
+ o = parse_object(sha1);
if (!o)
die("git upload-pack: cannot find object %s:", sha1_to_hex(sha1));
@@ -631,12 +729,26 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
return 0;
}
+static int scan_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
+{
+ struct ref *r = alloc_ref(refname);
+ hashcpy(r->new_sha1, sha1);
+ *refs_tail = r;
+ refs_tail = &r->next;
+ return 0;
+}
+
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;
--
1.6.4.1.341.gf2a44
^ permalink raw reply related
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Nicolas Pitre @ 2009-08-28 17:28 UTC (permalink / raw)
To: Jeff King; +Cc: Alex Riesen, David Reiss, git
In-Reply-To: <20090828150212.GA6013@coredump.intra.peff.net>
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.
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:
diff --git a/test-date.c b/test-date.c
index 62e8f23..0bcd0c9 100644
--- a/test-date.c
+++ b/test-date.c
@@ -1,5 +1,10 @@
#include "cache.h"
+int gettimeofday(struct timeval *tv, struct timezone *tz)
+{
+ return 0;
+}
+
int main(int argc, char **argv)
{
int i;
Result:
$ ./test-date now
now -> bad -> Wed Dec 31 19:00:00 1969
now -> Tue Jan 22 10:48:24 10199
So this seems to work. ;-)
Nicolas
^ permalink raw reply related
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Jeff King @ 2009-08-28 17:15 UTC (permalink / raw)
To: Alex Riesen; +Cc: David Reiss, git
In-Reply-To: <81b0412b0908281000l41c862f9ye52da7251014c4f7@mail.gmail.com>
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.
-Peff
^ permalink raw reply
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Alex Riesen @ 2009-08-28 17:00 UTC (permalink / raw)
To: Jeff King; +Cc: David Reiss, git
In-Reply-To: <20090828150212.GA6013@coredump.intra.peff.net>
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?
^ permalink raw reply
* Running git server from NAS
From: John @ 2009-08-28 16:31 UTC (permalink / raw)
To: git
Hello,
I need to have a git server available for multiple users, but I want the git
home directory and repositories on NAS due to data backup, and minimal down
time if the Linux host goes down I can start another host pointing to the git
home directory on the NAS.
What would be the best way to configure this?
Thanks
-John
^ permalink raw reply
* Re: Merging in Subversion 1.5
From: Avery Pennarun @ 2009-08-28 16:34 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Matthias Andree, git, Matthieu Moy
In-Reply-To: <200908281819.10135.jnareb@gmail.com>
On Fri, Aug 28, 2009 at 4:19 PM, Jakub Narebski<jnareb@gmail.com> wrote:
> On Fri, 28 Aug 2009, Avery Pennarun wrote:
>> On Fri, Aug 28, 2009 at 3:12 PM, Jakub Narebski<jnareb@gmail.com> wrote:
>> > * You have to explicitely enable using svn:mergeinfo in log and blame
>>
>> Conversely, in git you can basically disable it using --first-parent,
>> which is sometimes handy. [...]
>
> In git-log. But in git-blame?
I don't know about git-blame, as I rarely use it. If it doesn't
support --first-parent, I imagine it would be easy to add, if it were
important to someone.
Avery
^ permalink raw reply
* Re: Merging in Subversion 1.5
From: Matthias Andree @ 2009-08-28 16:28 UTC (permalink / raw)
To: git@vger.kernel.org; +Cc: Jakub Narebski
In-Reply-To: <200908281819.10135.jnareb@gmail.com>
[culling most of Cc: list]
Am 28.08.2009, 18:19 Uhr, schrieb Jakub Narebski <jnareb@gmail.com>:
> On Fri, 28 Aug 2009, Avery Pennarun wrote:
>> On Fri, Aug 28, 2009 at 3:12 PM, Jakub Narebski<jnareb@gmail.com> wrote:
>
>> > From what I understand (from what I have read, and browsed, and
>> > lurged, and noticed) is that Subversion 1.5+ does merge tracking, but
>> > in very different way that in Git:
>> >
>> > * the svn:mergeinfo is client-side property; if I understand
>> > correctly this would help you in repeated merges, but not anyone
>> > other
>>
>> I don't believe there is such a thing as a "client-side property" in
>> svn.
>
> What about svn:ignore or svn:mimetype (IIRC) property?
All this is committed to the repository, so there isn't a question of if
it's client-side in a sense of "local to the client/checkout". Some
properties (such as svn:mergeinfo) require a bit of additional server-side
support, but that's about it.
Oh, and to complicate matters, let me mention revprops (such as
svn:log). SCNR :^)
--
Matthias Andree
^ permalink raw reply
* Re: bzr to git syncing
From: Sverre Rabbelier @ 2009-08-28 16:19 UTC (permalink / raw)
To: Alex Bennee; +Cc: git, David Reitter
In-Reply-To: <b2cdc9f30908280902m22d594bam3c70259d4c296e52@mail.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.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Merging in Subversion 1.5
From: Jakub Narebski @ 2009-08-28 16:19 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Matthias Andree, git, Matthieu Moy
In-Reply-To: <32541b130908280829s6fcebbe5ja84b10e649de1eb3@mail.gmail.com>
On Fri, 28 Aug 2009, Avery Pennarun wrote:
> On Fri, Aug 28, 2009 at 3:12 PM, Jakub Narebski<jnareb@gmail.com> wrote:
> > From what I understand (from what I have read, and browsed, and
> > lurged, and noticed) is that Subversion 1.5+ does merge tracking, but
> > in very different way that in Git:
> >
> > * the svn:mergeinfo is client-side property; if I understand
> > correctly this would help you in repeated merges, but not anyone
> > other
>
> I don't believe there is such a thing as a "client-side property" in
> svn.
What about svn:ignore or svn:mimetype (IIRC) property?
> I see someone said this on stackoverflow
> (http://stackoverflow.com/questions/1156698/are-svn-merges-idempotent)
> but I'm pretty sure they were either mistaken or using a different
> definition of "client-side."
I think I got this (wrong?) impression from there.
> > * svn:mergeinfo contains _per-file_ merge info, so it is much, much
> > more "chatty" than Git multiple parents. This might be more
> > powerfull approach, in the same sense that more advanced merge
> > strategies that 3-way merge were more powerfull -- but 3-way merge
> > is best because it is simple (and either it is simple that 3-way
> > merge is enough, or complicated so manual intervention is required).
>
> svn people really love their cherry-picks and want to keep track of
> which things get cherry picked from one branch to another. This is
> nice (at least for informational purposes) although they go through
> some probably-unnecessary contortions *after* doing this, including
> splitting a merge from "maint" into "master" into two sequential
> merges, if you've previously cherry-picked a commit from master into
> maint. The above svn book link describes this in a bit more detail.
>
> I don't think that behaviour would be much help in any situation I've
> ever experienced, so I agree with your comment that 3-way merge is
> generally better.
Errr... what I meant here that I have read (on some blog, but either
I didn't bookmark it, or I can't find the bookmark) that svn:mergeinfo
is not as simple as listing _revisions_ which are merged (i.e. either
all parents, or additional parent), but it lists per-file merge
information, and can be quite large.
> > * You have to explicitely enable using svn:mergeinfo in log and blame
>
> Conversely, in git you can basically disable it using --first-parent,
> which is sometimes handy. [...]
In git-log. But in git-blame?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Using git to track my PhD thesis, couple of questions
From: demerphq @ 2009-08-28 16:12 UTC (permalink / raw)
To: seanh; +Cc: git
In-Reply-To: <20090828133708.GA11146@kisimul>
2009/8/28 seanh <seanh.nospam@gmail.com>:
> On Fri, Aug 28, 2009 at 12:21:42AM +0200, demerphq wrote:
>> As you can generate the PDF's from the latex then just hack gitweb to
>> let them download it from there.
>
> Unfortunately gitweb is written in Perl. But I know what you mean, it
> should in theory be possible for them to click on a 'Get PDF' link for a
> particular revision that causes the PDF to be built and returned to
> their browser.
What is unfortunate about that? Perl is a duct tape/swiss-army-knife
of the internet. Hacking gitweb to generate PDF's on the fly from
latex documents should be a fairly trivial hack, even if you aren't a
Perl hacker.
See:
http://search.cpan.org/~andrewf/LaTeX-Driver-0.08/lib/LaTeX/Driver.pm
for just one of many Perl modules to interface with with LaTeX.
Good luck.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: bzr to git syncing
From: Alex Bennee @ 2009-08-28 16:02 UTC (permalink / raw)
To: git, David Reitter
In-Reply-To: <F84D4C0F-1CEF-4853-84DB-B7927CBE62B3@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 807 bytes --]
2009/6/29 David Reitter <david.reitter@gmail.com>:
> Does anyone have experience syncing a Bzr repository to git?
> I would ideally want two-way syncing, but even the bzr->git route would be a
> start.
I've a sneaking suspicion a breakage has been introduced to either the
git-bzr script or
the bzr fast-import module. I say this as I have successfully pulled
from a bzr repo into
git before but having need to do it today and I get a crash in fast-import.
A few quick questions:
* What versions of git/bzr are you using (me: git 1.6.4, bzr 1.17)?
* Which git-bzr script are you using (me:
http://github.com/mcepl/git-bzr/tree/master)?
I've attached the fast-import crash I'm seeing. Are you seeing the
same sort of failure?
--
Alex, homepage: http://www.bennee.com/~alex/
http://www.half-llama.co.uk
[-- Attachment #2: fast_import_crash_21774 --]
[-- Type: application/octet-stream, Size: 1094 bytes --]
fast-import crash report:
fast-import process: 21774
parent process : 21773
at Fri Aug 28 16:54:14 2009
fatal: Corrupt mode: M 040000 - content
Most Recent Commands Before Crash
---------------------------------
commit refs/heads/bzr/upstream
mark :1
committer Alexander Sack <asac@jwsdot.com> 1181743954 +0200
data 39
M 644 inline build.sh
data 3963
M 644 inline chrome.manifest
data 192
M 644 inline config_build.sh
data 170
* M 040000 - content
Active Branch LRU
-----------------
active_branches = 1 cur, 5 max
pos clock name
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1) 0 refs/heads/bzr/upstream
Inactive Branches
-----------------
refs/heads/bzr/upstream:
status : active loaded dirty
tip commit : 0000000000000000000000000000000000000000
old tree : 0000000000000000000000000000000000000000
cur tree : 0000000000000000000000000000000000000000
commit clock: 0
last pack :
Marks
-----
exported to /export/src/debs/cbnlfox.git/.git/bzr-git/upstream-git-map
-------------------
END OF CRASH REPORT
^ permalink raw reply
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