* [RFC/WIP PATCH 3/3] submodule: simplify decision tree whether to or not to fetch
From: Heiko Voigt @ 2013-02-25 1:06 UTC (permalink / raw)
To: git; +Cc: Jens Lehmann
In-Reply-To: <cover.1361751905.git.hvoigt@hvoigt.net>
To make extending this logic later easier.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
submodule.c | 50 +++++++++++++++++++++++++++-----------------------
1 file changed, 27 insertions(+), 23 deletions(-)
diff --git a/submodule.c b/submodule.c
index b603000..a6fe16e 100644
--- a/submodule.c
+++ b/submodule.c
@@ -737,6 +737,23 @@ static void calculate_changed_submodule_paths(void)
submodule_config_cache_free(&submodule_config_cache);
}
+static int get_fetch_recurse_config(const char *name, int command_line_option)
+{
+ if (command_line_option != RECURSE_SUBMODULES_DEFAULT)
+ return command_line_option;
+
+ struct string_list_item *fetch_recurse_submodules_option;
+ fetch_recurse_submodules_option = unsorted_string_list_lookup(&config_fetch_recurse_submodules_for_name, name);
+ if (fetch_recurse_submodules_option)
+ /* local config overrules everything except commandline */
+ return (intptr_t)fetch_recurse_submodules_option->util;
+
+ if (gitmodules_is_unmerged)
+ return RECURSE_SUBMODULES_OFF;
+
+ return config_fetch_recurse_submodules;
+}
+
int fetch_populated_submodules(const struct argv_array *options,
const char *prefix, int command_line_option,
int quiet)
@@ -781,32 +798,19 @@ int fetch_populated_submodules(const struct argv_array *options,
if (name_for_path)
name = name_for_path->util;
- default_argv = "yes";
- if (command_line_option == RECURSE_SUBMODULES_DEFAULT) {
- struct string_list_item *fetch_recurse_submodules_option;
- fetch_recurse_submodules_option = unsorted_string_list_lookup(&config_fetch_recurse_submodules_for_name, name);
- if (fetch_recurse_submodules_option) {
- if ((intptr_t)fetch_recurse_submodules_option->util == RECURSE_SUBMODULES_OFF)
- continue;
- if ((intptr_t)fetch_recurse_submodules_option->util == RECURSE_SUBMODULES_ON_DEMAND) {
- if (!unsorted_string_list_lookup(&changed_submodule_names, name))
- continue;
- default_argv = "on-demand";
- }
- } else {
- if ((config_fetch_recurse_submodules == RECURSE_SUBMODULES_OFF) ||
- gitmodules_is_unmerged)
- continue;
- if (config_fetch_recurse_submodules == RECURSE_SUBMODULES_ON_DEMAND) {
- if (!unsorted_string_list_lookup(&changed_submodule_names, name))
- continue;
- default_argv = "on-demand";
- }
- }
- } else if (command_line_option == RECURSE_SUBMODULES_ON_DEMAND) {
+ switch (get_fetch_recurse_config(name, command_line_option)) {
+ default:
+ case RECURSE_SUBMODULES_DEFAULT:
+ case RECURSE_SUBMODULES_ON_DEMAND:
if (!unsorted_string_list_lookup(&changed_submodule_names, name))
continue;
default_argv = "on-demand";
+ break;
+ case RECURSE_SUBMODULES_ON:
+ default_argv = "yes";
+ break;
+ case RECURSE_SUBMODULES_OFF:
+ continue;
}
strbuf_addf(&submodule_path, "%s/%s", work_tree, ce->name);
--
1.8.2.rc0.25.g5062c01
^ permalink raw reply related
* Re: Certificate validation vulnerability in Git
From: Zubin Mithra @ 2013-02-25 2:28 UTC (permalink / raw)
To: ae; +Cc: git, Dhanesh K.
In-Reply-To: <512A601B.80807@op5.se>
Hello,
On Mon, Feb 25, 2013 at 12:16 AM, Andreas Ericsson <ae@op5.se> wrote:
> On 02/24/2013 06:31 PM, Zubin Mithra wrote:
>> Hello,
>>
>> There seems to be a security issue in the way git uses openssl for
>> certificate validation. Similar occurrences have been found and
>> documented in other open source projects, the research can be found at
>> [1].
>>
>> -=========]
>> - imap-send.c
>>
>> Line 307
>>
>> 307 ret = SSL_connect(sock->ssl);
>> 308 if (ret <= 0) {
>> 309 socket_perror("SSL_connect", sock, ret);
>> 310 return -1;
>> 311 }
>> 312
>>
>> Certificate validation errors are signaled either through return
>> values of SSL_connect or by setting internal flags. The internal flags
>> need to be checked using the SSL_get_verify_result function. This is
>> not performed.
>>
>> Kindly fix these issues, file a CVE and credit it to Dhanesh K. and
>> Zubin Mithra. Thanks.
>>
>
> The lack of certificate authority verification presents no attack vector
> for git imap-send. As such, it doesn't warrant a CVE. I'm sure you'll
> be credited with a "reported-by" line in the commit message if someone
> decides to fix it though. Personally, I'm not fussed.
I'd like to add in a few points -- generally SSL/TLS would be used in
cases where the authenticity of the server and confidentiality of the
messages transferred would be required. In this particular case, the
threat scenarios would be :-
- Usage of an invalid attacker certificate could result in the
attacker gaining access to authentication information sent over the
wire.
- If the code repository were private, the patches thus generated are
also assumed to be kept private. An invalid certificate check at the
client side would enable an attacker to gain access to those patches.
Is there anything I'm missing? I believe this is a valid security issue.
Thanks,
Zubin
>
>> We are not subscribed to this list, so we'd appreciate it if you could
>> CC us in the replies.
>>
>
> That's standard on this list. Please follow the same convention if/when
> you reply. Thanks.
>
> --
> Andreas Ericsson andreas.ericsson@op5.se
> OP5 AB www.op5.se
> Tel: +46 8-230225 Fax: +46 8-230231
>
> Considering the successes of the wars on alcohol, poverty, drugs and
> terror, I think we should give some serious thought to declaring war
> on peace.
^ permalink raw reply
* Re: Certificate validation vulnerability in Git
From: Jeff King @ 2013-02-25 3:16 UTC (permalink / raw)
To: Zubin Mithra; +Cc: git, Dhanesh K.
In-Reply-To: <CAA5xPpmmZuMK7q3-pTOx4L6DxFtyw5HWYdH7kHEsK=96KM5kAQ@mail.gmail.com>
On Sun, Feb 24, 2013 at 11:01:50PM +0530, Zubin Mithra wrote:
> There seems to be a security issue in the way git uses openssl for
> certificate validation. Similar occurrences have been found and
> documented in other open source projects, the research can be found at
> [1].
>
> -=========]
> - imap-send.c
>
> Line 307
>
> 307 ret = SSL_connect(sock->ssl);
> 308 if (ret <= 0) {
> 309 socket_perror("SSL_connect", sock, ret);
> 310 return -1;
> 311 }
> 312
>
> Certificate validation errors are signaled either through return
> values of SSL_connect or by setting internal flags. The internal flags
> need to be checked using the SSL_get_verify_result function. This is
> not performed.
I'm not sure what you mean. We use SSL_CTX_set_verify to turn on peer
certificate verification, which will cause SSL_connect to return
failure if the certificate signature cannot be traced back to a CA cert
from our local store.
Is there some case where this does not happen properly? If so, can you
give an example? The paper you referenced says only that there are some
special cases where SSL_connect does not notice the error, but then
gives an example where the application does not turn on SSL_VERIFY_PEER.
But git does. Are there are other cases that SSL_VERIFY_PEER does not
handle?
There is a _different_ problem not handled by the code you show above,
which is that SSL_connect does not verify that the hostname we connected
to matches the signed certificate. But that was fixed already by b62fb07
(imap-send: the subject of SSL certificate must match the host,
2013-02-15), which is in git v1.8.1.4.
-Peff
^ permalink raw reply
* Re: Certificate validation vulnerability in Git
From: Jeff King @ 2013-02-25 3:18 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Zubin Mithra, git, Dhanesh K.
In-Reply-To: <512A601B.80807@op5.se>
On Sun, Feb 24, 2013 at 07:46:51PM +0100, Andreas Ericsson wrote:
> The lack of certificate authority verification presents no attack vector
> for git imap-send. As such, it doesn't warrant a CVE. I'm sure you'll
> be credited with a "reported-by" line in the commit message if someone
> decides to fix it though. Personally, I'm not fussed.
Sure it presents an attack vector. I can man-in-the-middle your
imap-send client and read your otherwise secret patches. Or your
otherwise secret imap password.
-Peff
^ permalink raw reply
* Re: [PATCH 05/13] Help.c: add list_common_guides_help() function
From: Junio C Hamano @ 2013-02-25 5:24 UTC (permalink / raw)
To: Philip Oakley; +Cc: GitList
In-Reply-To: <4AEE9909C70D4810A228A367FB888AF4@PhilipOakley>
"Philip Oakley" <philipoakley@iee.org> writes:
> From: "Junio C Hamano" <gitster@pobox.com>
> Sent: Sunday, February 24, 2013 9:01 AM
>> Philip Oakley <philipoakley@iee.org> writes:
>>
>>> diff --git a/common-guides.h b/common-guides.h
>>> new file mode 100644
>>> index 0000000..a8ad8d1
>>> --- /dev/null
>>> +++ b/common-guides.h
>>> @@ -0,0 +1,12 @@
>>> +/* Automatically generated by ./generate-guidelist.sh */
>>> +/* re-use struct cmdname_help in common-commands.h */
>>
>> Huh?
> The first comment line fortells of patch 6 which can generate this .h
> file.
The Huh? was about that one, not about reuse. I do not want to see
a build artifact kept in the history without a good reason.
^ permalink raw reply
* Re: [PATCH 12/13] Documentation/Makefile: update git guide links
From: Junio C Hamano @ 2013-02-25 5:29 UTC (permalink / raw)
To: Philip Oakley; +Cc: GitList
In-Reply-To: <1361660761-1932-13-git-send-email-philipoakley@iee.org>
Philip Oakley <philipoakley@iee.org> writes:
> @@ -35,6 +37,8 @@ MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
> MAN_HTML=$(patsubst %.txt,%.html,$(MAN_TXT))
>
> OBSOLETE_HTML = git-remote-helpers.html
> +OBSOLETE_HTML = everyday.html
> +OBSOLETE_HTML = user-manual.html
> DOC_HTML=$(MAN_HTML) $(OBSOLETE_HTML)
If you are keeping track of inventory of "guides" in a new static
array, do you still need to look up "giteveryday" or "gituser-manual"
when the user asks for guide documents?
In other words, can't you change the side that launches the document
viewer so that we do not have to rename anything in the first place?
^ permalink raw reply
* [PATCH] Small grammar fix
From: Greg Price @ 2013-02-25 5:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
"Advice" is a mass noun, not a count noun; it's not
ordinarily pluralized.
(I've never seen "advices" before, and to double-check that this isn't
an idiosyncrasy of mine I checked the Google Ngram data:
http://books.google.com/ngrams/graph?content=advice%2Cadvices
which shows "advices" is <1/100 as common as "advice".)
Signed-off-by: Greg Price <price@mit.edu>
---
Documentation/config.txt | 2 +-
t/t7512-status-help.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index e452ff8..dbb2faf 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -168,7 +168,7 @@ advice.*::
Advice shown when linkgit:git-merge[1] refuses to
merge to avoid overwriting local changes.
resolveConflict::
- Advices shown by various commands when conflicts
+ Advice shown by various commands when conflicts
prevent the operation from being performed.
implicitIdentity::
Advice on how to set your identity configuration when
diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
index b3f6eb9..95d6510 100755
--- a/t/t7512-status-help.sh
+++ b/t/t7512-status-help.sh
@@ -5,7 +5,7 @@
# Grenoble INP Ensimag
#
-test_description='git status advices'
+test_description='git status advice'
. ./test-lib.sh
--
1.7.11.3
^ permalink raw reply related
* [PATCH] describe: Document --match pattern format
From: Greg Price @ 2013-02-25 5:29 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
It's not clear in git-describe(1) what kind of "pattern" should be
passed to --match. Fix that.
Signed-off-by: Greg Price <price@mit.edu>
---
Documentation/git-describe.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index 72d6bb6..711040d 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -81,8 +81,9 @@ OPTIONS
that points at object deadbee....).
--match <pattern>::
- Only consider tags matching the given pattern (can be used to avoid
- leaking private tags made from the repository).
+ Only consider tags matching the given `glob(7)` pattern,
+ excluding the "refs/tags/" prefix. This can be used to avoid
+ leaking private tags from the repository.
--always::
Show uniquely abbreviated commit object as fallback.
--
1.7.11.3
^ permalink raw reply related
* [PATCH] Fix ".git/refs" stragglers
From: Greg Price @ 2013-02-25 5:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
A couple of references still survive to .git/refs as a tree
of all refs. Fix one in docs, one in a -h message, one in
a -h message quoted in docs.
Signed-off-by: Greg Price <price@mit.edu>
---
Documentation/config.txt | 2 +-
Documentation/gitcli.txt | 9 +++++----
builtin/describe.c | 4 ++--
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index dbb2faf..6eb013a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -423,7 +423,7 @@ core.sharedRepository::
core.warnAmbiguousRefs::
If true, git will warn you if the ref name you passed it is ambiguous
- and might match multiple refs in the .git/refs/ tree. True by default.
+ and might match multiple refs in the repository. True by default.
core.compression::
An integer -1..9, indicating a default compression level.
diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt
index 3bc1500..d59a5ad 100644
--- a/Documentation/gitcli.txt
+++ b/Documentation/gitcli.txt
@@ -107,13 +107,14 @@ couple of magic command line options:
---------------------------------------------
$ git describe -h
usage: git describe [options] <committish>*
+ or: git describe [options] --dirty
--contains find the tag that comes after the commit
--debug debug search strategy on stderr
- --all use any ref in .git/refs
- --tags use any tag in .git/refs/tags
- --abbrev [<n>] use <n> digits to display SHA-1s
- --candidates <n> consider <n> most recent tags (default: 10)
+ --all use any ref
+ --tags use any tag, even unannotated
+ --long always use long format
+ --abbrev[=<n>] use <n> digits to display SHA-1s
---------------------------------------------
--help-all::
diff --git a/builtin/describe.c b/builtin/describe.c
index 90a72af..2ef3f10 100644
--- a/builtin/describe.c
+++ b/builtin/describe.c
@@ -402,8 +402,8 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
struct option options[] = {
OPT_BOOLEAN(0, "contains", &contains, N_("find the tag that comes after the commit")),
OPT_BOOLEAN(0, "debug", &debug, N_("debug search strategy on stderr")),
- OPT_BOOLEAN(0, "all", &all, N_("use any ref in .git/refs")),
- OPT_BOOLEAN(0, "tags", &tags, N_("use any tag in .git/refs/tags")),
+ OPT_BOOLEAN(0, "all", &all, N_("use any ref")),
+ OPT_BOOLEAN(0, "tags", &tags, N_("use any tag, even unannotated")),
OPT_BOOLEAN(0, "long", &longformat, N_("always use long format")),
OPT__ABBREV(&abbrev),
OPT_SET_INT(0, "exact-match", &max_candidates,
--
1.7.11.3
^ permalink raw reply related
* Re: Certificate validation vulnerability in Git
From: Junio C Hamano @ 2013-02-25 5:35 UTC (permalink / raw)
To: Jeff King; +Cc: Andreas Ericsson, Zubin Mithra, git, Dhanesh K.
In-Reply-To: <20130225031847.GB31988@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Feb 24, 2013 at 07:46:51PM +0100, Andreas Ericsson wrote:
>
>> The lack of certificate authority verification presents no attack vector
>> for git imap-send. As such, it doesn't warrant a CVE. I'm sure you'll
>> be credited with a "reported-by" line in the commit message if someone
>> decides to fix it though. Personally, I'm not fussed.
>
> Sure it presents an attack vector. I can man-in-the-middle your
> imap-send client and read your otherwise secret patches. Or your
> otherwise secret imap password.
Yes, the lack of verification alone will not hurt the victim; you
would need to also be able to insert yourself in the middle, perhaps
by poisoning the victim's DNS. But one of the points of using
SSL/TLS is to resist such an attack, and it certainly is an attack
surfce, even though it may be of a lessor kind than other kinds of
attacks.
^ permalink raw reply
* [PATCH 2/2] describe: Exclude --all --match=PATTERN
From: Greg Price @ 2013-02-25 5:31 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Currently when --all is passed, the effect of --match is only
to demote non-matching tags to be treated like non-tags. This
is puzzling behavior and not consistent with the documentation,
especially with the suggested usage of avoiding information leaks.
The combination of --all and --match is an oxymoron anyway, so
just forbid it.
Signed-off-by: Greg Price <price@mit.edu>
---
This should be applied after the preceding patch; I mistakenly omitted
the '1/2' in its subject line.
Documentation/git-describe.txt | 3 ++-
builtin/describe.c | 3 +++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index 711040d..fd5d8f2 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -83,7 +83,8 @@ OPTIONS
--match <pattern>::
Only consider tags matching the given `glob(7)` pattern,
excluding the "refs/tags/" prefix. This can be used to avoid
- leaking private tags from the repository.
+ leaking private tags from the repository. This option is
+ incompatible with `--all`.
--always::
Show uniquely abbreviated commit object as fallback.
diff --git a/builtin/describe.c b/builtin/describe.c
index 04c185b..90a72af 100644
--- a/builtin/describe.c
+++ b/builtin/describe.c
@@ -435,6 +435,9 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
if (longformat && abbrev == 0)
die(_("--long is incompatible with --abbrev=0"));
+ if (pattern && all)
+ die(_("--match is incompatible with --all"));
+
if (contains) {
const char **args = xmalloc((7 + argc) * sizeof(char *));
int i = 0;
--
1.7.11.3
^ permalink raw reply related
* Re: [RFC/WIP PATCH 1/3] teach config parsing to read from strbuf
From: Junio C Hamano @ 2013-02-25 5:54 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git, Jens Lehmann
In-Reply-To: <6c69068b4e6a72a2cca5dc6eaffa9982032a7f2a.1361751905.git.hvoigt@hvoigt.net>
Heiko Voigt <hvoigt@hvoigt.net> writes:
> diff --git a/config.c b/config.c
> index aefd80b..f995e98 100644
> --- a/config.c
> +++ b/config.c
> @@ -13,6 +13,9 @@
> typedef struct config_file {
> struct config_file *prev;
> FILE *f;
> + int is_strbuf;
> + struct strbuf *strbuf_contents;
> + int strbuf_pos;
> const char *name;
> int linenr;
> int eof;
The idea to allow more kinds of sources specified for "config_file"
structure is not bad per-se, but whenever you design an enhancement
to something that currently supports only on thing to allow taking
another kind, please consider what needs to be done by the next
person who adds the third kind. That would help catch design
mistakes early. For example, will the "string-list" (I am not
saying use of string-list makes sense as the third kind; just as an
example off the top of my head) source patch add
int is_string_list;
struct string_list *string_list_contents;
fields to this structure? Sounds insane for at least two reasons:
* if both is_strbuf and is_string_list are true, what should
happen?
* is there a good reason to waste storage for the three fields your
patch adds when sring_list strage (or FILE * storage for that
matter) is used?
The helper functions like config_fgetc() and config_ftell() sounds
like you are going in the right direction but may want to do the
OO-in-C in a similar way transport.c does, keeping a pointer to a
structure of methods, but I didn't read the remainder of this patch
very carefully enough to comment further.
^ permalink raw reply
* Re: [PATCH] Spelling fixes.
From: Junio C Hamano @ 2013-02-25 6:34 UTC (permalink / raw)
To: René Scharfe; +Cc: Ville Skyttä, git
In-Reply-To: <51290905.10008@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Am 23.02.2013 15:31, schrieb Ville Skyttä:
>>
>> Signed-off-by: Ville Skyttä <ville.skytta@iki.fi>
>> ---
>> Documentation/RelNotes/1.7.5.4.txt | 2 +-
>> Documentation/RelNotes/1.7.8.txt | 2 +-
>
> Retroactively changing release notes for older versions is not worth
> it, I think.
>
>> Documentation/RelNotes/1.8.2.txt | 2 +-
>
> Fixing typos in this draft for the next release is a good idea, though.
>
>> kwset.c | 4 ++--
>
>> xdiff/xdiffi.c | 2 +-
>
> These files come from external sources and it would be nice to push
> fixes (not just for typos) upstream as well.
>
> René
A good suggestion. Thanks.
^ permalink raw reply
* Re: [PATCH v2 0/2] improve-wincred-compatibility
From: Junio C Hamano @ 2013-02-25 6:43 UTC (permalink / raw)
To: kusmabite; +Cc: blees, git, msysgit, Jeff King
In-Reply-To: <CABPQNSaUizZPVOeeuEyb=o-Qmm4mYCRxV27qkmp62cSpFkinqA@mail.gmail.com>
Erik Faye-Lund <kusmabite@gmail.com> writes:
> On Thu, Jan 10, 2013 at 1:10 PM, Karsten Blees <karsten.blees@gmail.com> wrote:
>> Changes since initial version (see attached diff for details):
>> - split in two patches
>> - removed unused variables
>> - improved the dll error message
>> - changed ?: to if else
>> - added comments
>>
>> Also available here:
>> https://github.com/kblees/git/tree/kb/improve-wincred-compatibility-v2
>> git pull git://github.com/kblees/git.git kb/improve-wincred-compatibility-v2
>>
>> Karsten Blees (2):
>> wincred: accept CRLF on stdin to simplify console usage
>> wincred: improve compatibility with windows versions
>>
>> .../credential/wincred/git-credential-wincred.c | 206 ++++++++-------------
>> 1 file changed, 75 insertions(+), 131 deletions(-)
>>
>
> Wonderful!
>
> Acked-by: Erik Faye-Lund <kusmabite@gmail.com>
I'm in the "marking leftover bits" mode today, and noticed that
nothing happened for this topic in my tree. Did msysgit folks expect
me to pick this up directly, or did you guys want to feed this series
to me (with possibly other changes you worked on outside this list)?
^ permalink raw reply
* Re: [PATCH/RFC] mingw: rename WIN32 cpp macro to NATIVE_WINDOWS
From: Junio C Hamano @ 2013-02-25 6:44 UTC (permalink / raw)
To: git
Cc: Jonathan Nieder, Eric Blake, Mark Levedahl, Alex Riesen,
Jason Pyeron, Torsten Bögershausen,
Stephen & Linda Smith, Ramsay Jones
In-Reply-To: <5106C382.20009@ramsay1.demon.co.uk>
Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> Jonathan Nieder wrote:
>
>> Throughout git, it is assumed that the WIN32 preprocessor symbol is
>> defined on native Windows setups (mingw and msvc) and not on Cygwin.
>> On Cygwin, most of the time git can pretend this is just another Unix
>> machine, and Windows-specific magic is generally counterproductive.
>>
>> Unfortunately Cygwin *does* define the WIN32 symbol in some headers.
>> Best to rely on a new git-specific symbol NATIVE_WINDOWS instead,
>> defined as follows:
>>
>> #if defined(WIN32) && !defined(__CYGWIN__)
>> # define NATIVE_WINDOWS
>> #endif
>>
>> After this change, it should be possible to drop the
>> CYGWIN_V15_WIN32API setting without any negative effect.
>>
>> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
>
> If we go with this approach, could we prefix the symbol name with GIT_
> in order to reduce the global namespace pollution?
>
> eg GIT_NATIVE_WINDOWS, or GIT_NATIVE_WIN32 or just GIT_WIN32.
> (Yeah, I'm not good at choosing names!)
I was in "find leftover bits" mode today and found this thread hanging.
Has anything come out of this thread, or there is nothing to improve
in this area?
^ permalink raw reply
* Re: [PATCH] Support FTP-over-SSL/TLS for regular FTP
From: Junio C Hamano @ 2013-02-25 6:44 UTC (permalink / raw)
To: Modestas Vainius; +Cc: Matt Kraai, git
In-Reply-To: <7057807.F3QETssImX@mdxdesktop>
Modestas Vainius <modestas@vainius.eu> writes:
> Hello,
>
> Saturday 12 January 2013 06:25:21 rašė:
>> On Sat, Jan 12, 2013 at 03:59:52PM +0200, Modestas Vainius wrote:
>> > @@ -306,6 +311,11 @@ static CURL *get_curl_handle(void)
>> >
>> > if (curl_ftp_no_epsv)
>> >
>> > curl_easy_setopt(result, CURLOPT_FTP_USE_EPSV, 0);
>> >
>> > +#ifdef CURLOPT_USE_SSL
>> > + if (curl_ssl_try)
>> > + curl_easy_setopt(result, CURLOPT_USE_SSL, CURLUSESSL_TRY);
>> > +#endif
>> > +
>> >
>> > if (curl_http_proxy) {
>> >
>> > curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
>> > curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
>>
>> It looks like the indentation of the "if" line you added is messed up.
>
> Yeah, sorry about that. I will fix it.
Did anything happen to this topic since then?
^ permalink raw reply
* Re: [PATCH] rebase --preserve-merges keeps empty merge commits
From: Junio C Hamano @ 2013-02-25 6:44 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: Phil Hord, git, phil.hord, Neil Horman
In-Reply-To: <CANiSa6gM1gpj0A6PC0qNVSaWvVrOBnSnjn2uKR9-cHSLAZ2OVA@mail.gmail.com>
Martin von Zweigbergk <martinvonz@gmail.com> writes:
> I'm working on a re-roll of
>
> http://thread.gmane.org/gmane.comp.version-control.git/205796
>
> and finally got around to including test cases for what you fixed in
> this patch. I want to make sure I'm testing what you fixed here. See
> questions below.
Did anything further happen to this topic?
^ permalink raw reply
* Re: [RFC] git rm -u
From: Junio C Hamano @ 2013-02-25 6:54 UTC (permalink / raw)
To: Eric James Michael Ritz; +Cc: Antoine Pelisse, Tomas Carnecky, git
In-Reply-To: <50FB1673.8020808@gmail.com>
Eric James Michael Ritz <lobbyjones@gmail.com> writes:
> On 01/19/2013 04:49 PM, Antoine Pelisse wrote:
>> I think `git add -u` would be closer. It would stage removal of
>> files, but would not stage untracked files. It would stage other
>> type of changes though.
>
> On Sat, Jan 19, 2013 at 10:47 PM, Tomas Carnecky
>> Does `git add -A` do what you want?
>
> Thank you Tomas and Antoine. Both of these commands do what I want:
> stage deleted files on the index. But does the idea of a `git rm -u`
> still sound useful since these commands also stage changes besides
> deleted files?
Even though I am not sure how often I would use it myself, "reflect
only the removals in the working tree to the index, but exclude any
other kind of changes" might turn out to be a useful addition to the
toolchest in certain cases.
I however am not yet convinced that "git rm -u" is a good way to
express the feature at the UI. "git add -u" is "update the index
with modification and removal but ignore new files because we won't
know if they are garbage or assets". What the same "-u" option
means in the context of "git rm" is not very clear, at least to me.
^ permalink raw reply
* Re: [PATCH 0/7] perl/Git.pm: a bunch of fixes for Windows
From: Junio C Hamano @ 2013-02-25 6:54 UTC (permalink / raw)
To: git; +Cc: Gustavo L. de M. Chaves
In-Reply-To: <1359566583-19654-1-git-send-email-gnustavo@cpan.org>
"Gustavo L. de M. Chaves" <gnustavo@cpan.org> writes:
> ...
> While working on porting Git::Hooks to Windows I stumbled upon a few
> problems in the Git module, problems specific to the Windows
> environment. In the following sequence of patches I try to fix them.
Any comment on this from Windows folks?
^ permalink raw reply
* Re: [PATCH 1/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA.
From: Junio C Hamano @ 2013-02-25 6:54 UTC (permalink / raw)
To: git; +Cc: TJ
In-Reply-To: <510AA1E7.9070704@iam.tj>
TJ <git@iam.tj> writes:
> On 31/01/13 15:51, Junio C Hamano wrote:
>> TJ <git@iam.tj> writes:
>>
>>> + $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(man1dir)
>>> + $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(man5dir)
>>> + $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(man7dir)
>>> + $(INSTALL) -m $(INSTALL_MODE_DATA) $(DOC_MAN1) $(DESTDIR)$(man1dir)
>>> + $(INSTALL) -m $(INSTALL_MODE_DATA) $(DOC_MAN5) $(DESTDIR)$(man5dir)
>>> + $(INSTALL) -m $(INSTALL_MODE_DATA) $(DOC_MAN7) $(DESTDIR)$(man7dir)
>>
>> I'm tempted to suggest
>>
>> INSTALL_DIR = $(INSTALL) -d -m 755
>> INSTALL_DATA = $(INSTALL) -m 644
>> INSTALL_PROGRAM = $(INSTALL) -m 755
>>
>> The number of lines the patch needs to touch will be the same, but
>> the resulting lines will not have many $(INSTALL_MODE_BLAH) shouting
>> at us.
>
> I did contemplate that but was concerned it might be seen as interfering unduly with
> the tool name/path settings, as opposed to their options.
>
>> Besides, you would want to differentiate the two kinds of 755 anyway
>> (I'd prefer INSTALL_PROGRAM to use -m 555 personally, for example).
>
> Yes, I think I lost that one in the mists of sed-land when making the changes :)
>
> I'll revise the patch based on received comments and post the revision tomorrow.
Did anything come out of this discussion?
^ permalink raw reply
* Re: [PATCH 0/5] Fix msvc build
From: Junio C Hamano @ 2013-02-25 6:54 UTC (permalink / raw)
To: GIT Mailing-list
Cc: Ramsay Jones, Erik Faye-Lund, Jonathan Nieder, Johannes Sixt,
Johannes Schindelin
In-Reply-To: <510AB766.4030806@ramsay1.demon.co.uk>
Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> As I mentioned recently, while discussing a cygwin specific patch
> (see "Version 1.8.1 does not compile on Cygwin 1.7.14" thread), the
> MSVC build is broken for me.
>
> The first 4 patches fix the MSVC build for me. The final patch is
> not really related to fixing the build, but it removed some make
> warnings which were quite irritating ...
>
> Note that I used the Makefile, with the Visual C++ 2008 command
> line compiler on Windows XP (SP3), to build a vanilla git on MinGW.
> I'm not subscribed to the msysgit mailing list, nor do I follow the
> msysgit fork of git, so these patches may conflict with commits in
> their repository.
Did anything further happen to this topic in the Windows land?
^ permalink raw reply
* Re: [PATH/RFC] Revert "compat: add strtok_r()"
From: Junio C Hamano @ 2013-02-25 6:55 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, David Michael Barr, Jonathan Nieder
In-Reply-To: <20130201204927.GG12368@google.com>
Care to tie the loose end on this one, with a sign-off?
^ permalink raw reply
* Re: [BUG] Git clone of a bundle fails, but works (somewhat) when run with strace
From: Junio C Hamano @ 2013-02-25 6:59 UTC (permalink / raw)
To: git; +Cc: Philip Oakley, Alain Kalker
In-Reply-To: <20C7ED1EA37C4EECA28070D1483C57B7@PhilipOakley>
"Philip Oakley" <philipoakley@iee.org> writes:
>>> You probably wanted "git bundle create ../repo.bundle --all" which
>>> includes both "master" and "HEAD".
>>
>> That explains it, thanks! Maybe this could be added as an example to
>> the
>> documentation for `git bundle`? People looking at `man git-bundle`
>> hoping
>> to use it as one possible way to make a backup of a Git repository
>> might
>> not realize right away that --all is the way to specify all refs, like
>> with `git log`.
>
> I had posted a documentation patch back in Setemeber last year,
> http://thread.gmane.org/gmane.comp.version-control.git/205887/focus=205897,
> however Junio highlighted some additional concerns that I wasn't able
> to respond to at the time.
>
> It may be worth resurrecting once the concerns have been addressed.
A saner thing to do, instead of explaining away the lack of HEAD as
"the creator of the bundle did not bother to name it", might be to
automatically add an artificial HEAD to the resulting bundle when
the arguments given to specify the "range" do not have any negative
ones (because by definition such a bundle is unsuitable for use with
"git clone" [*1*]), and HEAD is not among the refs.
The heuristics to pick what to record as the artificial HEAD could
vary, though. Without thinking things through...
* When only one positive ref is given, use it (sort of obvious);
* When two or more positive refs are given, and the current branch
is one of them, use that;
* Otherwise, pick the "first" positive ref given from the command
line.
perhaps?
[Footnote]
*1* Strictly speaking, this condition could be loosened, as long as
cloning side uses an appropriate --depth, but I do not know such an
"advanced use case" needs a hand-holding change to add a HEAD that
was not asked by the user.
^ permalink raw reply
* Re: [PATCH] Improve QNX support in GIT
From: Junio C Hamano @ 2013-02-25 7:14 UTC (permalink / raw)
To: Mike Gorchak; +Cc: git
In-Reply-To: <7vvc9h4d7c.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Mike Gorchak <mike.gorchak.qnx@gmail.com> writes:
>
>> CFLAGS="-I/usr/qnxVVV/include" LDFLAGS="-I/usr/qnxVVV/lib" ./configure
>> --prefix=/usr
>
> Oh, I didn't notice that, but the definition of ALL_CFLAGS may be
> what is wrong. It allows CFLAGS to come before BASIC_CFLAGS that
> adds -Icompat/, which goes against the whole point of having
> replacement headers in compat/ directory.
Also, in general, as the end-user input, we would want to make it
take the precedence, so that CFLAGS can be used to override the
default command line; e.g. we may have -DMACRO=value on BASIC_CFLAGS
or others on ALL_CFLAGS, and let the users who know what they are
doing use CFLAGS=-DMACRO=anothervalue to override it.
Swapping the order between CFLAGS and BASIC_CFLAGS in ALL_CFLAGS may
be a good change for that reason as well.
In any case, I won't take a patch to rename source files left and
right only to work around name collisions with random system header
files we do not even use ourselves, unless/until I know we have
tried all the other saner approaches first. That's a workaround,
not a solution.
^ permalink raw reply
* Re: [PATCH 0/5] Fix msvc build
From: Johannes Sixt @ 2013-02-25 8:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: GIT Mailing-list, Ramsay Jones, Erik Faye-Lund, Jonathan Nieder,
Johannes Schindelin
In-Reply-To: <7vehg4288w.fsf@alter.siamese.dyndns.org>
Am 2/25/2013 7:54, schrieb Junio C Hamano:
> Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
>
>> As I mentioned recently, while discussing a cygwin specific patch
>> (see "Version 1.8.1 does not compile on Cygwin 1.7.14" thread), the
>> MSVC build is broken for me.
>>
>> The first 4 patches fix the MSVC build for me. The final patch is
>> not really related to fixing the build, but it removed some make
>> warnings which were quite irritating ...
>>
>> Note that I used the Makefile, with the Visual C++ 2008 command
>> line compiler on Windows XP (SP3), to build a vanilla git on MinGW.
>> I'm not subscribed to the msysgit mailing list, nor do I follow the
>> msysgit fork of git, so these patches may conflict with commits in
>> their repository.
>
> Did anything further happen to this topic in the Windows land?
I successfully built with MSVC with these patches (but I am not using the
result anywhere nor did I attempt to run the test suite).
More importantly, I'm using git on Windows ("MinGW flavor") with these
patches in production, so there are no obvious regressions.
Feel free to add my
Tested-by: Johannes Sixt <j6t@kdbg.org>
but if you don't have the patches around, I can resend them.
-- Hannes
^ 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