* 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
* Re: Using git to track my PhD thesis, couple of questions
From: Paolo Bonzini @ 2009-08-28 15:50 UTC (permalink / raw)
To: seanh; +Cc: git
In-Reply-To: <20090828133708.GA11146@kisimul>
On 08/28/2009 03:37 PM, seanh wrote:
> In response to Matthieu and Paolo, I'm not sure I understand the git
> internals involved in the discussion around merge --squash, I had a
> feeling this would produce a 'merge' that git in some sense would 'not
> know about', since it sounds complex and I don't understand it I don't
> think I want to go there.
Yes, the problem is that git does not track what happens when you do
"git merge --squash", which makes it harder to do merges after some time
(because of conflicts).
The solution I gave (and Matthieu explained how it works, even though
it's very technical) is a way to "explain" git what you did. If you try
it on a fake example with gitk, you should understand it better.
mkdir test
cd test
# import
git init
echo a > test
git add a
git commit -m1
# some changes happen in your local "fine grained" branch
git checkout -b local
echo b > test
git commit -a -m2
echo c >> test
git commit -a -m3 ##<<<
# the magic incantation brings those commit to master
# (first two commands) and teaches git what happened (last two)
git checkout master
git merge --squash local; git commit -m'merge 1' ##<<<
git checkout local
git merge master ##<<<
# more local changes
sed -i s/b/d/ test
git commit -a -m4
echo z >> test
git commit -a -m5 ##<<<
# the magic incantation, again
git checkout master
git merge --squash local; git commit -m'merge 1' ##<<<
git checkout local
git merge master ##<<<
Use gitk at the points indicated with ##<<<
It is actually very similar to what you chose to do. My commits to
master, in practice, are your tags. You may want to see how gitk's
graphs looks in both scenarios, and choose the one that you prefer.
Hope this helps!
Paolo
^ permalink raw reply
* Re: Merging in Subversion 1.5 (was: Re: Using git to track my PhD thesis, couple of questions)
From: Matthias Andree @ 2009-08-28 15:44 UTC (permalink / raw)
To: Avery Pennarun, Jakub Narebski; +Cc: git, Matthieu Moy
In-Reply-To: <32541b130908280829s6fcebbe5ja84b10e649de1eb3@mail.gmail.com>
Am 28.08.2009, 17:29 Uhr, schrieb Avery Pennarun <apenwarr@gmail.com>:
> I think they probably meant that it's the client's responsibility to
> set the property correctly, not the server's, and if your client is
> too old any you do a merge, it'll forget to set svn:mergeinfo, causing
> confusion for everyone. There's discussion in the svn book
> (http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html) but
> nothing implies that it's a non-replicated property. Indeed, I can
> see no particular reason that anyone would want it to be, for the
> reasons you specify.
It is replicated, and the common remedy against older clients is to refuse
commits from those clients that do not support mergeinfo. This is done by
defining a repository hook on the server side that validates this. AFAIR
such a hook example ships with SVN.
--
Matthias Andree
^ permalink raw reply
* Re: [PATCH] Fix overridable written with an extra 'e'
From: Johannes Schindelin @ 2009-08-28 15:31 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Junio C Hamano, Todd Zullinger, Nanako Shiraishi, git
In-Reply-To: <32541b130908280815y78f95140re679c336fbd17443@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1041 bytes --]
Hi,
On Fri, 28 Aug 2009, Avery Pennarun wrote:
> On Fri, Aug 28, 2009 at 4:53 AM, Junio C Hamano<gitster@pobox.com> wrote:
> > Hmph, I don't know. Googling "overrideable" suggests "Did you mean
> > overridable?" which is enough clue for me.
>
> Using a similar system, the Google hit count:
>
> overrideable: 26,900
> overridable: 339,000
> overridden: 2,280,000
But of course, "overidable" means "able to be overridden", not
"overridden".
> Which agrees with my intuition that you can get away with overridable,
> but it's much more common to just use overridden.
>
> "override" of course comes from "ride" (181,000,000). A horse can be
> ridden (10,500,000) if it's ridable (82,500).
>
> The bad news: rideable (201,000).
>
> http://www.merriam-webster.com/dictionary/ridable shows rideable as
> the preferred spelling, but accepts both.
Actually, I do not trust the bda speling of the many internet content
providers as much as Merriam Webster, so of all your analysis, I find this
the most important finding.
Ciao,
Dscho
^ permalink raw reply
* Re: Merging in Subversion 1.5 (was: Re: Using git to track my PhD thesis, couple of questions)
From: Avery Pennarun @ 2009-08-28 15:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Matthias Andree, git, Matthieu Moy
In-Reply-To: <m3ocq0km5m.fsf_-_@localhost.localdomain>
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. 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 they probably meant that it's the client's responsibility to
set the property correctly, not the server's, and if your client is
too old any you do a merge, it'll forget to set svn:mergeinfo, causing
confusion for everyone. There's discussion in the svn book
(http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html) but
nothing implies that it's a non-replicated property. Indeed, I can
see no particular reason that anyone would want it to be, for the
reasons you specify.
> * 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.
Tracking cherry picks in git would be really nice *sometimes*, but it
creates a tradeoff where you then have to slurp in huge amounts of
history that you might not want. In svn, this tradeoff doesn't exist,
since anything you cherry pick must have already existed on the server
anyway, and can never go away.
> * 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. (It's handiest if your team has a policy of
always using --no-ff when merging into trunk, which makes git act a
bit more like svn's merge tracking. I realize this is a bit heretical
to suggest on the git list, but I appreciate that the option exists
despite its heresy :))
Have fun,
Avery
^ 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