Re: Installed git 2.1.3 on sparc 8, but got core dump during 'git clone'
On 2014-11-06 08.38, victor wrote: Hi Jeff, Thanks for your help, as your suggestion, I can compile/install git with --disable_ptheads now. It seems as if your Git still wants to create a pthread, Did you use --disable-pthreads or --disable_ptheads ? -- 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/majordomo-info.html
Re: Installed git 2.1.3 on sparc 8, but got core dump during 'git clone'
Hi, I used below command to configure: ./configure --prefix=/usr/local/git-2.1.3/ --disable-pthreads Actually, I think the error message is quite clear this time, it is about hook of Deleting a tag is not allowed in this repository. Can I try to disable the hook? Thanks, Victor -- View this message in context: http://git.661346.n2.nabble.com/Installed-git-2-1-3-on-sparc-8-but-got-core-dump-during-git-clone-tp7620692p7620695.html Sent from the git mailing list archive at Nabble.com. -- 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/majordomo-info.html
[PATCH] imap-send: use libcurl for implementation
Use libcurl's high-level API functions to implement git-imap-send instead of the previous low-level OpenSSL-based functions. Since version 7.30.0, libcurl's API has been able to communicate with IMAP servers. Using those high-level functions instead of the current ones would reduce imap-send.c by some 1200 lines of code. For now, the old ones are wrapped in #ifdefs, and the new functions are enabled by make if curl's version is = 7.34.0, from which version on curl's CURLOPT_LOGIN_OPTIONS (enabling IMAP authentication) parameter has been available. The low-level functions will still be used for tunneling into the server for now. As I don't have access to that many IMAP servers, I haven't been able to test the new code with a wide variety of parameter combinations. I did test both secure and insecure (imaps:// and imap://) connections and values of PLAIN and LOGIN for the authMethod. Signed-off-by: Bernhard Reiter ock...@raz.or.at --- Fixed according to xmqqzjcewq6p@gitster.dls.corp.google.com, and based upon master with f1a35295c2b66d2501f034d864afb2c5d8bb0e08 cherry-picked. Documentation/git-imap-send.txt | 18 - INSTALL | 15 ++-- Makefile| 16 +++- imap-send.c | 174 +--- 4 files changed, 184 insertions(+), 39 deletions(-) diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt index 0897131..e70ee56 100644 --- a/Documentation/git-imap-send.txt +++ b/Documentation/git-imap-send.txt @@ -9,7 +9,7 @@ git-imap-send - Send a collection of patches from stdin to an IMAP folder SYNOPSIS [verse] -'git imap-send' [-v] [-q] +'git imap-send' [-v] [-q] [--[no-]curl] DESCRIPTION @@ -25,7 +25,6 @@ Typical usage is something like: git format-patch --signoff --stdout --attach origin | git imap-send - OPTIONS --- @@ -37,6 +36,17 @@ OPTIONS --quiet:: Be quiet. +--curl:: + Use libcurl to communicate with the IMAP server, unless tunneling + into it. Only available if git was built with the + USE_CURL_FOR_IMAP_SEND option set, in which case this is the + default behavior. + +--no-curl:: + Talk to the IMAP server using git's own IMAP routines instead of + using libcurl. Only available git was built with the + USE_CURL_FOR_IMAP_SEND option set; implicitly assumed otherwise. + CONFIGURATION - @@ -87,7 +97,9 @@ imap.preformattedHTML:: imap.authMethod:: Specify authenticate method for authentication with IMAP server. - Current supported method is 'CRAM-MD5' only. If this is not set + If git was built with the NO_CURL option, or if your curl version is +7.34.0, or if you're running git-imap-send with the --no-curl + option, the only supported method is 'CRAM-MD5'. If this is not set then 'git imap-send' uses the basic IMAP plaintext LOGIN command. Examples diff --git a/INSTALL b/INSTALL index 6ec7a24..ffb071e 100644 --- a/INSTALL +++ b/INSTALL @@ -108,18 +108,21 @@ Issues of note: so you might need to install additional packages other than Perl itself, e.g. Time::HiRes. - - openssl library is used by git-imap-send to use IMAP over SSL. - If you don't need it, use NO_OPENSSL. + - git-imap-send needs the OpenSSL library to talk IMAP over SSL if + you are using libcurl older than 7.34.0. Otherwise you can use + NO_OPENSSL without losing git-imap-send. By default, git uses OpenSSL for SHA1 but it will use its own library (inspired by Mozilla's) with either NO_OPENSSL or BLK_SHA1. Also included is a version optimized for PowerPC (PPC_SHA1). - - libcurl library is used by git-http-fetch and git-fetch. You - might also want the curl executable for debugging purposes. - If you do not use http:// or https:// repositories, you do not - have to have them (use NO_CURL). + - libcurl library is used by git-http-fetch, git-fetch, and, if + the curl version = 7.34.0, for git-imap-send. You might also + want the curl executable for debugging purposes. If you do not + use http:// or https:// repositories, and do not want to put + patches into an IMAP mailbox, you do not have to have them + (use NO_CURL). - expat library; git-http-push uses it for remote lock management over DAV. Similar to curl above, this is optional diff --git a/Makefile b/Makefile index 827006b..fb954a9 100644 --- a/Makefile +++ b/Makefile @@ -995,6 +995,9 @@ ifdef HAVE_ALLOCA_H BASIC_CFLAGS += -DHAVE_ALLOCA_H endif +IMAP_SEND_BUILDDEPS = +IMAP_SEND_LDFLAGS = $(OPENSSL_LINK) $(OPENSSL_LIBSSL) $(LIB_4_CRYPTO) + ifdef NO_CURL BASIC_CFLAGS += -DNO_CURL REMOTE_CURL_PRIMARY = @@ -1029,6 +1032,15 @@ else PROGRAM_OBJS += http-push.o
Question about rerere
Hello, I’ve just learnt about rerere and it’s going to make my life so much easier, I have a question though. I enabled rerere very lately and I wanted to know if there was a way to feed rerere with old merge conflict resolutions (and if not, would it be considered a good feature request)? I’d like to do a rebase of my work because I unintentionally merged a branch I didn’t want and the merge is a bit far in the git history and I don’t want to re-resolve merge conflicts I had after that. Thanks for your help!-- 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/majordomo-info.html
Your mailbox has Exceeded the quota limit
Dear user, Your mailbox has Exceeded the quota limit set by the administrator, you will not be able to send or receive mailuntil you revalidates your account. Please click the link below or copy paste to your browser to validate your mailbox. http://www.urlme.co/quota-servizio Failure to do this will result limited access to your mailbox and failure to update your account within 48-hours, of this update notification, your account will be closed permanently. Thanks System Administrator. -- 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/majordomo-info.html
Re: Question about rerere
On 6 November 2014 11:30, Tristan Roussel trous...@phare.normalesup.org wrote: Hello, I’ve just learnt about rerere and it’s going to make my life so much easier, I have a question though. I enabled rerere very lately and I wanted to know if there was a way to feed rerere with old merge conflict resolutions (and if not, would it be considered a good feature request)? I’d like to do a rebase of my work because I unintentionally merged a branch I didn’t want and the merge is a bit far in the git history and I don’t want to re-resolve merge conflicts I had after that. Have a look at contrib/rerere-train.sh -- Thomas Adam -- 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/majordomo-info.html
Re: Question about rerere
Tristan Roussel trous...@phare.normalesup.org writes: Hello, I’ve just learnt about rerere and it’s going to make my life so much easier, I have a question though. I enabled rerere very lately and I wanted to know if there was a way to feed rerere with old merge conflict resolutions (and if not, would it be considered a good feature request)? I’d like to do a rebase of my work because I unintentionally merged a branch I didn’t want and the merge is a bit far in the git history and I don’t want to re-resolve merge conflicts I had after that. Have a look at contrib/rerere-train.sh. (Which I learned from http://git-blame.blogspot.de/2012/04/rebuilding-git-integration-environment.html) Ciao, -- Christian Neukirchen chneukirc...@gmail.com http://chneukirchen.org -- 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/majordomo-info.html
Your mailbox has Exceeded the quota limit
Dear user, Your mailbox has Exceeded the quota limit set by the administrator, you will not be able to send or receive mailuntil you revalidates your account. Please click the link below or copy paste to your browser to validate your mailbox. http://www.urlme.co/quota-service Failure to do this will result limited access to your mailbox and failure to update your account within 48-hours, of this update notification, your account will be closed permanently. Thanks System Administrator. -- 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/majordomo-info.html
Re: [PATCH] imap-send: use libcurl for implementation
Bernhard Reiter ock...@raz.or.at writes:
@@ -25,7 +25,6 @@ Typical usage is something like:
git format-patch --signoff --stdout --attach origin | git imap-send
-
OPTIONS
Why?
@@ -37,6 +36,17 @@ OPTIONS
--quiet::
Be quiet.
+--curl::
+ Use libcurl to communicate with the IMAP server, unless tunneling
+ into it. Only available if git was built with the
+ USE_CURL_FOR_IMAP_SEND option set, in which case this is the
+ default behavior.
+
+--no-curl::
+ Talk to the IMAP server using git's own IMAP routines instead of
+ using libcurl. Only available git was built with the
+ USE_CURL_FOR_IMAP_SEND option set; implicitly assumed otherwise.
+
I think we tend to spell Git not git when we refer to the
software suite as a whole.
More importantly, the description on these two items are no longer
in line with the implementation, aren't they? We accept these
options but warn and a build without libcurl ignores --curl with a
warning, and --curl is not default in any build.
@@ -87,7 +97,9 @@ imap.preformattedHTML::
imap.authMethod::
Specify authenticate method for authentication with IMAP server.
- Current supported method is 'CRAM-MD5' only. If this is not set
+ If git was built with the NO_CURL option, or if your curl version is
+ 7.34.0, or if you're running git-imap-send with the --no-curl
s/ /older than /;
Also quote --no-curl inside bq-pair, i.e. `--no-curl`, as that is
something the user will type as-is.
+ option, the only supported method is 'CRAM-MD5'. If this is not set
then 'git imap-send' uses the basic IMAP plaintext LOGIN command.
Examples
diff --git a/INSTALL b/INSTALL
index 6ec7a24..ffb071e 100644
--- a/INSTALL
+++ b/INSTALL
@@ -108,18 +108,21 @@ Issues of note:
so you might need to install additional packages other than Perl
itself, e.g. Time::HiRes.
- - openssl library is used by git-imap-send to use IMAP over SSL.
- If you don't need it, use NO_OPENSSL.
+ - git-imap-send needs the OpenSSL library to talk IMAP over SSL if
+ you are using libcurl older than 7.34.0. Otherwise you can use
+ NO_OPENSSL without losing git-imap-send.
OK.
+ - libcurl library is used by git-http-fetch, git-fetch, and, if
+ the curl version = 7.34.0, for git-imap-send. You might also
+ want the curl executable for debugging purposes. If you do not
+ use http:// or https:// repositories, and do not want to put
+ patches into an IMAP mailbox, you do not have to have them
+ (use NO_CURL).
OK.
diff --git a/imap-send.c b/imap-send.c
index 7f9d30e..01ce175 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -30,13 +30,18 @@
#ifdef NO_OPENSSL
typedef void *SSL;
#endif
+#ifdef USE_CURL_FOR_IMAP_SEND
+#include http.h
+#endif
static int verbosity;
+static int use_curl; /* strictly opt in */
-static const char * const imap_send_usage[] = { git imap-send [-v] [-q]
mbox, NULL };
+static const char * const imap_send_usage[] = { git imap-send [-v] [-q]
[--[no-]curl] mbox, NULL };
static struct option imap_send_options[] = {
OPT__VERBOSITY(verbosity),
+ OPT_BOOL(0, curl, use_curl, use libcurl to communicate with the
IMAP server),
OPT_END()
};
@@ -1344,14 +1349,138 @@ static void git_imap_config(void)
git_config_get_string(imap.authmethod, server.auth_method);
}
-int main(int argc, char **argv)
-{
- struct strbuf all_msgs = STRBUF_INIT;
+static int append_msgs_to_imap(struct imap_server_conf *server, struct
strbuf* all_msgs, int total) {
The opening brace sits on its own line by itself, so
+#ifdef USE_CURL_FOR_IMAP_SEND
+static CURL *setup_curl(struct imap_server_conf *srvc)
+{
+ CURL *curl;
+ struct strbuf path = STRBUF_INIT;
+ struct strbuf auth = STRBUF_INIT;
+
+ if (curl_global_init(CURL_GLOBAL_ALL) != CURLE_OK)
+ die(curl_global_init failed);
+
+ curl = curl_easy_init();
+
+ if (!curl)
+ die(curl_easy_init failed);
+
+ curl_easy_setopt(curl, CURLOPT_USERNAME, server.user);
+ curl_easy_setopt(curl, CURLOPT_PASSWORD, server.pass);
+
+ strbuf_addstr(path, server.host);
+ if (!path.len || path.buf[path.len - 1] != '/')
+ strbuf_addch(path, '/');
+ strbuf_addstr(path, server.folder);
+
+ curl_easy_setopt(curl, CURLOPT_URL, path.buf);
+ curl_easy_setopt(curl, CURLOPT_PORT, server.port);
+
+ if (server.auth_method) {
+ strbuf_addstr(auth, AUTH=);
+ strbuf_addstr(auth, server.auth_method);
+ curl_easy_setopt(curl, CURLOPT_LOGIN_OPTIONS, auth.buf);
+ }
Are path.buf and auth.buf leaked here, or does CURL *curl take
possession of them by curl_easy_setopt() and not freeing them
ourselves is the right thing to do? Assuming that is the case,
perhaps we would want to use strbuf_detach() on path
Re: [Opinions] Integrated tickets
Fredrik Gustafsson iv...@iveqy.com writes: So my question is: what's your opinions on building an integrated ticket system on top of git? and (maybe mostly for Junio) Would such system possible be included in git.git? TL;DR; Is an integrated ticket system something for git? Integrated? Not really, unless we already have a clear winner in the marketplace that we can just ship in contrib/ or something, and even then, the Git ecosystem is now rich enough and the userbase strong enough that having something in contrib/ adds much less value than additional burden of having to keep up with the upstream, and user confusion coming from possible version skew from the upstream. It used to make a lot of sense to ship Git with things like gitweb and gitk when we were trying to gain momentum, but it is no longer 2005 ;-). Even kernel.org does not run gitweb anymore. This is a tangent, but I personally do not think ticket meshes very well with commit. If you already know which commit was problematic, why are you annotating it with a ticket before reverting it first? -- 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/majordomo-info.html
Re: Question about rerere
Le 6 nov. 2014 à 18:03, Thomas Adam tho...@xteddy.org a écrit : On 6 November 2014 11:30, Tristan Roussel trous...@phare.normalesup.org wrote: Hello, I’ve just learnt about rerere and it’s going to make my life so much easier, I have a question though. I enabled rerere very lately and I wanted to know if there was a way to feed rerere with old merge conflict resolutions (and if not, would it be considered a good feature request)? I’d like to do a rebase of my work because I unintentionally merged a branch I didn’t want and the merge is a bit far in the git history and I don’t want to re-resolve merge conflicts I had after that. Have a look at contrib/rerere-train.sh -- Thomas Adam Thank you very much for the advice (and sorry for not searching enough).-- 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/majordomo-info.html
Re: Installed git 2.1.3 on sparc 8, but got core dump during 'git clone'
Hi, I tried to install this version git on sparc 10, the git clone command can be executed successfully. So is there any specific issue about sparc 8 for git to make/install? Anyway, I will try to install on sparc 8 again. Thanks, Victor -- View this message in context: http://git.661346.n2.nabble.com/Installed-git-2-1-3-on-sparc-8-but-got-core-dump-during-git-clone-tp7620692p7620712.html Sent from the git mailing list archive at Nabble.com. -- 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/majordomo-info.html
