* Re: [PATCH 2/2] git-completion.bash: prevent 'git help' from searching for git repository
From: Junio C Hamano @ 2009-10-28 6:11 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <20091027133040.28836.qmail@fe20635a713ff7.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> Hi Junio, I suggest to apply this patch from Johannes to master.
>
> Thanks, Gerrit.
Could you help by coming up with a suitable log message?
It's a bit too much to ask me to hunt for ancient discussion to correct
the <<all the ack go here>> myself to describe what the issue was,
especially when I wasn't heavily involved in the review of the patch
itself. My impression is that the original description of the problem
and the solution in your first message does not apply to what Dscho and
you agreed to be the best solution.
>
> On Fri, Sep 04, 2009 at 11:09:36AM +0000, Gerrit Pape wrote:
>> On Fri, Sep 04, 2009 at 12:22:36PM +0200, Johannes Schindelin wrote:
>> > -- snipsnap --
>> > [PATCH] git help -a: do not look for a repository
>>
>> Perfect, thanks.
>>
>> Acked-by: Gerrit Pape <pape@smarden.org>
>>
>> > Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>> >
>> > ---
>> >
>> > builtin-help.c | 6 +++---
>> > 1 files changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/builtin-help.c b/builtin-help.c
>> > index e1eba77..719aa23 100644
>> > --- a/builtin-help.c
>> > +++ b/builtin-help.c
>> > @@ -416,9 +416,6 @@ int cmd_help(int argc, const char **argv, const char *prefix)
>> > const char *alias;
>> > load_command_list("git-", &main_cmds, &other_cmds);
>> >
>> > - setup_git_directory_gently(&nongit);
>> > - git_config(git_help_config, NULL);
>> > -
>> > argc = parse_options(argc, argv, prefix, builtin_help_options,
>> > builtin_help_usage, 0);
>> >
>> > @@ -429,6 +426,9 @@ int cmd_help(int argc, const char **argv, const char *prefix)
>> > return 0;
>> > }
>> >
>> > + setup_git_directory_gently(&nongit);
>> > + git_config(git_help_config, NULL);
>> > +
>> > if (!argv[0]) {
>> > printf("usage: %s\n\n", git_usage_string);
>> > list_common_cmds_help();
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe git" in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] imap-send.c: fix pointer to be const
From: Junio C Hamano @ 2009-10-28 6:26 UTC (permalink / raw)
To: Vietor Liu; +Cc: git
In-Reply-To: <1256706591-2763-1-git-send-email-vietor@vxwo.org>
Vietor Liu <vietor@vxwo.org> writes:
> Fixes some compiler warnings:
> imap-send.c: In function ‘ssl_socket_connect’:
> warning: assignment discards qualifiers from pointer target type
>
> Signed-off-by: Vietor Liu <vietor@vxwo.org>
I do not quite understand. This variable gets assigned the return values
from TLSv1_method() or SSLv23_method(), but the copy of ssl.h I have
declares them as:
SSL_METHOD *SSLv23_method(void); /* SSLv3 but can rollback to v2 */
SSL_METHOD *TLSv1_method(void); /* TLSv1.0 */
We would need to explain this change a bit better.
> imap-send.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/imap-send.c b/imap-send.c
> index 3847fd1..10dd025 100644
> --- a/imap-send.c
> +++ b/imap-send.c
> @@ -273,7 +273,7 @@ static int ssl_socket_connect(struct imap_socket *sock, int use_tls_only, int ve
> fprintf(stderr, "SSL requested but SSL support not compiled in\n");
> return -1;
> #else
> - SSL_METHOD *meth;
> + const SSL_METHOD *meth;
> SSL_CTX *ctx;
> int ret;
>
> --
> 1.6.5.2
^ permalink raw reply
* Re: [PATCH 0/4] Cygwin MSVC patches
From: Johannes Sixt @ 2009-10-28 6:56 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list, mstormo
In-Reply-To: <4AE7410D.3030109@ramsay1.demon.co.uk>
Ramsay Jones schrieb:
> Hi Junio,
>
> I've had these patches "hanging around" in my queue, for a few
> weeks, with every intention of adding several more to fix up
> some problems... Hmm, well I haven't got to those yet, so I
> thought I may as well pass these on.
>
> [PATCH 1/4] MSVC: Fix an "unresolved symbol" linker error on cygwin
> [PATCH 2/4] Makefile: merge two Cygwin configuration sections into one
> [PATCH 3/4] Makefile: keep MSVC and Cygwin configuration separate
> [PATCH 4/4] win32: Improve the conditional inclusion of WIN32 API code
>
> I think they are all pretty safe (famous last words), but it would be
> a good idea for someone with an MSYS/MinGW installation to test them
> (particularly patch #4; it's really the only one I'm slightly worried
> about :D).
>
> With these patches, the msvc build on cygwin seems to be working fine.
What is "the msvc build on cygwin"?
Is it "git built with msvc, then run in cygwin"?
-- Hannes
^ permalink raw reply
* Re: [PATCH] imap-send.c: fix pointer to be const
From: Vietor Liu @ 2009-10-28 7:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk4ygxce6.fsf@alter.siamese.dyndns.org>
On Tue, 2009-10-27 at 23:26 -0700, Junio C Hamano wrote:
> Vietor Liu <vietor@vxwo.org> writes:
>
> > Fixes some compiler warnings:
> > imap-send.c: In function ‘ssl_socket_connect’:
> > warning: assignment discards qualifiers from pointer target type
> >
> > Signed-off-by: Vietor Liu <vietor@vxwo.org>
>
> I do not quite understand. This variable gets assigned the return values
> from TLSv1_method() or SSLv23_method(), but the copy of ssl.h I have
> declares them as:
>
> SSL_METHOD *SSLv23_method(void); /* SSLv3 but can rollback to v2 */
> SSL_METHOD *TLSv1_method(void); /* TLSv1.0 */
1. openssl-devel-1.0.0-0.10
const SSL_METHOD *SSLv23_method(void); /* SSLv3 but can rollback to v2
*/
const SSL_METHOD *TLSv1_method(void); /* TLSv1.0 */
2. http://www.openssl.org/docs/ssl/ssl.html
const SSL_METHOD *SSLv2_method(void);
Constructor for the SSLv2 SSL_METHOD structure for combined
client and server.
const SSL_METHOD *TLSv1_method(void);
Constructor for the TLSv1 SSL_METHOD structure for combined
client and server.
3. it maybe fixes warnings for other version.
^ permalink raw reply
* Re: [PATCH] commit: More generous accepting of RFC-2822 footer lines.
From: Junio C Hamano @ 2009-10-28 7:14 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Brown, git
In-Reply-To: <20091028000511.GK10505@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> David Brown <davidb@codeaurora.org> wrote:
>> From: David Brown <davidb@quicinc.com>
>>
>> 'git commit -s' will insert a blank line before the Signed-off-by
>> line at the end of the message, unless this last line is a
>> Signed-off-by line itself. Common use has other trailing lines
>> at the ends of commit text, in the style of RFC2822 headers.
>>
>> Be more generous in considering lines to be part of this footer.
>> This may occasionally leave out the blank line for cases where
>> the commit text happens to start with a word ending in a colon,
>> but this results in less fixups than the extra blank lines with
>> Acked-by, or other custom footers.
>
> The nasty perl I use in Gerrit's commit-msg hook is a bit more
> expressive. Basically the rule is we insert a blank line before
> the new footer unless all lines in the last paragraph (so all text
> after the last "\n\n" sequence) match the regex "^[a-zA-Z0-9-]+:".
Together with your suggestion for tests, the above makes quite a lot of
sense to me.
There is one thing to be careful about.
When deciding to omit adding a new S-o-b, we deliberately check only the
last S-o-b to see if it matches what we are trying to add. This is so
that a message from you, that has my patch that was reviewed and touched
up by you with your sign-off, i.e.
S-o-b: Junio
S-o-b: Shawn
will not be prevented to have another sign-off by me, so that I can
certify that I know that your change I received from you in the patch is
kosher. IOW, this is not a "duplicate" check. The order of S-o-b:
matters as it records the flow of the patch.
^ permalink raw reply
* Re: [PATCH 1/4] Add routines for filenames encoding <local encoding> <-> UTF-8
From: Timur Sufiev @ 2009-10-28 7:15 UTC (permalink / raw)
To: Peter Krefting; +Cc: git
In-Reply-To: <alpine.DEB.2.00.0910271515270.17168@ds9.cixit.se>
>> If `i18n.filenameslocalencoding' option was set via git-config to a
>> correct <codepage> encoding, 2 things should be done:
>
> Windows supports UTF-16 file names, but need to use wchar_t APIs for fopen()
> and friends. Have you looked at any of that?
No, I didn't look towards Windows handling of Unicode, because Git under
Windows works well enough without that: I've built Git in MinGW/MSYS
environmment (using the patches we're discussing) and it handles
cyrillic filenames in Windows ANSI CP1251 codepage just as was planned:
writes filenames to tree objects in UTF-8, checks out them into working
dir in CP1251, other stuff as git-clone, git-diff, git-status, etc also
works ok. One remaining issue (offtopic here, as far as I understand) to
make TortoiseGit work with UTF-8 Git's output.
> --
> \\// Peter - http://www.softwolves.pp.se/
--
Timur Sufiev
^ permalink raw reply
* Re: git-svn: add support for merges during 'git svn fetch'
From: Junio C Hamano @ 2009-10-28 7:17 UTC (permalink / raw)
To: Eric Wong; +Cc: Nanako Shiraishi, Junio C Hamano, Sam Vilain, git
In-Reply-To: <20091027071405.GA3236@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> Thanks for the ping, I got sidetracked and forgot about this. I've
> fixed up minor formatting details, acked and pushed out Sam's changes to
> git://git.bogomips.org/git-svn along with one I small fix I originally
> sent out a bad patch for.
Thanks; pulled.
^ permalink raw reply
* Re: vl/git-gui topic
From: Junio C Hamano @ 2009-10-28 7:17 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091027182710.GF10505@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>> * vl/git-gui (2009-10-16) 1 commit.
>> - git-gui: adjust the minimum height of diff pane for shorter screen height
>>
>> Shawn?
>
> Applied to git-gui tree.
Thanks, pulled together with bunch of other changes that looked sensible.
^ permalink raw reply
* Re: [PATCH] mergetool--lib: add p4merge as a pre-configured mergetool option
From: Junio C Hamano @ 2009-10-28 7:18 UTC (permalink / raw)
To: Charles Bailey; +Cc: Scott Chacon, git list
In-Reply-To: <20091027230043.GA11607@hashpling.org>
Charles Bailey <charles@hashpling.org> writes:
> On Tue, Oct 27, 2009 at 03:36:49PM -0700, Scott Chacon wrote:
>> p4merge is now a built-in diff/merge tool.
>> This adds p4merge to git-completion and updates
>> the documentation to mention p4merge.
>> ---
>
> I approve (but haven't had a chance to test this).
Thanks; eventually you two need Sign-off and Acked-by, then, but I sense
that an undate to address the points below is in order?
> I'm just wondering, does this work well with unixes and Mac OS X? I
> think it's recommended install practice to symlink p4v as p4merge on
> *nix, but Mac OS X needs some sort of 'launchp4merge' to be called
> IIRC, or is this something that users can just configure with
> mergetool.p4diff.path?
^ permalink raw reply
* Re: [PATCH] help -i: properly error out if no info viewer can be found
From: Junio C Hamano @ 2009-10-28 7:18 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Junio C Hamano, git
In-Reply-To: <20091027133134.28975.qmail@34dfe9cde77152.315fe32.mid.smarden.org>
Thanks.
^ permalink raw reply
* Re: [PATCH v2] rebase -i: more graceful handling of invalid commands
From: Junio C Hamano @ 2009-10-28 7:18 UTC (permalink / raw)
To: Jan Krüger
Cc: Thomas Rast, kusmabite, Git Mailing List, Junio C Hamano,
Johannes Schindelin
In-Reply-To: <20091027155814.0de65db5@perceptron>
Thanks.
^ permalink raw reply
* Re: Add '--bisect' revision machinery argument
From: Junio C Hamano @ 2009-10-28 7:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.2.01.0910271124110.31845@localhost.localdomain>
Thanks.
^ permalink raw reply
* Re: [PATCH] add-interactive: handle deletion of empty files
From: Junio C Hamano @ 2009-10-28 7:18 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091028005257.GA5002@sigill.intra.peff.net>
Thanks.
^ permalink raw reply
* Re: [PATCH/RFC 2/2] completion: allow use without compiling
From: Junio C Hamano @ 2009-10-28 7:18 UTC (permalink / raw)
To: Stephen Boyd
Cc: Shawn O. Pearce, Junio C Hamano, git, Clemens Buchacher,
Sverre Rabbelier
In-Reply-To: <4AE7A1B9.5010001@gmail.com>
Stephen Boyd <bebarino@gmail.com> writes:
> Ok. Following Junio's suggestion I think we would have to do the following:
>
> (1) Revert the rename (git-completion.bash.in -> git-completion.bash)
>
> (2) Add a "generation" mode to git-completion.bash.generate to
> generate the lists and output them to a file
>
> (3) Add logic in git-completion.bash.generate to source the generated
> file if it exists
>
> (4) Source git-completion.bash.generate in git-completion.bash to get
> the functions moved there
Sorry, I do not quite see why an extra *.generate script is necessary.
^ permalink raw reply
* Re: [PATCH 5/5] http-backend: more explict LocationMatch
From: Junio C Hamano @ 2009-10-28 7:18 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Mark Lodato, git, Junio C Hamano
In-Reply-To: <20091027222435.GJ10505@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Mark Lodato <lodatom@gmail.com> wrote:
>> In the git-http-backend examples, only match git-receive-pack within
>> /git/.
>
> All 5 patches:
>
> Acked-by: Shawn O. Pearce <spearce@spearce.org>
>
> Junio, add these to my smart-http topic please. :-)
> Thanks Mark!
Thanks.
^ permalink raw reply
* Re: [PATCH 2/3] remote-helpers: return successfully if everything up-to-date
From: Junio C Hamano @ 2009-10-28 7:18 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Clemens Buchacher, Mark Lodato, git
In-Reply-To: <20091028001125.GM10505@spearce.org>
Thanks.
^ permalink raw reply
* Re: [PATCH] Fix memory leak in transport-helper
From: Junio C Hamano @ 2009-10-28 7:18 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Johannes Schindelin, Shawn O. Pearce, Junio C Hamano,
Johan Herland, Nanako Shiraishi, Sverre Rabbelier, git
In-Reply-To: <alpine.LNX.2.00.0910271456410.14365@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Tue, 27 Oct 2009, Johannes Schindelin wrote:
>
>> So you mean to imply that this method is not about closing, but about
>> releasing the structure. Right?
>
> Yes, that's the word I was failing to come up with last night, thanks.
> Junio, "s/close/release/g" on that patch should improve comprehensibility
> greatly. (And changing the transport method name would probably also
> improve matters)
Thanks, both.
^ permalink raw reply
* Re: [PATCH] bash: complete more options for 'git rebase'
From: Junio C Hamano @ 2009-10-28 7:19 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Bj�rn Gustavsson, git
In-Reply-To: <20091028003208.GO10505@spearce.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 563 bytes --]
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Bj??rn Gustavsson <bgustavsson@gmail.com> wrote:
>> Complete all long options for 'git rebase' except --no-verify
>> (probably used very seldom) and the long options corresponding
>> to -v, -q, and -f.
>>
>> Signed-off-by: Bj¶rn Gustavsson <bgustavsson@gmail.com>
>
> Acked-by: Shawn O. Pearce <spearce@spearce.org>
>
>> I am primarily interested in having the --whitespace= option completed,
>> but while at it I have added completion for the other potentially useful
>> long options.
Thanks.
^ permalink raw reply
* Re: [PATCH] Do not try to remove directories when removing old links
From: Junio C Hamano @ 2009-10-28 7:19 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: git
In-Reply-To: <hc6l9h$fn6$1@ger.gmane.org>
Thanks.
^ permalink raw reply
* Re: [PATCH] gitk: Use the --submodule option for diffs
From: Junio C Hamano @ 2009-10-28 7:19 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Paul Mackerras, Junio C Hamano, Git Mailing List
In-Reply-To: <4AE70AC9.6040302@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Instead of just showing not-quite-helpful SHA-1 pairs display the first
> lines of the corresponding commit messages in the submodule (similar to
> the output of 'git submodule summary').
>
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
> ---
>
> This patch applies to 'next' and uses the new --submodule option of git
> diff to achieve a more meaningful output of submodule differences in
> gitk.
>
> Any objections against making this the default?
It looks like you are not making this the default, but are making it
mandatory. That's quite different.
As long as gitk ships with matching version of git, I do not think it is a
huge problem to force "diff" to always run with --submodule option, but if
that is what the patch does, I'd prefer to see the patch says so, instead
of giving a false impression that there may be a way to disable it if one
wants to.
Looking at the patched text, I had to wonder where these $flags come from.
The callers of "diffcmd" give it to you, and I am not sure if all of them
want -p format diffs. Specifically, what does gettreediffs do? Does it
make sense to give --submodule to that invocation?
Yes, I know --submodule happens to be a no-op in non-patch format diffs,
but I do not think that is by design. It is something somebody may notice
and correct it later, at which time this patch will be broken.
I also suspect that this might break getpatchid, but as long as all the
patches consistently change/break ids it would be Ok.
^ permalink raw reply
* Re: [PATCH] gitignore: root most patterns at the top-level directory
From: Johannes Sixt @ 2009-10-28 7:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vmy3cys0f.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> How does .cvsignore and .svnignore work? Don't they have the same issue,
> and perhaps worse as I do not recall seeing a way to anchor a pattern to a
> particular directory like we do in their .SCMignore files? And judging
> from the fact that they can get away with the lack of that "feature", this
> perhaps is not an issue in real life?
.cvsignore and .svnignore do not apply recursively to subdirectories, do they?
> For example, it crossed my mind that perhaps we can change the ignore
> rules so that a non-globbing pattern is automatically anchored at the
> current directly but globbing ones are recursive as before.
>
> If we do so, there is no need to change the current .gitignore entires.
> You need to spell a concrete filename as a glob pattern that matches only
> one path if you want the recursive behaviour. E.g. if you have a Makefile
> per subdirectory, each of which generates and includes Makefile.depend
> file, you would write "Makefile.depen[d]" in the toplevel .gitignore file.
In one project that uses autotools, I have "Makefile" and "Makefile.in" in
the top-level .gitignore. I would be forced to use this ugliness instead.
Granted, to write "/git", "/git-add", etc in .gitignore is not exactly
pretty, either, but the reason that it is so extra-ugly in the git code
itself is only because there are so many build products in a single
directory that cannot be caught by a glob pattern. In practice, you
usually have only a hand-full non-glob ignored files per directory; it
doesn't hurt to anchor them using "/frotz" style.
> But that is a kind of incompatible change whose necessity is unproven and
> has to cook and wait.
I would be concerned by this change.
-- Hannes
^ permalink raw reply
* [PATCH] imap-send.c: fix pointer to be const
From: Vietor Liu @ 2009-10-28 7:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Fixes some compiler warnings:
imap-send.c: In function ‘ssl_socket_connect’:
warning: assignment discards qualifiers from pointer target type
====================================================
OpenSSL Changes between 0.9.8k and 1.0:
*) Let the TLSv1_method() etc. functions return a 'const' SSL_METHOD
pointer and make the SSL_METHOD parameter in SSL_CTX_new,
SSL_CTX_set_ssl_version and SSL_set_ssl_method 'const'.
Signed-off-by: Vietor Liu <vietor@vxwo.org>
---
imap-send.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 3847fd1..10dd025 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -273,7 +273,7 @@ static int ssl_socket_connect(struct imap_socket *sock, int use_tls_only, int ve
fprintf(stderr, "SSL requested but SSL support not compiled in\n");
return -1;
#else
- SSL_METHOD *meth;
+ const SSL_METHOD *meth;
SSL_CTX *ctx;
int ret;
--
1.6.5.2
^ permalink raw reply related
* [PATCH v2] imap-send.c: fix pointer to be const
From: Vietor Liu @ 2009-10-28 7:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Fixes some compiler warnings:
imap-send.c: In function ‘ssl_socket_connect’:
warning: assignment discards qualifiers from pointer target type
====================================================
OpenSSL Changes between 0.9.8k and 1.0:
*) Let the TLSv1_method() etc. functions return a 'const' SSL_METHOD
pointer and make the SSL_METHOD parameter in SSL_CTX_new,
SSL_CTX_set_ssl_version and SSL_set_ssl_method 'const'.
Signed-off-by: Vietor Liu <vietor@vxwo.org>
---
imap-send.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 3847fd1..10dd025 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -273,7 +273,7 @@ static int ssl_socket_connect(struct imap_socket *sock, int use_tls_only, int ve
fprintf(stderr, "SSL requested but SSL support not compiled in\n");
return -1;
#else
- SSL_METHOD *meth;
+ const SSL_METHOD *meth;
SSL_CTX *ctx;
int ret;
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH] imap-send.c: fix pointer to be const
From: Junio C Hamano @ 2009-10-28 7:25 UTC (permalink / raw)
To: Vietor Liu; +Cc: Junio C Hamano, git
In-Reply-To: <1256714677-3659-1-git-send-email-vietor@vxwo.org>
Vietor Liu <vietor@vxwo.org> writes:
> Fixes some compiler warnings:
> imap-send.c: In function ‘ssl_socket_connect’:
> warning: assignment discards qualifiers from pointer target type
>
> ====================================================
> OpenSSL Changes between 0.9.8k and 1.0:
>
> *) Let the TLSv1_method() etc. functions return a 'const' SSL_METHOD
> pointer and make the SSL_METHOD parameter in SSL_CTX_new,
> SSL_CTX_set_ssl_version and SSL_set_ssl_method 'const'.
>
> Signed-off-by: Vietor Liu <vietor@vxwo.org>
This is much easier to understand.
Thanks.
> ---
> imap-send.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/imap-send.c b/imap-send.c
> index 3847fd1..10dd025 100644
> --- a/imap-send.c
> +++ b/imap-send.c
> @@ -273,7 +273,7 @@ static int ssl_socket_connect(struct imap_socket *sock, int use_tls_only, int ve
> fprintf(stderr, "SSL requested but SSL support not compiled in\n");
> return -1;
> #else
> - SSL_METHOD *meth;
> + const SSL_METHOD *meth;
> SSL_CTX *ctx;
> int ret;
>
> --
> 1.6.5.2
^ permalink raw reply
* Re: [PATCH/RFC 2/2] completion: allow use without compiling
From: Stephen Boyd @ 2009-10-28 7:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git, Clemens Buchacher, Sverre Rabbelier
In-Reply-To: <7v63a0t29l.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Stephen Boyd <bebarino@gmail.com> writes:
>> Ok. Following Junio's suggestion I think we would have to do the following:
>>
>> (1) Revert the rename (git-completion.bash.in -> git-completion.bash)
>>
>> (2) Add a "generation" mode to git-completion.bash.generate to
>> generate the lists and output them to a file
>>
>> (3) Add logic in git-completion.bash.generate to source the generated
>> file if it exists
>>
>> (4) Source git-completion.bash.generate in git-completion.bash to get
>> the functions moved there
>
> Sorry, I do not quite see why an extra *.generate script is necessary.
I'm still assuming the generation mode has to be sh agnostic, therefore
requiring those functions to be in another *.generate script. Is that wrong?
^ 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