git version 2.17.1
git-gui version 0.21.GITGUI
Steps to reproduce:
1) Open `git gui`
2) Select "Clone Existing Repository"
3) Set "Source Location" to an empty remote repository (I am trying
to clone from a gitolite "wild" repo that is created on the fly during
the clone).
4) Clone
Result:
fata
On 12/08/17 02:30, Junio C Hamano wrote:
This may make the code to _compile_, but is it sensible to let the
code build and be used by the end users without the "these protocols
are safe" filter, I wonder?
Git will display a warning at runtime if this is not available but
perhaps this warning
On 12/08/17 00:15, Junio C Hamano wrote:
"Tom G. Christensen" writes:
I have build tested these changes against upstream curl 7.12.0 (fails),
7.12.1 and 7.15.5. I have also built and run the testsuite against the
Red Hat provided curl versions listed above.
Hmph, what does &quo
check.
This is done to ensure that vendor supported curl versions that have had
CURLPROTO_* support backported are handled correctly.
Signed-off-by: Tom G. Christensen
---
http.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/http.c b/http.c
index e00264cff..569909e8a 100644
these changes against upstream curl 7.12.0 (fails),
7.12.1 and 7.15.5. I have also built and run the testsuite against the
Red Hat provided curl versions listed above.
Tom G. Christensen (2):
http: Fix handling of missing CURLPROTO_*
http: use a feature check to enable GSSAPI delegation control
h
Turn the version check into a feature check to ensure this functionality
is also enabled with vendor supported curl versions where the feature
may have been backported.
Signed-off-by: Tom G. Christensen
---
http.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/http.c
On 11/08/17 01:23, Jeff King wrote:
On Fri, Aug 11, 2017 at 01:17:51AM +0200, Tom G. Christensen wrote:
OK, thanks for double-checking. I'm still puzzled why your build
succeeds and mine does not.
I know what's going on now and it's so simple.
Red Hats version of curl 7.
On 11/08/17 00:54, Jeff King wrote:
On Fri, Aug 11, 2017 at 12:23:42AM +0200, Tom G. Christensen wrote:
Er, sorry if I'm being dense, but how? Are you suggesting that by
removing the callsite of get_curl_allowed_protocols(), the compiler
might elide the now-dead code completely? I
On 10/08/17 23:32, Jeff King wrote:
On Thu, Aug 10, 2017 at 10:33:18PM +0200, Tom G. Christensen wrote:
You've totally ignored the argument I made back then[1], and which I
reiterated in this thread. So I'll say it one more time: the more
compelling reason is not the #ifdefs, but the
On 09/08/17 23:47, Jeff King wrote:
On Wed, Aug 09, 2017 at 11:42:12PM +0200, Johannes Schindelin wrote:
I mean, if we even go out of our way to support the completely outdated
and obsolete .git/branches/ for what is likely a single user, it may not
be the worst to keep those couple of #ifdef gu
[I am resending this since the original does not seem to have made it to
the list, at least I cannot find it in any archives]
On 09/08/17 23:47, Jeff King wrote:
On Wed, Aug 09, 2017 at 11:42:12PM +0200, Johannes Schindelin wrote:
I mean, if we even go out of our way to support the completely
On 09/08/17 15:38, Ævar Arnfjörð Bjarmason wrote:
RHEL/CentOS 5.x has perl 5.8.8, but it also has curl 7.15.5[1] which is
obseleted by these curl patches. Maybe we'd want to be more conservative
with perl for whatever reason, but I'd like to at least bump our
requirenment of 5.8.0 to 5.8.8. Thos
en paste the commands.
It saves me creating a script file and then removing it later.
--
Tom Hale
On 17/04/17 11:24, Junio C Hamano wrote:
> "Tom \"Ravi\" Hale" writes:
>
> > If a user types `set -e` in an interactive shell, and is using __git_ps1
> > to set
> > their prompt, the shell will die if the current directory isn't inside a git
reventing
`set -e` from having an effect.
Signed-off-by: Tom "Ravi" Hale
>From 7867768f4516559c129ed9eb07ae29c36a6c9367 Mon Sep 17 00:00:00 2001
From: "Tom \"Ravi\" Hale"
Date: Sun, 16 Apr 2017 14:10:10 +0700
Subject: [PATCH] __git_ps1: Don't kill sh
On 06/04/17 11:21, Jeff King wrote:
On Wed, Apr 05, 2017 at 11:33:37AM +0200, Tom G. Christensen wrote:
I don't use the el3 and el4 versions much any more and el5 use will also
drop of now as I'm busy converting machines from el5 to el7.
Thanks for sharing, that's a really i
On 05/04/17 15:40, Ævar Arnfjörð Bjarmason wrote:
On Wed, Apr 5, 2017 at 3:04 PM, Tom G. Christensen wrote:
This allows running the git-svn testsuite with Python 2.2.
+CC-ing Eric S. Raymond who added these version limitations in a33faf2827.
Also, in his patch contrib/svn-fe/svnrdump_sim.py
On 05/04/17 12:51, Ævar Arnfjörð Bjarmason wrote:
On Wed, Apr 5, 2017 at 11:33 AM, Tom G. Christensen
wrote:
Whoah. So my assumption in
that nobody was compiling this & thus not reporting failures was
false. Rather there's an entire community & distribution mechanism
around pat
Commit 17966c0a added an unguarded use of curl_easy_strerror.
This adds a guard so it is not used with curl < 7.12.0.
Signed-off-by: Tom G. Christensen
---
http.c | 4
1 file changed, 4 insertions(+)
diff --git a/http.c b/http.c
index a46ab23af..104caaa75 100644
--- a/http.c
+++ b/htt
Do not try and use CURLINFO_SSL_DATA_{IN,OUT} for curl < 7.12.1.
Signed-off-by: Tom G. Christensen
---
http.c | 4
1 file changed, 4 insertions(+)
diff --git a/http.c b/http.c
index ce618bdca..a46ab23af 100644
--- a/http.c
+++ b/http.c
@@ -649,10 +649,12 @@ static int curl_trace(C
This adds man page installation when using NO_PERL_MAKEMAKER to ensure
parity with the normal case where ExtUtils::MakeMaker is used.
Signed-off-by: Tom G. Christensen
---
perl/Makefile | 13 +
1 file changed, 13 insertions(+)
diff --git a/perl/Makefile b/perl/Makefile
index
These are patches currently needed to support building and running git
on RHEL/CentOS 3 and 4.
Tom G. Christensen (7):
Make NO_PERL_MAKEMAKER behave more like ExtUtils::MakeMaker
Install man pages when NO_PERL_MAKEMAKER is used
Allow svnrdump_sim.py to be used with Python 2.2
Handle
This adds an OLD_GNUPG define to the Makefile which when activated will
ensure git does not use the --keyid-format argument when calling the
'gpg' program.
This is consistent with how 'gpg' was used in git < 2.10.0 and slightly
decreases security.
Signed-off-by: Tom G. Chr
This allows running the git-svn testsuite with Python 2.2.
Signed-off-by: Tom G. Christensen
---
contrib/svn-fe/svnrdump_sim.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/svn-fe/svnrdump_sim.py b/contrib/svn-fe/svnrdump_sim.py
index 11ac6f692..86bf4a742
: Tom G. Christensen
---
perl/Makefile | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/perl/Makefile b/perl/Makefile
index 15d96fcc7..ce53a240c 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -25,7 +25,12 @@ clean:
$(makfile): PM.stamp
ifdef NO_PERL_MAKEMAKER
With curl < 7.10.7 we cannot get the proxy CONNECT response code.
As a workaround set it to zero which means no response code available.
Signed-off-by: Tom G. Christensen
---
http.c | 4
1 file changed, 4 insertions(+)
diff --git a/http.c b/http.c
index 96d84bbed..ce618bdca 100644
--
On 04/04/17 04:54, Jeff King wrote:
A nearby thread raised the question of whether we can rely on a version
of libcurl that contains a particular feature. The version in question
is curl 7.11.1, which came out in March 2004.
My feeling is that this is old enough to stop caring about. Which means
ementations, and the importance of
proper treatment thereof.
If Bob creates Bob's git compatible program, and he happens to use
Bob's OpenPGP implementation, his compatible option for git-commit(1)
still has to be called "--gpg-sign". Madness.
Tom.
If an alias is a single git command show the man page of the
aliased git command with --help.
Signed-off-by: Tom Kunze
---
Hi,
I noticed that when I pass --help to an alias which is only a git
command it tells me a information about the alias. But it would be
nice if it instead opens the
not.
Also:
Given it's very rare to want only part of a string to emit colour codes,
if something like "bold" carries through until a "no-bold", why doesn't
"auto" do the same thing?
--
Tom Hale
seems that this is not being
respected when piped through `cat`.
Am I misunderstanding the manual?
--
Tom Hale
The log --format="%d" includes preceding space:
$ git log -n1 --format="XX%dXX" HEAD
XX (HEAD -> master)XX
I know of no other % that is output in this way.
Is there a way of removing this preceding space through the format
string, or will it need to be a code change?
--
Tom Hale
re an issue I can watch, or a way to
subscribe/monitor only this one thread?
--
Cheers,
Tom
back to the shell, whereas I
would expect to see:
Stage this hunk [y,n,q,a,d,/,j,J,g,e,?]?
--
Tom Hale
Would it be possible to also treat signals (128 and above) as 'special' values
as well (as I've seen some merge tools self destruct like that from time to
time)
- Original Message -
From: gits...@pobox.com
To: j...@keeping.me.uk
Cc: Tom Tanner (BLOOMBERG/ LONDON), dav...
For instance, if you set your diff/mergetool to meld and you don't have it
installed:
> git difftool
Viewing (1/1): 'blah'
Launch 'meld' [Y/n]? y
/home/ttanner/bin/meld[8]: /opt/swt/bin/meld: not found
> echo $?
0
> /home/ttanner/bin/meld
/home/ttanner/bin/meld[8]: /opt/swt/bin/meld: not found
>
Le 09/06/2016 à 13:49, Matthieu Moy a écrit :
> Samuel GROOT writes:
>
>> If used with `in-reply-to=`, cite the message body of the given
>> email file. Otherwise, do nothing.
>
> It should at least warn when --in-reply-to= is not given
> (either no --in-reply-to or --in-reply-to=). I don't see
On 06/09/16 07:51, Matthieu Moy wrote:
> Junio C Hamano writes:
>
>> Tom Russello writes:
>>
>>> +# Check if two files have the same content, non-order sensitive
>>> +test_cmp_noorder () {
>>> + sort $1 >$1;
>>
>> Here is what I th
On 06/08/16 08:26, Matthieu Moy wrote:
> Did you drop the "configuration variables" patch on purpose? Or will you
> resend it separately?
I just resend it separately,
thank you.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
i -e "s/\'P\'/\`P\`/g" ./*.txt
Signed-off-by: Tom Russello
Signed-off-by: Erwan Mathoniere
Signed-off-by: Samuel Groot
Signed-off-by: Matthieu Moy
Reviewed-by: Matthieu Moy
---
I forgot to add this patch to the current series (v4) and there is no change
si
in purposes is to stick to the CodingGuidelines as possible so
that people writting new documentation by mimicking the existing are more likely
to have it right (even if they didn't read the CodingGuidelines).
Signed-off-by: Tom Russello
Signed-off-by: Erwan Mathoniere
Signed-off-by: Samuel
new documentation by mimicking the existing are more likely
to have it right (even if they didn't read the CodingGuidelines).
Signed-off-by: Tom Russello
Signed-off-by: Erwan Mathoniere
Signed-off-by: Samuel Groot
Signed-off-by: Matthieu Moy
---
Changes since v3:
- More precise commi
Make the guideline text that we want for our documentation clearer.
Signed-off-by: Tom Russello
Signed-off-by: Erwan Mathoniere
Signed-off-by: Samuel Groot
Signed-off-by: Matthieu Moy
---
Changes since v3:
- Add the rule of when environment variables must be prefixed with
Hello,
as `MAN_BOLD_LITERAL` knob is just now turned on by default with 5945717
(Documentation: bold literals in man, 2016-05-31), it is the right time to
make our documentation more consistent.
Documentation/CodingGuidelines| 13 --
Documentation/config.txt | 58 ++
Take an email message file, parse it and fill the "From", "To", "Cc",
"In-reply-to", "References" fields appropriately.
If `--compose` option is set, it will also fill the subject field with
`Re: ['s subject]` in the introductory message.
S
-by: Tom RUSSELLO
Signed-off-by: Samuel GROOT
Signed-off-by: Matthieu MOY
---
Documentation/git-send-email.txt | 8
git-send-email.perl | 81 ++--
t/t9001-send-email.sh| 32
3 files changed, 117 insertions(+), 4
The purpose of this series of patches is to implement a new
"quote-email" feature integrated in the current `--in-reply-to` option.
* The first 2 patches make the tests less dependent to
`git send-email`'s exact output.
* Third patch makes `git send-email` a bit less verbose.
* Fourth pat
Tests might fail if lines compared in text files don't have the same order.
Signed-off-by: Samuel GROOT
Signed-off-by: Tom RUSSELLO
Signed-off-by: Matthieu MOY
---
t/t9001-send-email.sh | 61 ---
1 file changed, 34 insertions(+), 27 dele
Check if the given utf-8 email address is in the Cc: field.
Signed-off-by: Tom RUSSELLO
Signed-off-by: Samuel GROOT
Signed-off-by: Matthieu MOY
---
t/t9001-send-email.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index
We need a simple and generic way to parse an email file.
Since it would be hard to include and maintain an external library,
create an simple email parser subroutine to parse an email file.
Signed-off-by: Samuel GROOT
Signed-off-by: Tom RUSSELLO
Signed-off-by: Matthieu MOY
---
We chose to
Messages displayed by `send-email` should be shortened to avoid displaying
unnecesseray informations.
Signed-off-by: Samuel GROOT
Signed-off-by: Tom RUSSELLO
Signed-off-by: Matthieu MOY
---
git-send-email.perl | 22 +--
t/t9001-send-email.sh | 58
On 06/06/16 16:08, Matthieu Moy wrote:
> I'd add to the commit message that one of the goals of this patch is to
> make the use "mostly consistent" with CodingGuidelines, so that people
> writting new doc by mimicking the existing one later get a good
> probability of getting it right even if they
On 06/06/16 15:42, Matthieu Moy wrote:
> Matthieu Moy writes:
>
>> Tom Russello writes:
>>> + Literal examples (e.g. use of command-line options, command names,
>>> + configuration and environment variables) must be typeset in monospace
>>
As a first step, this change GIT_* variables that where in
italic style to monospace font according to the guideline. It was obtained
with
perl -pi -e "s/\'(GIT_.*?)\'/\`\1\`/g" *.txt
Signed-off-by: Tom Russello
Signed-off-by: Erwan Mathoniere
Signed-off-by: Samuel
s -iP perl -pi -e "s/\'P\'/\`P\`/g" ./*.txt
Signed-off-by: Tom Russello
Signed-off-by: Erwan Mathoniere
Signed-off-by: Samuel Groot
Signed-off-by: Matthieu Moy
---
Currently, in Documentation/git-status.txt, status.relativePaths (l.120) has no
particular style whereas in Docum
Hello,
as `MAN_BOLD_LITERAL` knob is just now turned on by default with 5945717
(Documentation: bold literals in man, 2016-05-31), it is the right time to
make our documentation more consistent.
Changes since v2: prefix the email subject lines with "doc:"
--
To unsubscribe from this list: send th
Make the guideline text that we want for our documentation clearer.
Signed-off-by: Tom Russello
Signed-off-by: Erwan Mathoniere
Signed-off-by: Samuel Groot
Signed-off-by: Matthieu Moy
---
IMHO, the previous "rule" was not so clear on what we have to do and didn't give
a guide
s -iP perl -pi -e "s/\'P\'/\`P\`/g" ./*.txt
Signed-off-by: Tom Russello
Signed-off-by: Erwan Mathoniere
Signed-off-by: Samuel Groot
Signed-off-by: Matthieu Moy
---
Currently, in Documentation/git-status.txt, status.relativePaths (l.120) has no
particular style whereas in Docum
Make the guideline text that we want for our documentation clearer.
Signed-off-by: Tom Russello
Signed-off-by: Erwan Mathoniere
Signed-off-by: Samuel Groot
Signed-off-by: Matthieu Moy
---
IMHO, the previous "rule" was not so clear on what we have to do and didn't give
a guide
As a first step, this change GIT_* variables that where in
italic style to monospace font according to the guideline. It was obtained
with
perl -pi -e "s/\'(GIT_.*?)\'/\`\1\`/g" *.txt
Signed-off-by: Tom Russello
Signed-off-by: Erwan Mathoniere
Signed-off-by: Samuel
Hello,
as `MAN_BOLD_LITERAL` knob is now turned on by default, it is the right time to
make our documentation more consistent.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majo
On 05/28/16 16:35, Matthieu Moy wrote:
>> +--quote-email=::
>> +Reply to the given email and automatically populate the "To:",
"Cc:" and
>> +"In-Reply-To:" fields.
>
> I think this is a bit too technical for a user documentation. To: and
> Cc: is OK, but people need not know about "In-Reply
On 05/28/16 17:01, Matthieu Moy wrote:
>> Currently, `send-email` without `--compose` implies `--annotate`.
>
> I don't get it. Did you mean s/without/with/? Even if so, this is not
> exactly true: "git send-email --compose -1" will open the editor only
> for the cover-letter, while adding --annota
Take an email message file, parse it and quote the message body.
If `--compose` is set, then it will quote the message in the cover letter.
Otherwise, imply `--annotate` option and put the quoted message in the first
patch after the triple-dash.
Signed-off-by: Tom Russello
Signed-off-by: Samuel
Take an email message file, parse it and fill the "To", "Cc" and
"In-Reply-To" fields appropriately.
If `--compose` option is set, it will also fill the subject field with
"Re: ['s subject]".
Signed-off-by: Tom Russello
Signed-off-by: Samuel Groot
S
Hello,
With the current send-email command, you can send a series of patches
"in reply to" an email.
This patch adds a new option to `git send-email`,
`--quote-email=` which does two things:
- set fields appropriately (To, Cc, Subject, In-Reply-To)
- quote the given message
In th
On 05/25/16 00:30, Aaron Schrab wrote:
> At 14:49 +0200 24 May 2016, Matthieu Moy
> wrote:
>> Samuel GROOT writes:
>>
>>> What kind of help text would you want to see?
>>>
>>> Maybe something like this:
>>>
>>> GIT: Quoted message body below.
>>> GIT: Feel free to trim down the quoted text
>>
From: Tom Russello
This new option takes an email message file, parses it, fills the "To",
"Subject" and "Cc" fields appropriately and quote the message.
This option involves the `--compose` mode to edit the cover letter quoting the
given email.
Signed-off-b
From: Tom Russello
Tests if the "To", "Cc" and "Subject" fields are adequately filled and if the
message is correctly quoted.
Signed-off-by: Tom Russello
Signed-off-by: Samuel Groot
Signed-off-by: Matthieu Moy
---
diff --git a/t/t9001-send-email.sh b/t/t90
Hello,
With the current send-email command, you can send a series of patches "in reply
to" an email.
This patch adds a new option to `git send-email`, `--quote-mail=`, to
quote an email in the cover letter in your series of patches.
The "To", "Cc" and "Subject" fields will be filled appropriately
monospaced (`GIT_EDITOR` - l.657)
As a first step, this patch changes GIT_* variables that where in
italic style to monospace font. It was obtained with
perl -pi -e "s/\'(GIT_.*?)\'/\`\1\`/g" *.txt
Signed-off-by: Tom Russello
Signed-off-by: Matthieu Moy
---
Hello,
There is n
What I want can be achieved using "git stash store `git stash create`"
On 05/02/2016 12:58 PM, Junio C Hamano wrote:
Tom Anderson writes:
Yes, but I like my stashes to be saved in the ref namespace.
Isn't that something you can do so yourself with store_stash?
--
To unsubs
On 05/02/2016 11:42 AM, Junio C Hamano wrote:
Tom Anderson writes:
@@ -61,6 +61,9 @@ stashed and then cleaned up with `git clean`,
leaving the working directory
in a very clean state. If the `--all` option is used instead then the
ignored files are stashed and cleaned in addition to the
Add the "--no-reset" (same as "-r") flag to git-stash.sh. A common
workflow is to use "git-stash save" and "git-stash apply" to save your
work without modifying your changed files. This forces users to
reload their changed files in text editors like emacs, and touches the
modify time on all chan
On 09/04/16 23:04, Jeff King wrote:
I did some quick grepping around, and I suspect you may run
into the same thing in other places (e.g., t3404.40 looks
like a similar case).
There are only a few tests that fail and just t5532.3 seems affected by
this issue.
Subject: [PATCH] t5532: use wri
Hello,
Looking at the testsuite results on Solaris I see a failure in t5532.3.
Running the testsuite with -v -i revealed a shell syntax error:
proxying for example.com 9418
./proxy: syntax error at line 3: `cmd=$' unexpected
not ok 3 - fetch through proxy works
#
# git fetch fake
On 09/04/16 19:39, Jeff King wrote:
[1/3]: config: lower-case first word of error strings
[2/3]: git_config_set_multivar_in_file: all non-zero returns are errors
[3/3]: git_config_set_multivar_in_file: handle "unset" errors
I applied them to 2.8.1 and ran the testsuite again on Solar
On 07/04/16 22:19, Tom G. Christensen wrote:
On 07/04/16 20:50, Junio C Hamano wrote:
Junio C Hamano writes:
So perhaps this is all we need to fix your box.
setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
I applied this patch to 2.8.0 and have completed a testsuite run on
On 07/04/16 20:50, Junio C Hamano wrote:
Junio C Hamano writes:
So perhaps this is all we need to fix your box.
setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Yes that seems to work very well.
I applied this patch to 2.8.0 and have completed a testsuite run on
Solaris 2.6
On 07/04/16 20:32, Junio C Hamano wrote:
"Tom G. Christensen" writes:
The reason for the crash is simple, a null value was passed to the 's'
format for the *printf family of functions.
...
Passing a null value to the 's' format is explicitly documented as
givin
Hello,
While working on an update to the git packages in tgcware(1) I ran into
segfaults when running the testsuite.
Here's what it looks like on Solaris 7/SPARC:
Core was generated by
`/export/home/tgc/buildpkg/git/src/git-upstream/git update-index
should-be-empty'.
Program terminated wit
Do you need loan to finance your Businessor Investment? We offer all kinds
of loans (Personal, Mortgage, Refinancing, Debt Consolidation, Investment
Loan etc) at 4% interest rate, Contact us today at: mc.tm...@gmail.com .
Contact Us With Email Only (mc.tm...@gmail.com).
--
To unsubscribe from
on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed
i know next to nothing about git and was asked to resolve this issue.
thank you.
tom
--
To unsubscribe from this list: send the line "unsubscribe git&qu
01: turn --no$option workarounds to --no-$option
Kyle J. McKay (1):
git-send-email.perl: support no- prefix with older GetOptions
git-send-email.perl | 10 ++
t/t9001-send-email.sh | 10 +-
2 files changed, 15 insertions(+), 5 deletions(-)
Tested-by: Tom G. Christensen
I
The __builtin_ctzll function was added in gcc 3.4.0.
This extends the check for gcc so that use of __builtin_ctzll is only
enabled if gcc >= 3.4.0.
Signed-off-by: Tom G. Christensen
---
v2:
Add S-o-b
v1:
I noticed this on RHEL3 during 2.0.0rc phase but I see that the same
issue was noticed
Commit dd61399 introduced support for http proxies that require
authentication but it relies on the CURL_PROXYAUTH option which was
added in curl 7.10.7.
This makes sure proxy authentication is only enabled if libcurl can
support it.
Signed-off-by: Tom G. Christensen
---
RHEL3 ships with curl
The __builtin_ctzll function was added in gcc 3.4.0.
This extends the check for gcc so that use of __builtin_ctzll is only
enabled if gcc >= 3.4.0.
---
I noticed this on RHEL3 during 2.0.0rc phase but I see that the same
issue was noticed on Debian Sarge:
http://article.gmane.org/gmane.comp.versio
On 01/02/15 23:48, Junio C Hamano wrote:
I was reviewing the recent bugs and fixes for the last time, and was
wondering if we want to do 2.3-rc3 with build fix for those with
ancient cURL (tc/curl-vernum-output-broken-in-7.11) and workaround
for those with Perl with older Getopt::Long (tc/t9001-n
On 30/01/15 15:50, Andreas Schwab wrote:
"Tom G. Christensen" writes:
diff --git a/Makefile b/Makefile
index c44eb3a..69a2ce3 100644
--- a/Makefile
+++ b/Makefile
@@ -1035,13 +1035,13 @@ else
REMOTE_CURL_NAMES = $(REMOTE_CURL_PRIMARY) $(REMOTE_CURL_ALIASES)
PR
On 29/01/15 16:52, Jeff King wrote:
Both this and the curl-version issue you reported seem to have simple
solutions that you've already worked out and tested. Would you like to
express them in the form of patches so they can be applied? :)
Patches have been posted as requested.
-tgc
--
To uns
correctly.
Signed-off-by: Tom G. Christensen
---
This was discoved while building on RHEL4 which has curl 7.12.1.
The makefile check for curl >= 7.34.0 failed and enabled
USE_CURL_FOR_IMAP_SEND.
# curl-config --vernum
70C01
# { echo 072200; curl-config --vernum 2>/dev/null ; } | sort -r | s
;. More recent
versions of Getopt::Long, such as version 2.34, support either prefix. So
use the older form in the tests.
See also:
d2559f734bba7fe5257720356a92f3b7a5b0d37c
907a0b1e04ea31cb368e9422df93d8ebb0187914
84eeb687de7a6c7c42af3fb51b176e0f412a979e
3fee1fe87144360a1913eab86af9ad136c810076
S
by checking its version, or just checking after we
import the keys that we can actually _use_ them).
That would seem a bit heavy-handed as it is otherwise working fine with
the old gnupg.
-tgc
--
Tom G. Christensen - Systemmedarbejder - IT-drift
Statsbiblioteket - Victor Albecks Vej 1 - 8000 Aar
On 28/01/15 00:35, Junio C Hamano wrote:
A release candidate Git v2.3.0-rc2 is now available for testing
at the usual places.
Commit 2cf770 added testing of the --[no-]xmailer option to git
send-email in t9001-send-email.sh
Unfortunately it used the modern Getopt::long style of --no- to
nega
On 28/01/15 00:35, Junio C Hamano wrote:
A release candidate Git v2.3.0-rc2 is now available for testing
at the usual places.
All signed commit tests fail on RHEL4 which is a regression from 2.2.2.
From t4202.42:
++ git tag -s -m signed_tag_msg signed_tag
gpg: key CDDE430D: secret key withou
On 28/01/15 00:35, Junio C Hamano wrote:
A release candidate Git v2.3.0-rc2 is now available for testing
at the usual places.
Building is broken on RHEL4 which is a regression from 2.2.2.
The makefile check for curl >= 7.34.0 fails and enables
USE_CURL_FOR_IMAP_SEND even though curl is 7.12.
rom my personal point of view it would be nice and polite to get an
answer for postings.
Hopefully I got some feedback from this list to whom I should send the
patch for review or denial.
Thanks
Tom
===
=
Subject: FEAT
else
url = xstrdup("foreign");
url_len = strlen(url);
for (i = url_len - 1; url[i] == '/' && 0 <= i; i--)
;
url_len = i + 1;
if (4 < i && !strncmp(".git", url + i -
dot-git-and-slash
From https://github.com/git/git.git/
a155a5f..5512ac5 maint -> upstream/maint
Signed-off-by: Tom Miller
---
This patch should be based on the tip of "next" because it is dependent
on the code from "tm/fetch-prune".
Initially I thought I
he user to use "git
remote prune" to fix the problem.
This patch changes the way "fetch --prune" works by moving the pruning
operation before the fetching operation. Instead of warning the user of
a conflict, it autmatically fixes it.
Signed-off-by: Tom Miller
Tested-by:
1 - 100 of 126 matches
Mail list logo
