# failing to send patches to the list 9 messages from 2007-07-13 to 2007-07-14. Participants: martin f krafft, Alex Riesen, Jeff King, Jakub Narebski, Eric Wong. Thread: https://gitlist.dev/t/9017 ## martin f krafft, 2007-07-13 09:30 Subject: failing to send patches to the list Message-ID: <20070713093050.GA18001@lapse.madduck.net> URL: https://gitlist.dev/e/20070713093050.GA18001%40lapse.madduck.net ``` Dear list, attached you may find two patches, which I've previously sent to the list with git format-patch -s --stdout | sendmail git@vger.kernel.org Even though my mail server seems to have delivered them correctly: Jul 13 10:53:32 albatross postfix/smtp[29758]: C404D895D6F: to=, relay=vger.kernel.org[209.132.176.167]:25, delay=2.2, delays=0.08/0.04/0.56/1.6, dsn=2.7.1, status=sent (250 2.7.1 Looks like Linux source DIFF email.. BF:; S932911AbXGMIxb) they never made it onto the list. What am I doing wrong? Should I resubmit the patches or is this enough for now? -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck spamtraps: madduck.bogus@madduck.net all software projects are done by iterative prototyping. some companies call their prototypes "releases", that's all. From 7b2bb44f78b8bc691bbc1445c6c333fdc281a788 Mon Sep 17 00:00:00 2001 From: martin f. krafft Date: Fri, 13 Jul 2007 11:09:05 +0200 Subject: [PATCH] fall back to mozilla's sha.h if openssl/sha.h is not available Uses $(CPP) to attempt to preprocess an include directive. If that fails, NO_OPENSSL is defined, causing the Makefile to fall back to using mozilla's SHA implementation. Signed-off-by: martin f. krafft --- Makefile | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index d7541b4..1676343 100644 --- a/Makefile +++ b/Makefile @@ -532,6 +532,12 @@ ifndef NO_CURL endif endif +HAS_OPENSSL := $(shell echo "\#include " \ + | $(CPP) -o/dev/null - 2>/dev/null || echo no) +ifeq "$(HAS_OPENSSL)" "no" + NO_OPENSSL = "openssl_sha.h_not_found" +endif + ifndef NO_OPENSSL OPENSSL_LIBSSL = -lssl ifdef OPENSSLDIR -- 1.5.3.rc1.7.gcae4 From 5f537c75774c5c0b45b74585ace4178738f251f0 Mon Sep 17 00:00:00 2001 From: martin f. krafft Date: Fri, 13 Jul 2007 11:09:46 +0200 Subject: [PATCH] Provide --stdlayout option for git-svn to set trunk,tags,branches to defaults The --stdlayout option to git-svn init initialises the default Subversion values of trunk,tags,branches: -T trunk -b branches -t tags. If any of the -T/-t/-b options are given in addition, they are given preference. Signed-off-by: martin f. krafft --- Documentation/git-svn.txt | 6 +++++- git-svn.perl | 8 +++++++- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 0a210e4..9e74b27 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -44,10 +44,14 @@ COMMANDS --tags=;; -b;; --branches=;; +--stdlayout;; These are optional command-line options for init. Each of these flags can point to a relative repository path (--tags=project/tags') or a full url - (--tags=https://foo.org/project/tags) + (--tags=https://foo.org/project/tags). The option --stdlayout is + a shorthand way of setting trunk,tags,branches as the relative paths, + which is the Subversion default. If any of the other options are given + as well, they take precedence. --no-metadata;; Set the 'noMetadata' option in the [svn-remote] config. --use-svm-props;; diff --git a/git-svn.perl b/git-svn.perl index b3dffcc..5b443ee 100755 --- a/git-svn.perl +++ b/git-svn.perl @@ -77,11 +77,12 @@ my %fc_opts = ( 'follow-parent|follow!' => \$Git::SVN::_follow_parent, \$Git::SVN::_repack_flags, %remote_opts ); -my ($_trunk, $_tags, $_branches); +my ($_trunk, $_tags, $_branches, $_stdlayout); my %icv; my %init_opts = ( 'template=s' => \$_template, 'shared:s' => \$_shared, 'trunk|T=s' => \$_trunk, 'tags|t=s' => \$_tags, 'branches|b=s' => \$_branches, 'prefix=s' => \$_prefix, + 'stdlayout' => \$_stdlayout, 'minimize-url|m' => \$Git::SVN::_minimize_url, 'no-metadata' => sub { $icv{noMetadata} = 1 }, 'use-svm-props' => sub { $icv{useSvmProps} = 1 }, @@ -296,6 +297,11 @@ sub cmd_clone { $url !~ m#^[a-z\+]+://#) { $path = $url; } + if (defined $_stdlayout) { + $_trunk = 'trunk' if (!defined $_trunk); + $_tags = 'tags' if (!defined $_tags); + $_branches = 'branches' if (!defined $_branches); + } $path = basename($url) if !defined $path || !length $path; cmd_init($url, $path); Git::SVN::fetch_all($Git::SVN::default_repo_id); -- 1.5.3.rc1.7.gcae4 ``` ## martin f krafft, 2007-07-13 09:56 Subject: git-svn patch faulty (was: failing to send patches to the list) Message-ID: <20070713095644.GA26743@lapse.madduck.net> URL: https://gitlist.dev/e/20070713095644.GA26743%40lapse.madduck.net In-Reply-To: <20070713093050.GA18001@lapse.madduck.net> ``` Hi there, still not having figured out the problem with the list (and I did contact postmaster@), I just discovered that in fact the patch only handles git-svn clone, not git-svn init. Thus, it's best to ignore it for now. I am sorry for not taking enough care before publishing it. The openssl-autodetect patch does work and is ready for inclusion, if you agree. -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck spamtraps: madduck.bogus@madduck.net "if builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." -- gerald weinberg ``` ## Alex Riesen, 2007-07-13 12:57 Subject: Re: failing to send patches to the list Message-ID: <81b0412b0707130557g6cf04365j232654734b148c3f@mail.gmail.com> URL: https://gitlist.dev/e/81b0412b0707130557g6cf04365j232654734b148c3f%40mail.gmail.com In-Reply-To: <20070713093050.GA18001@lapse.madduck.net> ``` On 7/13/07, martin f krafft wrote: > attached you may find two patches, which I've previously sent to the > list with > > git format-patch -s --stdout | sendmail git@vger.kernel.org > I suggest you try "git format-patch -s --stdout |less" before sending format-patch without parameters produces nothing. Even assuming you run something like "git-format-patch start.." (note the range specification), its output is NOT what sendmail can use (unless you have a special sendmail which understands mboxes). ``` ## Jeff King, 2007-07-13 15:55 Subject: Re: failing to send patches to the list Message-ID: <20070713155516.GA2712@sigill.intra.peff.net> URL: https://gitlist.dev/e/20070713155516.GA2712%40sigill.intra.peff.net In-Reply-To: <20070713093050.GA18001@lapse.madduck.net> ``` On Fri, Jul 13, 2007 at 11:30:50AM +0200, martin f krafft wrote: > git format-patch -s --stdout | sendmail git@vger.kernel.org > > Even though my mail server seems to have delivered them correctly: > [...] > they never made it onto the list. vger will reject messages without a message-id. git-format-patch by default does not generate a message-id, so unless sendmail generates one on the fly, that is your problem. In general, git-format-patch output is probably not suitable for direct sending...have you looked at git-send-email? -Peff ``` ## Jakub Narebski, 2007-07-14 00:58 Subject: Re: failing to send patches to the list Message-ID: URL: https://gitlist.dev/e/f79742%24j44%242%40sea.gmane.org In-Reply-To: <20070713093050.GA18001@lapse.madduck.net> ``` martin f krafft wrote: > Subject: [PATCH] fall back to mozilla's sha.h if openssl/sha.h is not available > > Uses $(CPP) to attempt to preprocess an include directive. If > that fails, NO_OPENSSL is defined, causing the Makefile to fall back to using > mozilla's SHA implementation. Shouldn't this be rather in configure.in? Main Makefile has only defaults for different systems, but does not do tests. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ``` ## martin f krafft, 2007-07-14 06:05 Subject: Re: failing to send patches to the list Message-ID: <20070714060537.GA24396@lapse.madduck.net> URL: https://gitlist.dev/e/20070714060537.GA24396%40lapse.madduck.net In-Reply-To: <81b0412b0707130557g6cf04365j232654734b148c3f@mail.gmail.com> ``` also sprach Alex Riesen [2007.07.13.1457 +0200]: > I suggest you try "git format-patch -s --stdout |less" before > sending format-patch without parameters produces nothing. I did. I simply misquoted in the email. Fact is that sendmail did send an email, which VGER recognised to be a diff; yet it never showed up. I think the missing message ID is likely the problem. I'll look into it. -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck spamtraps: madduck.bogus@madduck.net humpty was pushed. ``` ## martin f krafft, 2007-07-14 06:52 Subject: Re: failing to send patches to the list Message-ID: <20070714065242.GA27136@lapse.madduck.net> URL: https://gitlist.dev/e/20070714065242.GA27136%40lapse.madduck.net In-Reply-To: <20070713155516.GA2712@sigill.intra.peff.net> ``` also sprach Jeff King [2007.07.13.1755 +0200]: > vger will reject messages without a message-id. git-format-patch by > default does not generate a message-id, so unless sendmail generates one > on the fly, that is your problem. > > In general, git-format-patch output is probably not suitable for direct > sending...have you looked at git-send-email? I just ran a test and found out: sendmail does generate a message ID on the fly on the client, so this cannot be the problem. -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck spamtraps: madduck.bogus@madduck.net http://www.transnationalrepublic.org/ ``` ## martin f krafft, 2007-07-14 06:59 Subject: Re: failing to send patches to the list Message-ID: <20070714065928.GB27136@lapse.madduck.net> URL: https://gitlist.dev/e/20070714065928.GB27136%40lapse.madduck.net In-Reply-To: ``` also sprach Jakub Narebski [2007.07.14.0258 +0200]: > Shouldn't this be rather in configure.in? Main Makefile has only > defaults for different systems, but does not do tests. You are right, except git HEAD already comes with a Makefile (rather than a Makefile.in), so I just ran it while testing out patches. I introduced the test because I thought the computer could find out about libssl for me, rather than myself having to forget to specify NO_OPENSSL every time. I agree that this should be (also) in configure.ac; the question is more whether we *could* also add it to the Makefile to make from-source compilations easier. On the other hand, I wonder: if the mozilla/sha.h implementation is in the tree anyway, why even bother with libssl? The SHA implementation is unlikely to be changed anytime soon, so the extra library dependency seems overkill just for the SHA hash functionality. Just my 2ยข -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck spamtraps: madduck.bogus@madduck.net "to get back my youth i would do anything in the world, except take exercise, get up early, or be respectable." -- oscar wilde ``` ## Eric Wong, 2007-07-14 10:54 Subject: Re: git-svn patch faulty (was: failing to send patches to the list) Message-ID: <20070714105455.GB14842@muzzle> URL: https://gitlist.dev/e/20070714105455.GB14842%40muzzle In-Reply-To: <20070713095644.GA26743@lapse.madduck.net> ``` martin f krafft wrote: > Hi there, > > still not having figured out the problem with the list (and I did > contact postmaster@), I just discovered that in fact the patch only > handles git-svn clone, not git-svn init. Thus, it's best to ignore > it for now. I am sorry for not taking enough care before publishing > it. Heh, I haven't used git-svn init in months :) -- Eric Wong ```