Re: [PATCH] Improve QNX support in GIT
Junio C Hamano writes: > Mike Gorchak 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. -- 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: [BUG] Git clone of a bundle fails, but works (somewhat) when run with strace
"Philip Oakley" 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. -- 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: [PATH/RFC] Revert "compat: add strtok_r()"
Care to tie the loose end on this one, with a sign-off? -- 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 0/5] Fix msvc build
Ramsay Jones 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? -- 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 1/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA.
TJ writes: > On 31/01/13 15:51, Junio C Hamano wrote: >> 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? -- 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 0/7] perl/Git.pm: a bunch of fixes for Windows
"Gustavo L. de M. Chaves" 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? -- 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: [RFC] git rm -u
Eric James Michael Ritz 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. -- 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] rebase --preserve-merges keeps empty merge commits
Martin von Zweigbergk 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? -- 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] Support FTP-over-SSL/TLS for regular FTP
Modestas Vainius 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?
--
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/RFC] mingw: rename WIN32 cpp macro to NATIVE_WINDOWS
Ramsay Jones 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 > > 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? -- 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 v2 0/2] improve-wincred-compatibility
Erik Faye-Lund writes: > On Thu, Jan 10, 2013 at 1:10 PM, Karsten Blees > 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 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)? -- 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] Spelling fixes.
René Scharfe writes: > Am 23.02.2013 15:31, schrieb Ville Skyttä: >> >> Signed-off-by: Ville Skyttä >> --- >> 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. -- 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: [RFC/WIP PATCH 1/3] teach config parsing to read from strbuf
Heiko Voigt 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.
--
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 2/2] describe: Exclude --all --match=PATTERN
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
---
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 ::
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
--
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: Certificate validation vulnerability in Git
Jeff King 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. -- 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] Fix ".git/refs" stragglers
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
---
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] *
+ or: git describe [options] --dirty
--containsfind the tag that comes after the commit
--debug debug search strategy on stderr
---all use any ref in .git/refs
---tagsuse any tag in .git/refs/tags
---abbrev []use digits to display SHA-1s
---candidates consider most recent tags (default: 10)
+--all use any ref
+--tagsuse any tag, even unannotated
+--longalways use long format
+--abbrev[=]use 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
--
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] describe: Document --match pattern format
It's not clear in git-describe(1) what kind of "pattern" should be passed to --match. Fix that. Signed-off-by: Greg Price --- 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 :: - 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 -- 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] Small grammar fix
"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 --- 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 -- 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 12/13] Documentation/Makefile: update git guide links
Philip Oakley 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? -- 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 05/13] Help.c: add list_common_guides_help() function
"Philip Oakley" writes: > From: "Junio C Hamano" > Sent: Sunday, February 24, 2013 9:01 AM >> Philip Oakley writes: >> >>> diff --git a/common-guides.h b/common-guides.h >>> new file mode 100644 >>> index 000..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. -- 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: Certificate validation vulnerability in Git
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 -- 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: Certificate validation vulnerability in Git
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
--
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: Certificate validation vulnerability in Git
Hello,
On Mon, Feb 25, 2013 at 12:16 AM, Andreas Ericsson 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.erics...@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.
--
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
[RFC/WIP PATCH 3/3] submodule: simplify decision tree whether to or not to fetch
To make extending this logic later easier.
Signed-off-by: Heiko Voigt
---
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
--
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
[RFC/WIP PATCH 2/3] implement fetching of moved submodules
Change calculation of changed submodule paths to read revisions config.
We now read the submodule name for every changed submodule path in a
commit. We then use the submodules names for fetching instead of the
submodule paths.
We lazily read all configurations of changed submodule path into a cache
which can then be used to lookup the configuration for a certain revision
and path or name.
It is expected that .gitmodules files do not change often between
commits. Thats why we lookup the .gitmodules sha1 and use a submodule
configuration cache to lazily lookup the parsed result for a submodule
stored by its name.
This cache could be reused for other purposes which need knowledge about
submodule configurations. For example automatic clone on fetch of a new
submodule if it is configured to be automatically initialized.
The submodule configuration in the current worktree can be stored using
the null sha1.
Signed-off-by: Heiko Voigt
---
Makefile| 1 +
submodule-config-cache.c| 96 ++
submodule-config-cache.h| 34
submodule.c | 196 ++--
t/t5526-fetch-submodules.sh | 31 +++
5 files changed, 335 insertions(+), 23 deletions(-)
create mode 100644 submodule-config-cache.c
create mode 100644 submodule-config-cache.h
diff --git a/Makefile b/Makefile
index 98da708..2e1d83b 100644
--- a/Makefile
+++ b/Makefile
@@ -858,6 +858,7 @@ LIB_OBJS += strbuf.o
LIB_OBJS += streaming.o
LIB_OBJS += string-list.o
LIB_OBJS += submodule.o
+LIB_OBJS += submodule-config-cache.o
LIB_OBJS += symlinks.o
LIB_OBJS += tag.o
LIB_OBJS += trace.o
diff --git a/submodule-config-cache.c b/submodule-config-cache.c
new file mode 100644
index 000..8ea5ac4
--- /dev/null
+++ b/submodule-config-cache.c
@@ -0,0 +1,96 @@
+#include "cache.h"
+#include "submodule-config-cache.h"
+#include "strbuf.h"
+#include "hash.h"
+
+void submodule_config_cache_init(struct submodule_config_cache *cache)
+{
+ init_hash(&cache->for_name);
+ init_hash(&cache->for_path);
+}
+
+static int free_one_submodule_config(void *ptr, void *data)
+{
+ struct submodule_config *entry = ptr;
+
+ strbuf_release(&entry->path);
+ strbuf_release(&entry->name);
+ free(entry);
+
+ return 0;
+}
+
+void submodule_config_cache_free(struct submodule_config_cache *cache)
+{
+ /* NOTE: its important to iterate over the name hash here
+* since paths might have multiple entries */
+ for_each_hash(&cache->for_name, free_one_submodule_config, NULL);
+ free_hash(&cache->for_path);
+ free_hash(&cache->for_name);
+}
+
+static unsigned int hash_sha1_string(const unsigned char *sha1, const char
*string)
+{
+ int c;
+ unsigned int hash, string_hash = 5381;
+ memcpy(&hash, sha1, sizeof(hash));
+
+ /* djb2 hash */
+ while ((c = *string++))
+ string_hash = ((string_hash << 5) + hash) + c; /* hash * 33 + c
*/
+
+ return hash + string_hash;
+}
+
+void submodule_config_cache_update_path(struct submodule_config_cache *cache,
+ struct submodule_config *config)
+{
+ void **pos;
+ int hash = hash_sha1_string(config->gitmodule_sha1, config->path.buf);
+ pos = insert_hash(hash, config, &cache->for_path);
+ if (pos) {
+ config->next = *pos;
+ *pos = config;
+ }
+}
+
+void submodule_config_cache_insert(struct submodule_config_cache *cache,
struct submodule_config *config)
+{
+ unsigned int hash;
+ void **pos;
+
+ hash = hash_sha1_string(config->gitmodule_sha1, config->name.buf);
+ pos = insert_hash(hash, config, &cache->for_name);
+ if (pos) {
+ config->next = *pos;
+ *pos = config;
+ }
+}
+
+struct submodule_config *submodule_config_cache_lookup_path(struct
submodule_config_cache *cache,
+ const unsigned char *gitmodule_sha1, const char *path)
+{
+ unsigned int hash = hash_sha1_string(gitmodule_sha1, path);
+ struct submodule_config *config = lookup_hash(hash, &cache->for_path);
+
+ while (config &&
+ hashcmp(config->gitmodule_sha1, gitmodule_sha1) &&
+ strcmp(path, config->path.buf))
+ config = config->next;
+
+ return config;
+}
+
+struct submodule_config *submodule_config_cache_lookup_name(struct
submodule_config_cache *cache,
+ const unsigned char *gitmodule_sha1, const char *name)
+{
+ unsigned int hash = hash_sha1_string(gitmodule_sha1, name);
+ struct submodule_config *config = lookup_hash(hash, &cache->for_name);
+
+ while (config &&
+ hashcmp(config->gitmodule_sha1, gitmodule_sha1) &&
+ strcmp(name, config->name.buf))
+ config = config->next;
+
+ return config;
+}
diff --git a/submodule-config-cache.h b/submodule-config-cache.h
new file mode 100644
index 000..2b48c27
--
[RFC/WIP PATCH 1/3] teach config parsing to read from strbuf
This can be used to read configuration values directly from gits
database.
Signed-off-by: Heiko Voigt
---
.gitignore | 1 +
Makefile | 1 +
cache.h| 1 +
config.c | 119 ++---
t/t1300-repo-config.sh | 4 ++
test-config.c | 41 +
6 files changed, 142 insertions(+), 25 deletions(-)
create mode 100644 test-config.c
diff --git a/.gitignore b/.gitignore
index 6669bf0..386b7f2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -178,6 +178,7 @@
/gitweb/static/gitweb.min.*
/test-chmtime
/test-ctype
+/test-config
/test-date
/test-delta
/test-dump-cache-tree
diff --git a/Makefile b/Makefile
index ba8e243..98da708 100644
--- a/Makefile
+++ b/Makefile
@@ -543,6 +543,7 @@ PROGRAMS += $(patsubst %.o,git-%$X,$(PROGRAM_OBJS))
TEST_PROGRAMS_NEED_X += test-chmtime
TEST_PROGRAMS_NEED_X += test-ctype
+TEST_PROGRAMS_NEED_X += test-config
TEST_PROGRAMS_NEED_X += test-date
TEST_PROGRAMS_NEED_X += test-delta
TEST_PROGRAMS_NEED_X += test-dump-cache-tree
diff --git a/cache.h b/cache.h
index e493563..ada2362 100644
--- a/cache.h
+++ b/cache.h
@@ -1128,6 +1128,7 @@ extern int update_server_info(int);
typedef int (*config_fn_t)(const char *, const char *, void *);
extern int git_default_config(const char *, const char *, void *);
extern int git_config_from_file(config_fn_t fn, const char *, void *);
+extern int git_config_from_strbuf(config_fn_t fn, struct strbuf *strbuf, void
*data);
extern void git_config_push_parameter(const char *text);
extern int git_config_from_parameters(config_fn_t fn, void *data);
extern int git_config(config_fn_t fn, void *);
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;
@@ -24,6 +27,46 @@ static config_file *cf;
static int zlib_compression_seen;
+static int config_file_valid(struct config_file *file)
+{
+ if (file->f)
+ return 1;
+ if (file->is_strbuf)
+ return 1;
+
+ return 0;
+}
+
+static int config_fgetc(struct config_file *file)
+{
+ if (!file->is_strbuf)
+ return fgetc(file->f);
+
+ if (file->strbuf_pos < file->strbuf_contents->len)
+ return file->strbuf_contents->buf[file->strbuf_pos++];
+
+ return EOF;
+}
+
+static int config_ungetc(int c, struct config_file *file)
+{
+ if (!file->is_strbuf)
+ return ungetc(c, file->f);
+
+ if (file->strbuf_pos > 0)
+ return file->strbuf_contents->buf[--file->strbuf_pos];
+
+ return EOF;
+}
+
+static long config_ftell(struct config_file *file)
+{
+ if (!file->is_strbuf)
+ return ftell(file->f);
+
+ return file->strbuf_pos;
+}
+
#define MAX_INCLUDE_DEPTH 10
static const char include_depth_advice[] =
"exceeded maximum include depth (%d) while including\n"
@@ -169,16 +212,15 @@ int git_config_from_parameters(config_fn_t fn, void *data)
static int get_next_char(void)
{
int c;
- FILE *f;
c = '\n';
- if (cf && ((f = cf->f) != NULL)) {
- c = fgetc(f);
+ if (cf && config_file_valid(cf)) {
+ c = config_fgetc(cf);
if (c == '\r') {
/* DOS like systems */
- c = fgetc(f);
+ c = config_fgetc(cf);
if (c != '\n') {
- ungetc(c, f);
+ config_ungetc(c, cf);
c = '\r';
}
}
@@ -896,6 +938,38 @@ int git_default_config(const char *var, const char *value,
void *dummy)
return 0;
}
+static int do_config_from(struct config_file *top, config_fn_t fn, void *data)
+{
+ int ret;
+
+ /* push config-file parsing state stack */
+ top->prev = cf;
+ top->linenr = 1;
+ top->eof = 0;
+ strbuf_init(&top->value, 1024);
+ strbuf_init(&top->var, 1024);
+ cf = top;
+
+ ret = git_parse_file(fn, data);
+
+ /* pop config-file parsing state stack */
+ strbuf_release(&top->value);
+ strbuf_release(&top->var);
+ cf = top->prev;
+
+ return ret;
+}
+
+static void config_file_init(struct config_file *top, const char *filename,
+FILE *f, struct strbuf *string)
+{
+ top->f = f;
+ top->name = filename;
+ top->is_strbuf = f ? 0 : 1;
+ top->strbuf_contents = string;
+ top->strbuf_pos = 0;
+}
+
int git_config_from_file(config_fn_t fn, const char *filename, void *data)
{
int ret;
@@ -905,28 +979,24 @@ int git_config_from_file(config_fn_t fn, const char
*fi
[RFC/WIP PATCH 0/3] fetch moved submodules on-demand
Hi, this is a series I have been working on and off. My plan is that it might be part of a slightly bigger series also implementing on-demand clone of submodules into the .git/modules folder if a submodule is configured like that. This is needed as preparation for the final goal of automatic checkout/deletion of submodules when they appear/disappear. My plan is to introduce a new .gitmodules variable submodule..init to specify whether a submodule should be initialized (and thus cloned) by default or not. If not configured it will default to off to stay closed to the current behavior. If it proves useful we can maybe change that default later to on. That way we would get much closer to "clone/fetch and get everything you need to work on a project". I send this series mainly to inform people what I have been working and to maybe get some early feedback about the approach. Let me know what you think. Cheers Heiko Heiko Voigt (3): teach config parsing to read from strbuf implement fetching of moved submodules submodule: simplify decision tree whether to or not to fetch .gitignore | 1 + Makefile| 2 + cache.h | 1 + config.c| 119 +- submodule-config-cache.c| 96 ++ submodule-config-cache.h| 34 +++ submodule.c | 242 t/t1300-repo-config.sh | 4 + t/t5526-fetch-submodules.sh | 31 ++ test-config.c | 41 10 files changed, 502 insertions(+), 69 deletions(-) create mode 100644 submodule-config-cache.c create mode 100644 submodule-config-cache.h create mode 100644 test-config.c -- 1.8.2.rc0.25.g5062c01 -- 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 4/4] contrib/mw-to-git/t/install-wiki.sh: use a lowercase "usage:" string
Make the usage string consistent with Git.
Signed-off-by: David Aguilar
---
contrib/mw-to-git/t/install-wiki.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/mw-to-git/t/install-wiki.sh
b/contrib/mw-to-git/t/install-wiki.sh
index c6d6fa3..70a53f6 100755
--- a/contrib/mw-to-git/t/install-wiki.sh
+++ b/contrib/mw-to-git/t/install-wiki.sh
@@ -15,7 +15,7 @@ fi
. "$WIKI_TEST_DIR"/test-gitmw-lib.sh
usage () {
- echo "Usage: "
+ echo "usage: "
echo " ./install-wiki.sh "
echo " install | -i : Install a wiki on your computer."
echo " delete | -d : Delete the wiki and all its pages and "
--
1.7.12.4 (Apple Git-37)
--
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 3/4] contrib/examples/git-remote.perl: use a lowercase "usage:" string
Make the usage string consistent with Git.
Signed-off-by: David Aguilar
---
contrib/examples/git-remote.perl | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/examples/git-remote.perl b/contrib/examples/git-remote.perl
index b549a3c..d42df7b 100755
--- a/contrib/examples/git-remote.perl
+++ b/contrib/examples/git-remote.perl
@@ -380,7 +380,7 @@ elsif ($ARGV[0] eq 'show') {
}
}
if ($i >= @ARGV) {
- print STDERR "Usage: git remote show \n";
+ print STDERR "usage: git remote show \n";
exit(1);
}
my $status = 0;
@@ -410,7 +410,7 @@ elsif ($ARGV[0] eq 'prune') {
}
}
if ($i >= @ARGV) {
- print STDERR "Usage: git remote prune \n";
+ print STDERR "usage: git remote prune \n";
exit(1);
}
my $status = 0;
@@ -458,13 +458,13 @@ elsif ($ARGV[0] eq 'add') {
}
elsif ($ARGV[0] eq 'rm') {
if (@ARGV <= 1) {
- print STDERR "Usage: git remote rm \n";
+ print STDERR "usage: git remote rm \n";
exit(1);
}
exit(rm_remote($ARGV[1]));
}
else {
- print STDERR "Usage: git remote\n";
+ print STDERR "usage: git remote\n";
print STDERR " git remote add \n";
print STDERR " git remote rm \n";
print STDERR " git remote show \n";
--
1.7.12.4 (Apple Git-37)
--
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 1/4] git-svn: use a lowercase "usage:" string
Make the usage string consistent with Git.
Signed-off-by: David Aguilar
---
I'm not sure why this wasn't caught in my first round.
It should probably be squashed into the 02/16 from v2.
git-svn.perl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index a93166f..6c7bd95 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -534,7 +534,7 @@ sub cmd_fetch {
}
my ($remote) = @_;
if (@_ > 1) {
- die "Usage: $0 fetch [--all] [--parent] [svn-remote]\n";
+ die "usage: $0 fetch [--all] [--parent] [svn-remote]\n";
}
$Git::SVN::no_reuse_existing = undef;
if ($_fetch_parent) {
@@ -1404,7 +1404,7 @@ sub cmd_multi_fetch {
# this command is special because it requires no metadata
sub cmd_commit_diff {
my ($ta, $tb, $url) = @_;
- my $usage = "Usage: $0 commit-diff -r ".
+ my $usage = "usage: $0 commit-diff -r ".
" []";
fatal($usage) if (!defined $ta || !defined $tb);
my $svn_path = '';
--
1.7.12.4 (Apple Git-37)
--
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 2/4] tests: use a lowercase "usage:" string
Adjust test commands and test suites so that their
usage strings are consistent with Git.
Signed-off-by: David Aguilar
---
t/lib-git-svn.sh | 2 +-
t/t1509/prepare-chroot.sh | 2 +-
test-chmtime.c| 2 +-
test-delta.c | 2 +-
test-genrandom.c | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/t/lib-git-svn.sh b/t/lib-git-svn.sh
index 199f22c..c5e55b1 100644
--- a/t/lib-git-svn.sh
+++ b/t/lib-git-svn.sh
@@ -148,7 +148,7 @@ stop_httpd () {
convert_to_rev_db () {
"$PERL_PATH" -w -- - "$@" <<\EOF
use strict;
-@ARGV == 2 or die "Usage: convert_to_rev_db ";
+@ARGV == 2 or die "usage: convert_to_rev_db ";
open my $wr, '+>', $ARGV[1] or die "$!: couldn't open: $ARGV[1]";
open my $rd, '<', $ARGV[0] or die "$!: couldn't open: $ARGV[0]";
my $size = (stat($rd))[7];
diff --git a/t/t1509/prepare-chroot.sh b/t/t1509/prepare-chroot.sh
index c5334a8..6269117 100755
--- a/t/t1509/prepare-chroot.sh
+++ b/t/t1509/prepare-chroot.sh
@@ -14,7 +14,7 @@ xmkdir() {
R="$1"
-[ -n "$R" ] || die "Usage: prepare-chroot.sh "
+[ -n "$R" ] || die "usage: prepare-chroot.sh "
[ -x git ] || die "This script needs to be executed at git source code's top
directory"
[ -x /bin/busybox ] || die "You need busybox"
diff --git a/test-chmtime.c b/test-chmtime.c
index 92713d1..02b42ba 100644
--- a/test-chmtime.c
+++ b/test-chmtime.c
@@ -114,6 +114,6 @@ int main(int argc, const char *argv[])
return 0;
usage:
- fprintf(stderr, "Usage: %s %s\n", argv[0], usage_str);
+ fprintf(stderr, "usage: %s %s\n", argv[0], usage_str);
return -1;
}
diff --git a/test-delta.c b/test-delta.c
index af40a3c..4595cd6 100644
--- a/test-delta.c
+++ b/test-delta.c
@@ -23,7 +23,7 @@ int main(int argc, char *argv[])
unsigned long from_size, data_size, out_size;
if (argc != 5 || (strcmp(argv[1], "-d") && strcmp(argv[1], "-p"))) {
- fprintf(stderr, "Usage: %s\n", usage_str);
+ fprintf(stderr, "usage: %s\n", usage_str);
return 1;
}
diff --git a/test-genrandom.c b/test-genrandom.c
index b3c28d9..54824d0 100644
--- a/test-genrandom.c
+++ b/test-genrandom.c
@@ -12,7 +12,7 @@ int main(int argc, char *argv[])
unsigned char *c;
if (argc < 2 || argc > 3) {
- fprintf(stderr, "Usage: %s []\n", argv[0]);
+ fprintf(stderr, "usage: %s []\n", argv[0]);
return 1;
}
--
1.7.12.4 (Apple Git-37)
--
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 v2 00/16] use a lowercase "usage:" string
On Sun, Feb 24, 2013 at 1:45 PM, Junio C Hamano wrote: > Thanks. > > After applying these patches, "git grep '^[^#]*Usage:'" still shows > a handful more hits, such as contrib/examples/git-remote.perl that > are touched by this series. Thanks, I'll take a look at these. I stayed away from tests and comments in the first round so that we could catch the user-facing strings. That seems to have settled in well so I can make another pass and catch these last remaining stragglers. -- David -- 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: [git] [PATCH 13/13] Fixup! doc: giteveryday and user-manual man format
On 24/02/13 15:01, W. Trevor King wrote: On Sat, Feb 23, 2013 at 11:06:01PM +, Philip Oakley wrote: diff --git a/Documentation/gituser-manual.txt b/Documentation/gituser-manual.txt index a4778d7..e991b11 100644 --- a/Documentation/gituser-manual.txt +++ b/Documentation/gituser-manual.txt @@ -1,7 +1,12 @@ Git User's Manual (for version 1.5.3 or newer) -__ +== I'd be happy dropping the parenthetical bit here. It's hard to imagine someone still running something earlier than 1.5.3. It's even harder to imagine them installing a modern user manual man page for their old Git version ;). Sensible. Will do. Philip -- 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: [git] [PATCH 12/13] Documentation/Makefile: update git guide links
On 24/02/13 14:58, W. Trevor King wrote: On Sat, Feb 23, 2013 at 11:06:00PM +, Philip Oakley wrote: OBSOLETE_HTML = git-remote-helpers.html +OBSOLETE_HTML = everyday.html +OBSOLETE_HTML = user-manual.html DOC_HTML=$(MAN_HTML) $(OBSOLETE_HTML) Should be '+=' instead of '='. Well spotted. That maybe part of why my make of the documentation failed. Though the 'new' giteveryday gituser-manual don't build as man pages, so I may simply leave them with their old make process - If I understand correctly they are in the right place and just need the 'git' prefix. However I'm biased by my Msysgit/G4W experience which always assumes --web and fires up the HTML version so there may be issues with the plain .txt version attempting to be displayed as a man page if it doesn't follow the format. (my linux laptop was a repair of a 'scrapper') Philip -- 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: [git] [PATCH 09/13] Rename everyday to giteveryday
On 24/02/13 14:55, W. Trevor King wrote: On Sat, Feb 23, 2013 at 11:05:57PM +, Philip Oakley wrote: diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt index e1fba85..3fc69f6 100644 --- a/Documentation/everyday.txt +++ b/Documentation/everyday.txt @@ -1,413 +1,25 @@ -Everyday Git With 20 Commands Or So +Everyday GIT With 20 Commands Or So === This looks like it's opposing 48a8c26 (Documentation: avoid poor-man's small caps GIT, 2013-01-21). Another reason to use 'Git' over 'GIT' is to match the page we're redirecting to: My mistake. When I was separating out the changes into separate patches I incorrectly restored/copied an old version of the title. Will correct. new file mode 100644 index 000..e1fba85 --- /dev/null +++ b/Documentation/giteveryday.txt @@ -0,0 +1,413 @@ +Everyday Git With 20 Commands Or So +=== Trevor Philip -- 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: [git] [PATCH 06/13] Add guide-list.txt and extraction shell
On 24/02/13 14:51, W. Trevor King wrote:
On Sat, Feb 23, 2013 at 11:05:54PM +, Philip Oakley wrote:
+# Usage: ./generate-guidelist.sh >>common-guides.h
Following David's recent series, it's probably better to use a
lowercase 'usage' [1].
I prefer the Initial capital version to suggest the start of a sentence,
but I can go with either way.
Also, I'd expect '>common-guides.h' would make
more sense than appending with '>>'.
My mistake. Will correct.
+/* re-use struct cmdname_help in common-commands.h */
+
+static struct cmdname_help common_guides[] = {"
This is probably just copied from generate-cmdlist.sh, but maybe it
would be a good idea to #include "common-commands.h" here?
I was trying to avoid nested includes. Eventually, if the series is
accepted, I'd want to refactor the guide generation into the existing
command generation so that .h file would then disappear.
Trevor
[1]: http://article.gmane.org/gmane.comp.version-control.git/216961
Philip
--
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
Building git with NO_PERL=1 will install git-submodule, which depends on perl
Compare with git-instaweb which is replaced by as a small shell script which informs the user that the functionality is not implemented. I've only checked git-submodule, other commands may also have an undocumented dependency on perl. -- 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 01/13] Use 'Git' in help messages
On Sun, Feb 24, 2013 at 12:59 AM, Junio C Hamano wrote:
> David Aguilar writes:
>
>> This is referring to "git the command", not "git the system",
>> so it should not be changed according to the rule that was
>> applied when many "git" strings were changed to "Git".
>
> That sounds like a sensible objection.
>
>> There are scripts, etc. in the wild that parse this output.
>> which is another reason we would not want to change this.
>
> Are there? For what purpose?
>
> Especially when these are all _("l10n ready"), I find that somewhat
> unlikely.
A script might conditionally use new git behavior and parse the
output of "git version" to determine whether or not it can use it.
oh-my-zsh does this, for example [*].
Changing the git to Git is probably fine for some scripts that
do something interesting based on the git version since they
might be doing something simple like splitting the string on
whitespace and taking the last element as the version number.
These won't be broken by this change, but this approach is
already broken for a different reason. Apple's build of git
prints "git version 1.7.12.4 (Apple Git-37)" so they would
need to account for the last parens section optionally
being there. Changing "git" to "Git" only breaks anyone that
has assumed that they could get the version by doing
s/git version// on the string.
I think being able to find the version at runtime is something
that is typically used by packagers and folks that want to be
portable across git versions. For these, it would be helpful
to have a consistent and stable output that can be easily parsed.
By deciding to not mark these l10n ready and keeping the output
consistent we could help that use case.
[*] I'm not saying this is a good idea or something that scripts
should do, I'm just pointing out that it is done in practice,
so it is worth considering their use cases.
--
David
--
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: [git] [PATCH 02/13] Show 'git help ' usage, with examples
On 24/02/13 14:39, W. Trevor King wrote: On Sat, Feb 23, 2013 at 11:05:50PM +, Philip Oakley wrote: + "Examples: 'git help git', 'git help branch', 'git help tutorial'.."); This sentence should end in '.', not '..'. Cheers, Trevor I should have used three as ellipsis ... to suggest 'more', which was my intent, but ended up neither here, nor there. Philip -- 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 05/13] Help.c: add list_common_guides_help() function
From: "Junio C Hamano" Sent: Sunday, February 24, 2013 9:01 AM Philip Oakley writes: diff --git a/common-guides.h b/common-guides.h new file mode 100644 index 000..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 second comment line notes that I re-use cmdname_help, rather than creating another struct with a similar name. I should probably have noted these points in the commit message. (or waited until patch 6 to add the comment). Philip -- 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 01/13] Use 'Git' in help messages
From: "Junio C Hamano"
Sent: Sunday, February 24, 2013 8:59 AM
David Aguilar writes:
This is referring to "git the command", not "git the system",
so it should not be changed according to the rule that was
applied when many "git" strings were changed to "Git".
That sounds like a sensible objection.
I'd read the messages in the tone 'commands of the Git system', but I
can see that both views are equally plausible. Though the final _("git:
'%s' is not a Git command. See 'git --help'.") can't be referring to a
'git-', obviously ;-)
There are scripts, etc. in the wild that parse this output.
which is another reason we would not want to change this.
Are there? For what purpose?
Especially when these are all _("l10n ready"), I find that somewhat
unlikely.
The bash completion (in contrib/) does read from the command list
IIRC. I do not think it relies on the messages, though.
I was aware of that bash completion used 'git help -a' so I avoided
changing the response to that option. Initially I'd thought of making
'-a' provide both commands and guides but knew I'd need to ensure the
completion would still be sensible. I'd taken Juio's earlier advice to
keep '-a' unchanged and simply add the -g|--guides option as a
supplemental 'git help' response..
Philip
--
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 v2 00/16] use a lowercase "usage:" string
Thanks. After applying these patches, "git grep '^[^#]*Usage:'" still shows a handful more hits, such as contrib/examples/git-remote.perl that are touched by this series. -- 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] Improve QNX support in GIT
Mike Gorchak 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. -- 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: Load testing of git
On Sun, Feb 24, 2013 at 8:58 AM, Thomas Koch wrote: > Yuri Mikhailov: >> Dear Git community, >> >> I am a Software Developer and I have been using git for a while. >> Currently my company is looking for a version control system to use >> and we find Git a good candidate for us. But what is important for us >> to know is scalability of this VCS. Does anyone performed load testing >> of Git? What is the practical maximum number of files and revisions >> this system can handle? >> >> Best regards, >> Iurii Mykhailov > > Have a look at the projects using Git[1]. There are for sure projects that > exceeds the scalability you're thinking about. The linux Kernel might be the > biggest project. I highly doubt the Linux kernel is the biggest project. IIRC WebKit has more objects, more files, etc. Its repository's compressed form is >4G. I know of at least some proprietary repositories with 96G in them. Not much history, but a lot of binary blobs around 128M each doesn't compress well. And bup wasn't used so we didn't get very good compression over the files. -- 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] Makefile: make mandir, htmldir and infodir absolute
This matches the use of the variables with the same names in autotools,
reducing the potential for user surprise.
Using relative paths in these variables also causes issues if they are
exported from the Makefile, as discussed in commit c09d62f (Makefile: do
not export mandir/htmldir/infodir, 2013-02-12).
Suggested-by: Junio C Hamano
Signed-off-by: John Keeping
---
On Tue, Feb 12, 2013 at 03:09:53PM -0800, Junio C Hamano wrote:
> A longer term fix is to introduce runtime_{man,html,info}dir variables
> to hold these funny values, and make {man,html,info}dir variables
> to have real paths whose default values begin with $(prefix), but
> as a first step, stop exporting them from the top-level Makefile.
Here's an attempt at doing that.
If this is sensible, should bindir_relative be calculated in the same
way?
Makefile | 36 +---
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/Makefile b/Makefile
index 7c75e3b..087eec4 100644
--- a/Makefile
+++ b/Makefile
@@ -360,33 +360,39 @@ STRIP ?= strip
# Among the variables below, these:
# gitexecdir
# template_dir
-# mandir
-# infodir
-# htmldir
# sysconfdir
# can be specified as a relative path some/where/else;
# this is interpreted as relative to $(prefix) and "git" at
# runtime figures out where they are based on the path to the executable.
+# Additionally, the following will be treated as relative by "git" if they
+# begin with "$(prefix)/":
+# mandir
+# infodir
+# htmldir
# This can help installing the suite in a relocatable way.
prefix = $(HOME)
bindir_relative = bin
bindir = $(prefix)/$(bindir_relative)
-mandir = share/man
-infodir = share/info
+mandir = $(prefix)/share/man
+infodir = $(prefix)/share/info
gitexecdir = libexec/git-core
mergetoolsdir = $(gitexecdir)/mergetools
sharedir = $(prefix)/share
gitwebdir = $(sharedir)/gitweb
localedir = $(sharedir)/locale
template_dir = share/git-core/templates
-htmldir = share/doc/git-doc
+htmldir = $(prefix)/share/doc/git-doc
ETC_GITCONFIG = $(sysconfdir)/gitconfig
ETC_GITATTRIBUTES = $(sysconfdir)/gitattributes
lib = lib
# DESTDIR =
pathsep = :
+mandir_relative = $(patsubst $(prefix)/%,%,$(mandir))
+infodir_relative = $(patsubst $(prefix)/%,%,$(infodir))
+htmldir_relative = $(patsubst $(prefix)/%,%,$(htmldir))
+
export prefix bindir sharedir sysconfdir gitwebdir localedir
CC = cc
@@ -1548,12 +1554,12 @@ ETC_GITATTRIBUTES_SQ = $(subst
','\'',$(ETC_GITATTRIBUTES))
DESTDIR_SQ = $(subst ','\'',$(DESTDIR))
bindir_SQ = $(subst ','\'',$(bindir))
bindir_relative_SQ = $(subst ','\'',$(bindir_relative))
-mandir_SQ = $(subst ','\'',$(mandir))
-infodir_SQ = $(subst ','\'',$(infodir))
+mandir_relative_SQ = $(subst ','\'',$(mandir_relative))
+infodir_relative_SQ = $(subst ','\'',$(infodir_relative))
localedir_SQ = $(subst ','\'',$(localedir))
gitexecdir_SQ = $(subst ','\'',$(gitexecdir))
template_dir_SQ = $(subst ','\'',$(template_dir))
-htmldir_SQ = $(subst ','\'',$(htmldir))
+htmldir_relative_SQ = $(subst ','\'',$(htmldir_relative))
prefix_SQ = $(subst ','\'',$(prefix))
gitwebdir_SQ = $(subst ','\'',$(gitwebdir))
@@ -1685,9 +1691,9 @@ strip: $(PROGRAMS) git$X
git.sp git.s git.o: GIT-PREFIX
git.sp git.s git.o: EXTRA_CPPFLAGS = \
- '-DGIT_HTML_PATH="$(htmldir_SQ)"' \
- '-DGIT_MAN_PATH="$(mandir_SQ)"' \
- '-DGIT_INFO_PATH="$(infodir_SQ)"'
+ '-DGIT_HTML_PATH="$(htmldir_relative_SQ)"' \
+ '-DGIT_MAN_PATH="$(mandir_relative_SQ)"' \
+ '-DGIT_INFO_PATH="$(infodir_relative_SQ)"'
git$X: git.o GIT-LDFLAGS $(BUILTIN_OBJS) $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \
@@ -1697,9 +1703,9 @@ help.sp help.s help.o: common-cmds.h
builtin/help.sp builtin/help.s builtin/help.o: common-cmds.h GIT-PREFIX
builtin/help.sp builtin/help.s builtin/help.o: EXTRA_CPPFLAGS = \
- '-DGIT_HTML_PATH="$(htmldir_SQ)"' \
- '-DGIT_MAN_PATH="$(mandir_SQ)"' \
- '-DGIT_INFO_PATH="$(infodir_SQ)"'
+ '-DGIT_HTML_PATH="$(htmldir_relative_SQ)"' \
+ '-DGIT_MAN_PATH="$(mandir_relative_SQ)"' \
+ '-DGIT_INFO_PATH="$(infodir_relative_SQ)"'
version.sp version.s version.o: GIT-VERSION-FILE GIT-USER-AGENT
version.sp version.s version.o: EXTRA_CPPFLAGS = \
--
1.8.2.rc0.248.g2dab8ff
--
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: Certificate validation vulnerability in Git
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.
> 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.erics...@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.
--
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 1/1] Fix git compilation without libiconv
Fix git compilation without available libiconv library. From: Mike Gorchak Signed-off-by: Mike Gorchak --- configure.ac | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 1991258..d0e82c1 100644 --- a/configure.ac +++ b/configure.ac @@ -566,7 +566,9 @@ for l in $lib_order; do [AC_MSG_RESULT([yes]) NO_ICONV= break], - [AC_MSG_RESULT([no])]) + [AC_MSG_RESULT([no]) + NEEDS_LIBICONV= + ]) LIBS="$old_LIBS" done -- 1.8.2-rc0 -- 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: Load testing of git
In 2012 there was a thread about git's performance on large repositories. One archive of the discussion begins here: http://mid.gmane.org/CB5074CF.3AD7A%25joshua.redstone%40fb.com > The test repo has 4 million commits, linear history and about 1.3 > million files. I'm not sure to what extent git performance may have changed since then, e.g., by improving the index format. Jeff -- 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
Certificate validation vulnerability in Git
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.
We are not subscribed to this list, so we'd appreciate it if you could
CC us in the replies.
Hope this helps.
Thanks!
Zubin
[1] http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf
--
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: Load testing of git
Yuri Mikhailov: > Dear Git community, > > I am a Software Developer and I have been using git for a while. > Currently my company is looking for a version control system to use > and we find Git a good candidate for us. But what is important for us > to know is scalability of this VCS. Does anyone performed load testing > of Git? What is the practical maximum number of files and revisions > this system can handle? > > Best regards, > Iurii Mykhailov Have a look at the projects using Git[1]. There are for sure projects that exceeds the scalability you're thinking about. The linux Kernel might be the biggest project. [1] https://git.wiki.kernel.org/index.php/GitProjects Thomas Koch, http://www.koch.ro -- 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: [git] [PATCH 13/13] Fixup! doc: giteveryday and user-manual man format
On Sat, Feb 23, 2013 at 11:06:01PM +, Philip Oakley wrote: > diff --git a/Documentation/gituser-manual.txt > b/Documentation/gituser-manual.txt > index a4778d7..e991b11 100644 > --- a/Documentation/gituser-manual.txt > +++ b/Documentation/gituser-manual.txt > @@ -1,7 +1,12 @@ > Git User's Manual (for version 1.5.3 or newer) > -__ > +== I'd be happy dropping the parenthetical bit here. It's hard to imagine someone still running something earlier than 1.5.3. It's even harder to imagine them installing a modern user manual man page for their old Git version ;). -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [git] [PATCH 12/13] Documentation/Makefile: update git guide links
On Sat, Feb 23, 2013 at 11:06:00PM +, Philip Oakley wrote: > OBSOLETE_HTML = git-remote-helpers.html > +OBSOLETE_HTML = everyday.html > +OBSOLETE_HTML = user-manual.html > DOC_HTML=$(MAN_HTML) $(OBSOLETE_HTML) Should be '+=' instead of '='. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [git] [PATCH 09/13] Rename everyday to giteveryday
On Sat, Feb 23, 2013 at 11:05:57PM +, Philip Oakley wrote: > diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt > index e1fba85..3fc69f6 100644 > --- a/Documentation/everyday.txt > +++ b/Documentation/everyday.txt > @@ -1,413 +1,25 @@ > -Everyday Git With 20 Commands Or So > +Everyday GIT With 20 Commands Or So > === This looks like it's opposing 48a8c26 (Documentation: avoid poor-man's small caps GIT, 2013-01-21). Another reason to use 'Git' over 'GIT' is to match the page we're redirecting to: > new file mode 100644 > index 000..e1fba85 > --- /dev/null > +++ b/Documentation/giteveryday.txt > @@ -0,0 +1,413 @@ > +Everyday Git With 20 Commands Or So > +=== Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [git] [PATCH 06/13] Add guide-list.txt and extraction shell
On Sat, Feb 23, 2013 at 11:05:54PM +, Philip Oakley wrote:
> +# Usage: ./generate-guidelist.sh >>common-guides.h
Following David's recent series, it's probably better to use a
lowercase 'usage' [1]. Also, I'd expect '>common-guides.h' would make
more sense than appending with '>>'.
> +/* re-use struct cmdname_help in common-commands.h */
> +
> +static struct cmdname_help common_guides[] = {"
This is probably just copied from generate-cmdlist.sh, but maybe it
would be a good idea to #include "common-commands.h" here?
Trevor
[1]: http://article.gmane.org/gmane.comp.version-control.git/216961
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
Re: [git] [PATCH 02/13] Show 'git help ' usage, with examples
On Sat, Feb 23, 2013 at 11:05:50PM +, Philip Oakley wrote: > +"Examples: 'git help git', 'git help branch', 'git help > tutorial'.."); This sentence should end in '.', not '..'. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [PATCH] Improve QNX support in GIT
>>> 2) Rename fnmatch.h to fnmatch_gnu.h and fnmatch.c to fnmatch_gnu.c to >>> avoid inclusion of system fnmatch.h header in case if -I/usr/include >>> path is specified before -Icompat/fnmatch. Which is common situation. > As to the substance, I am fairly negative about the approach this > patch takes, especially the rationale it uses for #2 above. It goes > directly against the spirit of having compat/ directory in the first > place to have -I/usr/include _before_ -Icompat/anything and that, > not the names of header files in compat/ directory, is the root > cause of the problem you are seeing, I think. It is quite common to pass CPPFLAGS/CFLAGS/CXXFLAGS before configure script to make a custom build. For example, I have specific set of headers which belong to another version of libc, so I pass directory where these headers are located right before configure script: CFLAGS="-I/usr/qnxVVV/include" LDFLAGS="-I/usr/qnxVVV/lib" ./configure --prefix=/usr About this you can read by typing ./configure --help. This approach works for every autoconf-based project, except for GIT due to headers collision. I do not know anything about "spirit of compat/ directory", but if it interferes with the normal build process, it means something is wrong. But it is up to you. Thanks. -- 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 for fix build git on Haiku
Hi, Am 23.02.2013 21:42, schrieb Jonathan Nieder: > diger wrote: > >> This patch fixes build git on Haiku > > Lovely. May we have your sign-off? (See > Documentation/SubmittingPatches for what this means.) Does "make > test" pass? (Just curious --- it's fine if it doesn't, though in that > case a list of test failures would be helpful.) > > Thanks, > Jonathan > > (patch left unsnipped for reference) > >> --- Makefile.orig2012-10-21 21:32:15.0 + >> +++ Makefile >> @@ -1211,6 +1204,16 @@ ifeq ($(uname_S),HP-UX) >> endif >> GIT_TEST_CMP = cmp >> endif >> +ifeq ($(uname_S),Haiku) >> +NO_R_TO_GCC_LINKER = YesPlease >> +NO_LIBGEN_H = YesPlease >> +NO_MEMMEM = YesPlease >> +NO_MKSTEMPS = YesPlease >> +NEEDS_LIBICONV = YesPlease >> +DEFAULT_EDITOR = nano Patch looks okay from what I have from my earlier ones in mind, but I believe nano is an Optional Package on Haiku and thus not guaranteed to be installed. CC'ing HaikuPorts. Regards, Andreas >> +PTHREAD_LIBS =-lroot >> +NO_CROSS_DIRECTORY_HARDLINKS = YesPlease >> +endif >> ifeq ($(uname_S),Windows) >> GIT_VERSION := $(GIT_VERSION).MSVC >> pathsep = ; -- 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] diff: Fix rename pretty-print when suffix and prefix overlap
Antoine Pelisse writes:
> When considering a rename for two files that have a suffix and a prefix
> that can overlap, a confusing line is shown. As an example, renaming
> "a/b/b/c" to "a/b/c" shows "a/b/{ => }/b/c".
This would be vastly more readable if it had "It should show XXX
instead" somewhere in the description, perhaps at the end of this
sentence. It can also be after "thus the { => }" below, but I think
giving the expected output earlier would be more appropriate.
> Currently, what we do is calculate the common prefix ("a/b/"), and the
> common suffix ("/b/c"), but the same "/b/" is actually counted both in
> prefix and suffix. Then when calculating the size of the non-common part,
> we end-up with a negative value which is reset to 0, thus the "{ => }".
In this example, the common prefix would be "a/b/" and the common
suffix that does not overlap with the prefix part would be "/c", so
I am imagining that "a/b/{ => b}/c" would be the desired output?
This is a really old thinko (dating back to June 2005). I'll queue
the patch on maint-1.7.6 (because 1.7.6.6 is slightly more than one
year old while 1.7.5.4 is a lot older) to allow distros that issue
incremental fixes on top of ancient versions of Git to pick up the
fix if they wanted to. Perhaps we would want to add a few tests?
Thanks.
>
> Do not allow the common suffix to overlap the common prefix and stop
> when reaching a "/" that would be in both.
>
> Signed-off-by: Antoine Pelisse
> ---
> diff.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/diff.c b/diff.c
> index 156fec4..80f4752 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -1290,7 +1290,16 @@ static char *pprint_rename(const char *a, const char
> *b)
> old = a + len_a;
> new = b + len_b;
> sfx_length = 0;
> - while (a <= old && b <= new && *old == *new) {
> + /*
> + * Note:
> + * if pfx_length is 0, old/new will never reach a - 1 because it
> + * would mean the whole string is common suffix. But then, the
> + * whole string would also be a common prefix, and we would not
> + * have pfx_length equals 0.
> + */
> + while (a + pfx_length - 1 <= old &&
> +b + pfx_length - 1 <= new &&
> +*old == *new) {
> if (*old == '/')
> sfx_length = len_a - (old - a);
> old--;
> --
> 1.7.9.5
--
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] attr: allow pattern escape using backslashes
Nguyễn Thái Ngọc Duy writes:
> Patterns in .gitattributes are separated by whitespaces, which makes
> it impossible to specify exact spaces in the pattern. '?' can be used
> as a workaround, but it matches other characters too. This patch makes
> a space following a backslash part of the pattern, not a pattern
> separator.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
>
> A similar patch was posted twice (during freeze time iirc). I think
> this is a good change, so I will keep reposting until someone turns
> it down.
>
> We could use wildmatch for parsing here, which would support patterns
> like "Hello[ ]world". But that's not going to happen until wildmatch
> graduates and somebody brings it up again.
Do people have any comment on this? Do we do something similar in
the .gitignore files already?
Speaking of .gitignore, I recall that there was a hanging discussion
on allowing a pattern to name the directory that the .gitignore file
appears in, which I do not think we currently support. With such a
feature, instead of listing "/junk" in the .gitignore file at the
top-level to say that everything inside the "junk" directory is
ignored by default, we could instead say "" at the beginning
of the .gitignore file in the "junk" directory. I think "* "
in the .gitattributes file in a directory causes "git check-attr ."
in that directory to report the , and we may want to have some
way to allow "git check-ignore ." to be affected by the .gitignore
file in the same directory in a similar way, but I do not have a
very strong opinion. Do people have any comment on this?
It is obviously too late for this cycle to do anything on the
'master' front on this topic (or the .gitignore), but it would be
good to reach concensus early so that we know what we want to do in
the next cycle.
> Documentation/gitattributes.txt | 6 +++---
> attr.c | 8 +++-
> t/t0003-attributes.sh | 5 +
> 3 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
> index 2698f63..113b1f8 100644
> --- a/Documentation/gitattributes.txt
> +++ b/Documentation/gitattributes.txt
> @@ -20,9 +20,9 @@ Each line in `gitattributes` file is of form:
>
> pattern attr1 attr2 ...
>
> -That is, a pattern followed by an attributes list,
> -separated by whitespaces. When the pattern matches the
> -path in question, the attributes listed on the line are given to
> +That is, a pattern followed by an attributes list, separated by
> +whitespaces that are not quoted by a backslash. When the pattern matches
> +the path in question, the attributes listed on the line are given to
> the path.
>
> Each attribute can be in one of these states for a given path:
> diff --git a/attr.c b/attr.c
> index 097ae87..776f34e 100644
> --- a/attr.c
> +++ b/attr.c
> @@ -209,7 +209,13 @@ static struct match_attr *parse_attr_line(const char
> *line, const char *src,
> if (!*cp || *cp == '#')
> return NULL;
> name = cp;
> - namelen = strcspn(name, blank);
> + namelen = 0;
> + while (name[namelen] != '\0' && !strchr(blank, name[namelen])) {
> + if (name[namelen] == '\\' && name[namelen + 1] != '\0')
> + namelen += 2;
> + else
> + namelen++;
> + }
> if (strlen(ATTRIBUTE_MACRO_PREFIX) < namelen &&
> !prefixcmp(name, ATTRIBUTE_MACRO_PREFIX)) {
> if (!macro_ok) {
> diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
> index 807b8b8..6a5d8ab 100755
> --- a/t/t0003-attributes.sh
> +++ b/t/t0003-attributes.sh
> @@ -24,6 +24,7 @@ test_expect_success 'setup' '
> echo "offon -test test"
> echo "no notest"
> echo "A/e/F test=A/e/F"
> + echo "A\\ b test=space"
> ) >.gitattributes &&
> (
> echo "g test=a/g" &&
> @@ -196,6 +197,10 @@ test_expect_success 'root subdir attribute test' '
> attr_check subdir/a/i unspecified
> '
>
> +test_expect_success 'quoting in pattern' '
> + attr_check "A b" space
> +'
> +
> test_expect_success 'negative patterns' '
> echo "!f test=bar" >.gitattributes &&
> test_must_fail git check-attr test -- f
--
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: git send-email should not allow 'y' for in-reply-to
Jeff King writes: > On Fri, Jan 11, 2013 at 10:43:39AM -0800, Hilco Wijbenga wrote: > ... > More seriously, I agree that re-wording the question is a reasonable > thing to do. I do not use send-email, either, so I don't have a strong > opinion on it. The suggestions you made: > >> How about "What Message-ID to use as In-Reply-To for the first email?" >> or "Provide the Message-ID to use as In-Reply-To for the first >> email:". > > seem fine to me. Maybe somebody who has been confused by it can offer > more. At any rate, patches welcome. Has anything come out of this discussion? Is the current phrasing fine as-is? -- 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 05/13] Help.c: add list_common_guides_help() function
Philip Oakley writes: > diff --git a/common-guides.h b/common-guides.h > new file mode 100644 > index 000..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? -- 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 01/13] Use 'Git' in help messages
David Aguilar writes:
> This is referring to "git the command", not "git the system",
> so it should not be changed according to the rule that was
> applied when many "git" strings were changed to "Git".
That sounds like a sensible objection.
> There are scripts, etc. in the wild that parse this output.
> which is another reason we would not want to change this.
Are there? For what purpose?
Especially when these are all _("l10n ready"), I find that somewhat
unlikely.
The bash completion (in contrib/) does read from the command list
IIRC. I do not think it relies on the messages, though.
--
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] Improve QNX support in GIT
Mike Gorchak writes: > Hello, > >> Here is a small patch with QNX build improvements: >> >> 1) Rename tar.h to tar_git.h. Latest QNX versions have system tar.h >> header according to >> http://pubs.opengroup.org/onlinepubs/009696699/basedefs/tar.h.html , >> to avoid inclusion of another tar.h, original header was renamed. >> 2) Rename fnmatch.h to fnmatch_gnu.h and fnmatch.c to fnmatch_gnu.c to >> avoid inclusion of system fnmatch.h header in case if -I/usr/include >> path is specified before -Icompat/fnmatch. Which is common situation. >> 3) pager.c - default "less" invocation flags were changed for QNX 6,x >> platform, since QNX has incompatible with GNU coreutils version of >> "less" utility. >> 4) config.mak.uname - a) do not override mkdtemp/mkstemps/strcasestr >> detection, since newer QNX version could contain such functions. Let >> to configure decide what is present in the system. b) getpagesize() >> function is existing under QNX, c) QNX has pthread functions in the >> libc, so do not define NO_PTHREAD macro. > > Sorry, in the previous post the patch was not inlined. First on the form. The message lacks a proper commit log message and a sign-off. Please check Documentation/SubmittingPatches and also compare the message I am responding to with recent patch submission messages from other people on the list. As to the substance, I am fairly negative about the approach this patch takes, especially the rationale it uses for #2 above. It goes directly against the spirit of having compat/ directory in the first place to have -I/usr/include _before_ -Icompat/anything and that, not the names of header files in compat/ directory, is the root cause of the problem you are seeing, I think. -- 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] pkt-line: Fix sparse errors and warnings
Jeff King writes: >> Oddly, you seemed to miss the one in connect.c (which my sparse does >> detect). > > Ah, I saw why as soon as I finished off the rebase: that (NULL, 0) goes > away in the very next patch,... Yeah, I noticed that myself while replacing 15. The patch in the message I am responding to seems to match byte-for-byte with the result of my rebase, too. Thanks. -- 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 v2] Documentation/githooks: Explain pre-rebase parameters
"W. Trevor King" writes: > On Sat, Feb 23, 2013 at 01:21:59PM -0800, Junio C Hamano wrote: >> "W. Trevor King" writes: >> >> > +This hook is called by 'git rebase' and can be used to prevent a >> > +branch from getting rebased. The hook takes two parameters: the >> > +upstream the series was forked from and the branch being rebased. The >> > +second parameter will be missing when rebasing the current branch. >> >> takes one or two parameters? >> >> Other than that, looks good to me, but it took me two readings to >> notice where these two parameters are described. I have a feeling >> that a comma s/forked from and/forked from, and/; might make them a >> bit more spottable, but others may have better suggestions to make >> them stand out more. > > How about: > > The hook may be called with one or two parameters. The first > parameter is the upstream from which the series was forked. The > second parameter is the branch being rebased, and is not set when > rebasing the current branch. Much nicer. Thanks. -- 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
