John Keeping writes:
> I'd rather have '$smtp_ssl_cert_path ne ""' in the first if condition
> (instead of the '-d $smtp_ssl_cert_path') ...
I agree. The signal for "no certs" should be an explicit "nonsense"
value like an empty string, not just a string that does not name an
expected filesyste
When attempting to git-svn fetch files from an svn https?: url using
the serf library (the only choice starting with svn 1.8) the following
errors can occur:
Temp file with moniker 'svn_delta' already in use at Git.pm line 1250
Temp file with moniker 'git_blob' already in use at Git.pm line 1250
On Jul 5, 2013, at 16:14, David Rothenberger wrote:
On 7/5/2013 1:48 PM, David Rothenberger wrote:
I recently upgraded my Subversion server to 1.8.0 and started
receiving the following error from "git svn fetch":
Temp file with moniker 'svn_delta' already in use at /usr/lib/perl5/
vendor_perl/
This patch allows git-svn to fetch successfully using the
serf library when given an https?: url to fetch from.
Unfortunately some svn servers do not seem to be configured
well for use with the serf library. This can cause fetching
to take longer compared to the neon library or actually
cause ti
The temp_is_locked function can be used to determine whether
or not a given name previously passed to temp_acquire is
currently locked.
Signed-off-by: Kyle J. McKay
---
perl/Git.pm | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/perl/Git.pm b/perl/Git.pm
inde
On Sat, Jul 06, 2013 at 02:04:07AM +, Daniel Shahaf wrote:
> On Sat, Jul 06, 2013 at 02:34:23AM +0200, Branko Čibej wrote:
> > http://subversion.apache.org/docs/release-notes/1.7.html#svnrdump
> > In other words, this is a limitation of the Serf-based backend that has
> > been around since Subv
On Sat, Jul 06, 2013 at 02:34:23AM +0200, Branko Čibej wrote:
> http://subversion.apache.org/docs/release-notes/1.7.html#svnrdump
> In other words, this is a limitation of the Serf-based backend that has
> been around since Subversion 1.4. I'm aware that it isn't documented as
> well as it should b
On 7/5/2013 6:01 PM, Kyle McKay wrote:
> On Jul 5, 2013, at 16:07, David Rothenberger wrote:
>> On 7/5/2013 3:58 PM, Kyle McKay wrote:
>>> On Jul 5, 2013, at 13:48, David Rothenberger wrote:
I recently upgraded my Subversion server to 1.8.0 and started
receiving the following error from "
On Jul 5, 2013, at 16:07, David Rothenberger wrote:
On 7/5/2013 3:58 PM, Kyle McKay wrote:
On Jul 5, 2013, at 13:48, David Rothenberger wrote:
I recently upgraded my Subversion server to 1.8.0 and started
receiving the following error from "git svn fetch":
Temp file with moniker 'svn_delta' al
On 7/5/2013 3:58 PM, Kyle McKay wrote:
> On Jul 5, 2013, at 13:48, David Rothenberger wrote:
>> I recently upgraded my Subversion server to 1.8.0 and started
>> receiving the following error from "git svn fetch":
>>
>> Temp file with moniker 'svn_delta' already in use at
>> /usr/lib/perl5/vendor_pe
On 7/5/2013 1:48 PM, David Rothenberger wrote:
> I recently upgraded my Subversion server to 1.8.0 and started
> receiving the following error from "git svn fetch":
>
> Temp file with moniker 'svn_delta' already in use at
> /usr/lib/perl5/vendor_perl/5.10/Git.pm line 1024.
>
> This occurs only w
On Jul 5, 2013, at 13:48, David Rothenberger wrote:
I recently upgraded my Subversion server to 1.8.0 and started
receiving the following error from "git svn fetch":
Temp file with moniker 'svn_delta' already in use at /usr/lib/perl5/
vendor_perl/5.10/Git.pm line 1024.
This occurs only when u
I recently upgraded my Subversion server to 1.8.0 and started
receiving the following error from "git svn fetch":
Temp file with moniker 'svn_delta' already in use at
/usr/lib/perl5/vendor_perl/5.10/Git.pm line 1024.
This occurs only when using an http:// URL; svn:// URLs work fine.
I think thi
On Fri, Jul 05, 2013 at 10:20:11AM -0700, Junio C Hamano wrote:
> +# Helper to come up with SSL/TLS certification validation params
> +# and warn when doing no verification
> +sub ssl_verify_params {
> + use IO::Socket::SSL qw(SSL_VERIFY_PEER SSL_VERIFY_NONE);
You might as well put this at the
On Thu, Jul 4, 2013 at 2:46 PM, Orgad Shaneh wrote:
> On Thu, Jul 4, 2013 at 3:42 PM, Antoine Pelisse wrote:
Your problem is that your hook script is not checking $2 so it is
overwriting the message even when you do not want to do so.
>>>
>>> No, it isn't. Not by git-gui at least. Check
Junio C Hamano writes:
> Alexey Shumkin writes:
>
>> -msg=$(printf "modify 2nd file (ge\303\244ndert)")
>> +msg="modify 2nd file (ge\303\244ndert)"
>> if test -n "$1"
>> then
>> -msg=$(echo $msg | iconv -f utf-8 -t $1)
>> +print "$msg" | iconv -f utf-8 -
>> I can try. Indeed, at this revision, the two other branches do not yet
>> exist. But @all will get everything? Last time, I only got head
>> (IIRC).
>
> Our P4 server has a limitation on the number of lines returned by "p4
> changes" command, so sometimes I have to use @change_start,@change_stop
On Fri, Jul 05, 2013 at 11:30:11AM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > On Fri, Jul 05, 2013 at 10:20:11AM -0700, Junio C Hamano wrote:
> >> "brian m. carlson" writes:
> >>
> >> > You've covered the STARTTLS case, but not the SSL one right above it.
> >> > Someone using smt
Alexey Shumkin writes:
> - msg=$(printf "modify 2nd file (ge\303\244ndert)")
> + msg="modify 2nd file (ge\303\244ndert)"
> if test -n "$1"
> then
> - msg=$(echo $msg | iconv -f utf-8 -t $1)
> + print "$msg" | iconv -f utf-8 -t "$1"
> + else
> +
On Fri, Jul 5, 2013 at 7:11 PM, Matthieu Brucher
wrote:
>> Hi Matthieu,
>>
>> Could you please try using //Depot/Projectall instead of selecting a
>> specific revision?
>
> I can try. Indeed, at this revision, the two other branches do not yet
> exist. But @all will get everything? Last time, I on
John Keeping writes:
> On Fri, Jul 05, 2013 at 10:20:11AM -0700, Junio C Hamano wrote:
>> "brian m. carlson" writes:
>>
>> > You've covered the STARTTLS case, but not the SSL one right above it.
>> > Someone using smtps on port 465 will still see the warning. You can
>> > pass SSL_verify_mode
> Hi Matthieu,
>
> Could you please try using //Depot/Projectall instead of selecting a
> specific revision?
I can try. Indeed, at this revision, the two other branches do not yet
exist. But @all will get everything? Last time, I only got head
(IIRC).
> Also, by using that command it means that t
Matthieu Brucher gmail.com> writes:
>
> Hi,
>
> I'm trying to convert a Perforce repository to git, knowing that:
> - I use client specs to remove a bunch of folders containing binaires
> (several GiB)
> - branch mappings may not be properly set, and I can't change them
>
> Now, the branches ar
On Fri, Jul 05, 2013 at 10:20:11AM -0700, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> > You've covered the STARTTLS case, but not the SSL one right above it.
> > Someone using smtps on port 465 will still see the warning. You can
> > pass SSL_verify_mode to Net::SMTP::SSL->new just li
"brian m. carlson" writes:
> You've covered the STARTTLS case, but not the SSL one right above it.
> Someone using smtps on port 465 will still see the warning. You can
> pass SSL_verify_mode to Net::SMTP::SSL->new just like you pass it to
> start_SSL.
OK, will a fix-up look like this on top of
My dear,I am Ms Janet Gohoho; I got your email address from inter-net. I
have issues I will like to discuss with you either by email or phone.
Thanks as I do hope to receive your reply as soon as possible. Ms Janet
Gohoho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the bo
I have svn repository on https singed with GeoTrust issued certificate.
Every time i try to access this repository i have message :
$ git svn rebase
Error validating server certificate for 'https://svn.egspace.ru:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint
Hi,
I'm trying to convert a Perforce repository to git, knowing that:
- I use client specs to remove a bunch of folders containing binaires
(several GiB)
- branch mappings may not be properly set, and I can't change them
Now, the branches are layout like this:
- Branch/Main <- master
- Branch/Fea
On Fri, Jul 05, 2013 at 06:23:58PM +0530, Ramkumar Ramachandra wrote:
> Thanks. On a related note, how do I find out about all these things? I tried
>
> $ perldoc Net::SMTP::SSL
>
> but it was completely useless. The only reason I got this far is
> because you literally told me what to do.
brian m. carlson wrote:
> You've covered the STARTTLS case, but not the SSL one right above it.
> Someone using smtps on port 465 will still see the warning. You can
> pass SSL_verify_mode to Net::SMTP::SSL->new just like you pass it to
> start_SSL.
Thanks. On a related note, how do I find out a
brian m. carlson:
+ /* U+FFFE and U+ are guaranteed non-characters. */
+ if ((codepoint & 0x1e) == 0xfffe)
+ return bad_offset;
I missed this the first time around: All Unicode characters whose
lower 16-bits are FFFE or are non-ch
On Fri, Jul 05, 2013 at 05:35:47PM +0530, Ramkumar Ramachandra wrote:
> @@ -1193,13 +1197,23 @@ X-Mailer: git-send-email $gitversion
>Debug => $debug_net_smtp);
> if ($smtp_encryption eq 'tls' && $smtp) {
>
Eric Sunshine wrote:
>> + $smtp_ssl_cert_path |=
>> "/etc/ssl/certs";
>
> You're going to want to use logical ||= here. Bitwise |= on a string
> does not do what you expect[1]:
>
> my $s = '/usr/local/etc/ssl/certs';
> $s |= '/etc/ssl/certs';
> print $s,
On Fri, Jul 5, 2013 at 8:05 AM, Ramkumar Ramachandra wrote:
> Use the ca-certificates in /etc/ssl/certs by default (that's where most
> distributions put it). SSL_VERIFY_NONE is now the fallback mode.
>
> Signed-off-by: Ramkumar Ramachandra
> ---
> diff --git a/git-send-email.perl b/git-send-ema
Hi,
Since nobody stepped up to write it, I wrote [2/2] myself. It will be
tested when I send out this series.
Thanks.
Ramkumar Ramachandra (2):
send-email: squelch warning from Net::SMTP::SSL
send-email: introduce sendemail.smtpsslcertpath
Documentation/config.txt | 3 +++
Docume
Due to a recent change in the Net::SMTP::SSL module, send-email emits
the following ugly warning everytime a email is sent via SSL:
***
Using the default of SSL_verify_mode of SSL_VERIFY_NONE for client
is deprecated! Please set SSL
Use the ca-certificates in /etc/ssl/certs by default (that's where most
distributions put it). SSL_VERIFY_NONE is now the fallback mode.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/config.txt | 3 +++
Documentation/git-send-email.txt | 4
git-send-email.perl
In de6029a (pretty: Add failing tests: --format output should honor
logOutputEncoding, 2013-06-26) 'complex-subject' test was changed.
Revert it back, because that change actually removed tests for "%b" and
"%s" with i18n.commitEncoding set.
Also, add two more tests for mentioned above "%b" and "%s
Function 'test_format' has become harder to read after its
change in de6029a2 (pretty: Add failing tests: --format output
should honor logOutputEncoding, 2013-06-26). Simplify it by
moving its "should we expect it to fail?" parameter to the end.
Note, current code does not use this last parameter
For testing truncated log messages 'commit_msg' function uses `sed` to
cut a message. On various platforms `sed` behaves differently and
results of its work depend on locales installed. So, avoid using `sed`.
Use predefined expected outputs instead of calculated ones.
Signed-off-by: Alexey Shumkin
This patches series includes following changes against v9
1. [PATCH v10 1/5] t4041, t4205, t6006, t7102: use iso8859-1 rather than
iso-8859-1
reworded. reasons of renaming explained "here and now" but not only
redirects to an older commit which did the same.
2. [PATCH v10 2/5] t4205 (log-p
Both "iso8859-1" and "iso-8859-1" are understood as latin-1
by modern platforms, but the latter is not understood by
older platforms; update tests to use the former.
This is in line with 3994e8a9 (t4201: use ISO8859-1 rather
than ISO-8859-1, 2009-12-03), which did the same.
Signed-off-by: Alexey
In previuos commit de6029a (pretty: Add failing tests: --format output
should honor logOutputEncoding, 2013-06-26) single quotes were replaced
with double quotes to make "$(commit_msg)" expression in heredoc to
work. The same effect can be achieved by using "EOF" as a heredoc
delimiter instead of "
Ramkumar Ramachandra writes:
> John Keeping wrote:
>> I don't think this is really "fix", it's more plastering over the
>> problem.
>
> It defaulted to SSL_VERIFY_NONE before Net::SMTP::SSL was updated, and
> the behavior hasn't changed now. The new version simply asks us to be
> explicit about
John Keeping wrote:
> I don't think this is really "fix", it's more plastering over the
> problem.
It defaulted to SSL_VERIFY_NONE before Net::SMTP::SSL was updated, and
the behavior hasn't changed now. The new version simply asks us to be
explicit about SSL_VERIFY_NONE, so we are aware about it.
On Fri, Jul 05, 2013 at 03:48:31PM +0530, Ramkumar Ramachandra wrote:
> Due to a recent change in the Net::SMTP::SSL module, send-email emits
> the following ugly warning everytime a email is sent via SSL:
>
> ***
> Using the default
Due to a recent change in the Net::SMTP::SSL module, send-email emits
the following ugly warning everytime a email is sent via SSL:
***
Using the default of SSL_verify_mode of SSL_VERIFY_NONE for client
is deprecated! Please set SSL
On Fri, Jul 05, 2013 at 02:00:40AM -0700, Junio C Hamano wrote:
> Fraser Tweedale writes:
>
> > The default similarity index of 50% is documented in gitdiffcore(7)
> > but it is worth also mentioning it in the description of the
> > -M/--find-renames option.
>
> Is it? I am not sure if it is wo
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
We are in the middle of 5th week now in the 11-week releace cycle
for 1.8.4 (http://tinyurl.com/gitCal), and quite a few topics have
graduated t
Fraser Tweedale writes:
> The default similarity index of 50% is documented in gitdiffcore(7)
> but it is worth also mentioning it in the description of the
> -M/--find-renames option.
Is it? I am not sure if it is worth it.
--
To unsubscribe from this list: send the line "unsubscribe git" in
t
Alexey Shumkin writes:
>> > Could you point me to the coding style guide, please?
>>
>> Documentation/CodingGuidelines::
> Oh! :)
> thank you
The most important part of the coding guidelines is to match the
style to existing code when writing a new one:
$ git grep '^[a-z_]* ()' -- *.sh | w
Alexey Shumkin writes:
>> OK, then I'll queue this patch (but not 2-4/5 yet) with log message
>> amended.
> Excuse me, you've said "Ok" for 2/5 message, and then explained (as I
> understood) then "subtle difference" between EOF and \EOF.
> Should I change the message somehow?
I left it up to yo
On Fri, Jul 05, 2013 at 01:44:07AM -0700, Junio C Hamano wrote:
> Alexey Shumkin writes:
>
> >> Perhaps like this.
> >>
> >> Function 'test_format' has become harder to read after its
> >> change in de6029a2 (pretty: Add failing tests: --format output
> >> should honor logOutputEncod
Alexey Shumkin writes:
>> Perhaps like this.
>>
>> Function 'test_format' has become harder to read after its
>> change in de6029a2 (pretty: Add failing tests: --format output
>> should honor logOutputEncoding, 2013-06-26). Simplify it by
>> moving its "should we expect it to fa
On Fri, Jul 05, 2013 at 01:11:49AM -0700, Junio C Hamano wrote:
> Alexey Shumkin writes:
>
> >>Both "iso8859-1" and "iso-8859-1" are understood as latin-1
> >>by modern platforms, but the latter is not understood by
> >>older platforms;update tests to use the former.
> >>
> >>
The default similarity index of 50% is documented in gitdiffcore(7)
but it is worth also mentioning it in the description of the
-M/--find-renames option.
Signed-off-by: Fraser Tweedale
---
Documentation/diff-options.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documen
The fact that the git transport does not do any authentication is
easily overlooked. For example, DNS poisoning may result in
fetching from somewhere that was not intended.
Add a brief security notice to the "GIT URLS" section of the
documentation stating that the git transport should be used wit
On Thu, Jul 04, 2013 at 11:45:57PM -0700, Junio C Hamano wrote:
> Alexey Shumkin writes:
>
> > Function 'test_format' is become hard to read after its change in
> > de6029a2d7734a93a9e27b9c4471862a47dd8123. So, make it more elegant.
> > Also, change 'commit_msg' function to make it more pretty.
>
Alexey Shumkin writes:
>> Both "iso8859-1" and "iso-8859-1" are understood as latin-1
>> by modern platforms, but the latter is not understood by
>> older platforms;update tests to use the former.
>>
>> This is in line with 3994e8a9 (t4201: use ISO8859-1 rather
>> tha
Alexey Shumkin writes:
>> Perhaps we should update test_format so that we can feed a quoted
>> input, e.g.
>>
>> +include an iso8859-1 character: bueno!
>>
>> or something?
> We could use this file whole in UTF-8 but just make a conversion of
> expected output as it's done a few lines above
On Thu, Jul 04, 2013 at 11:47:04PM -0700, Junio C Hamano wrote:
> Alexey Shumkin writes:
>
> > This is actually a fixup of de6029a2d7734a93a9e27b9c4471862a47dd8123,
> > which was applied before final patch series was sent.
> >
> > Also, see 3994e8a98dc7bbf67e61d23c8125f44383499a1f for the explana
On Fri, Jul 05, 2013 at 12:04:34AM -0700, Junio C Hamano wrote:
> Alexey Shumkin writes:
>
> > +test_format complex-body %b < > +commit $head3
> > +This commit message is much longer than the others,
> > +and it will be encoded in iso8859-1. We should therefore
> > +include an iso8859 character:
"Paul A. Kennedy" writes:
>> "rebase --abort" is typically used to get rid of conflicted mess the
>> user does not want to resolve right now, and "stash" would not be a
>> sensible thing to use in such a situation, I think. Doesn't it even
>> refuse to work if there is a conflicted entry in the
Alexey Shumkin writes:
> In previuos commit de6029a2d7734a93a9e27b9c4471862a47dd8123 single
> quotes were replaced with double quotes to make "$(commit_msg)"
> expression in heredoc to work. The same effect can be achieved by using
> "EOF" as a heredoc delimiter instead of "\EOF".
OK.
> -test_e
Alexey Shumkin writes:
> +test_format complex-body %b < +commit $head3
> +This commit message is much longer than the others,
> +and it will be encoded in iso8859-1. We should therefore
> +include an iso8859 character: ¡bueno!
This is not such a good idea, as the resulting file will be in mixed
benoit.per...@ensimag.fr writes:
> --- a/contrib/mw-to-git/Makefile
> +++ b/contrib/mw-to-git/Makefile
> @@ -2,6 +2,12 @@
> # Copyright (C) 2013
> # Matthieu Moy
> #
> +# To build and test:
> +#
> +# make:
> +# bin-wrapper/git mw preview Some_page.mw
> +# bin-wrapper/git clone me
66 matches
Mail list logo
