RE: [PATCH 4/4] Declare that HP NonStop systems require strings.h
From: Johannes Sixt [mailto:j...@kdbg.org] Sent: Saturday, December 15, 2012 12:17 AM To: Joachim Schmitz Cc: gits...@pobox.com; fedora@gmail.com; Git Mailing List Subject: Re: [PATCH 4/4] Declare that HP NonStop systems require strings.h Am 14.12.2012 23:46, schrieb Joachim Schmitz: Johannes Sixt wrote: Am 14.12.2012 20:57, schrieb David Michael: This platform previously included strings.h automatically. However, the build system now requires an explicit option to do so. Signed-off-by: David Michael fedora@gmail.com --- Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/Makefile b/Makefile index fb78f7f..e84b0cb 100644 --- a/Makefile +++ b/Makefile @@ -1357,6 +1357,7 @@ ifeq ($(uname_S),NONSTOP_KERNEL) # Added manually, see above. NEEDS_SSL_WITH_CURL = YesPlease HAVE_LIBCHARSET_H = YesPlease +HAVE_STRINGS_H = YesPlease NEEDS_LIBICONV = YesPlease NEEDS_LIBINTL_BEFORE_LIBICONV = YesPlease NO_SYS_SELECT_H = UnfortunatelyYes If NONSTOP_KERNEL is the platform that defines __TANDEM, then this should be squashed into the previous patch, shouldn't it? Patch 4/4 does not work without 3/4, Not for HP-NonStop. That is clear from the order of the patches in the series. To put it in a different way: Do all supported platforms still work after 3/4, but without 4/4? Sorry I didn't make myself clear, I left out a and vice versa Bye, Jojo -- 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] Renumber list in api-command.txt
- Start list with 1 instead of 0 because ASCIIDOC will renumber it anyway Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/technical/api-command.txt | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Documentation/technical/api-command.txt b/Documentation/technical/api-command.txt index ea9b2ed..d3b9781 100644 --- a/Documentation/technical/api-command.txt +++ b/Documentation/technical/api-command.txt @@ -71,28 +71,28 @@ Integrating a command Here are the things you need to do when you want to merge a new subcommand into the git tree. -0. Don't forget to sign off your patch! +1. Don't forget to sign off your patch! -1. Append your command name to one of the variables BUILTIN_OBJS, +2. Append your command name to one of the variables BUILTIN_OBJS, EXTRA_PROGRAMS, SCRIPT_SH, SCRIPT_PERL or SCRIPT_PYTHON. -2. Drop its test in the t directory. +3. Drop its test in the t directory. -3. If your command is implemented in an interpreted language with a +4. If your command is implemented in an interpreted language with a p-code intermediate form, make sure .gitignore in the main directory includes a pattern entry that ignores such files. Python .pyc and .pyo files will already be covered. -4. If your command has any dependency on a particular version of +5. If your command has any dependency on a particular version of your language, document it in the INSTALL file. -5. There is a file command-list.txt in the distribution main directory +6. There is a file command-list.txt in the distribution main directory that categorizes commands by type, so they can be listed in appropriate subsections in the documentation's summary command list. Add an entry for yours. To understand the categories, look at git-cmmands.txt in the main directory. -6. Give the maintainer one paragraph to include in the RelNotes file +7. Give the maintainer one paragraph to include in the RelNotes file to describe the new feature; a good place to do so is in the cover letter [PATCH 0/n]. -- 1.8.0.msysgit.0 --- Thomas -- 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: What's cooking in git.git (Dec 2012, #03; Wed, 12)
On Sat, Dec 15, 2012 at 2:45 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Couple of facts first: a) This code was already merged b) This code is for a test c) I'm the only developer so far Cruft in the codebase is a problem for git *developers* because it makes the code harder to maintain and extend. A problem big enough to warrant the rejection of the patch series? No. May I suggest you maintain remote-bzr as a separate project? You have total control that way without anyone's disagreeing with you. So you may be more productive and we have less of these emails back and forth. And speaking from someone whose series may take months to get in, why the rush? -- Duy -- 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: What's cooking in git.git (Dec 2012, #03; Wed, 12)
On Sat, Dec 15, 2012 at 2:44 AM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: On Sat, Dec 15, 2012 at 2:45 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Cruft in the codebase is a problem for git *developers* because it makes the code harder to maintain and extend. A problem big enough to warrant the rejection of the patch series? No. May I suggest you maintain remote-bzr as a separate project? You have total control that way without anyone's disagreeing with you. Which disagreement? We have all agreed how the code should look like in the end. The disagreement is on how and when this code should be merged to git.git. A separate project is not going to help there. And speaking from someone whose series may take months to get in, why the rush? Why the delay? Junio had already merged this code to 'next'. -- Felipe Contreras -- 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 0/3] compiling git with gcc -O3 -Wuninitialized
On Sat, Dec 15, 2012 at 10:07:54AM +0700, Nguyen Thai Ngoc Duy wrote: If get_foo() is not inlined, then when compiling some_fun, gcc sees only that a pointer to the local variable is passed, and must assume that it is an out parameter that is initialized after get_foo returns. However, when get_foo() is inlined, the compiler may look at all of the code together and see that some code paths in get_foo() do not initialize the variable. And we get the extra warnings. Other options: - Any __attribute__ or #pragma to aid flow analysis (or would gcc dev be willing to add one)? I looked through the full list of __attribute__ flags and couldn't find anything that would help. - Maintain a list of false positives and filter them out from gcc output? I think it would be just as simple to use the int foo = foo hack, which accomplishes the same thing without any post-processing step. And if we do this, should we support other compilers as well? I tried clang once a long while ago and got a bunch of warnings iirc. I don't use clang myself, but I don't have any problem with other people submitting patches to clean up its warnings, provided they don't make the code harder to read or write. -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: [PATCH/RFC 0/3] compiling git with gcc -O3 -Wuninitialized
Am 14.12.2012 23:09, schrieb Jeff King: Can anybody think of a clever way to expose the constant return value of error() to the compiler? We could do it with a macro, but that is also out for error(), as we do not assume the compiler has variadic macros. I guess we could hide it behind #ifdef __GNUC__, since it is after all only there to give gcc's analyzer more information. But I'm not sure there is a way to make a macro that is syntactically identical. I.e., you cannot just replace error(...) in return error(...); with a function call plus a value for the return statement. You'd need something more like: #define RETURN_ERROR(fmt, ...) \ do { \ error(fmt, __VA_ARGS__); \ return -1; \ } while(0) \ which is awfully ugly. Does #define error(fmt, ...) (error_impl(fmt, __VA_ARGS__), -1) cause problems when not used in a return statement? -- Hannes -- 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 0/3] compiling git with gcc -O3 -Wuninitialized
On Sat, Dec 15, 2012 at 11:49:25AM +0100, Johannes Sixt wrote: Am 14.12.2012 23:09, schrieb Jeff King: Can anybody think of a clever way to expose the constant return value of error() to the compiler? We could do it with a macro, but that is also out for error(), as we do not assume the compiler has variadic macros. I guess we could hide it behind #ifdef __GNUC__, since it is after all only there to give gcc's analyzer more information. But I'm not sure there is a way to make a macro that is syntactically identical. I.e., you cannot just replace error(...) in return error(...); with a function call plus a value for the return statement. You'd need something more like: #define RETURN_ERROR(fmt, ...) \ do { \ error(fmt, __VA_ARGS__); \ return -1; \ } while(0) \ which is awfully ugly. Does #define error(fmt, ...) (error_impl(fmt, __VA_ARGS__), -1) cause problems when not used in a return statement? Thanks, that was the cleverness I was missing. The only problem is that in standard C, doing this: error(no other arguments); generates: (error_impl(fmt, ), 1); which is bogus. This is a common problem with variadic macros, and fortunately gcc has a solution (and since we are already inside a gcc-only #ifdef, we should be OK). So doing this works for me: diff --git a/git-compat-util.h b/git-compat-util.h index 2e79b8a..a036323 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -285,9 +285,18 @@ extern void warning(const char *err, ...) __attribute__((format (printf, 1, 2))) extern NORETURN void usagef(const char *err, ...) __attribute__((format (printf, 1, 2))); extern NORETURN void die(const char *err, ...) __attribute__((format (printf, 1, 2))); extern NORETURN void die_errno(const char *err, ...) __attribute__((format (printf, 1, 2))); -extern int error(const char *err, ...) __attribute__((format (printf, 1, 2))); extern void warning(const char *err, ...) __attribute__((format (printf, 1, 2))); +#ifdef __GNUC__ +#define ERROR_FUNC_NAME error_impl +#define error(fmt, ...) (error_impl((fmt), ##__VA_ARGS__), -1) +#else +#define ERROR_FUNC_NAME error +#endif + +extern int ERROR_FUNC_NAME(const char *err, ...) +__attribute__((format (printf, 1, 2))); + extern void set_die_routine(NORETURN_PTR void (*routine)(const char *err, va_list params)); extern void set_error_routine(void (*routine)(const char *err, va_list params)); diff --git a/usage.c b/usage.c index 8eab281..d1a58fa 100644 --- a/usage.c +++ b/usage.c @@ -130,7 +130,7 @@ void NORETURN die_errno(const char *fmt, ...) va_end(params); } -int error(const char *err, ...) +int ERROR_FUNC_NAME(const char *err, ...) { va_list params; I think we could even get rid of the ERROR_FUNC_NAME ugliness by just calling it error, and doing an #undef error right before we define it in usage.c. -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: [PATCH 1/3] remote-testsvn: fix unitialized variable
On Friday 14 December 2012 17:11:44 Jeff King wrote: [...] We can fix it by returning -1 when no note is found (so on a zero return, we always found a valid value). Good fix. Parsing of the note now always fails if the note doesn't contain the expected string, as it should. Signed-off-by: Jeff King p...@peff.net --- I think this is the right fix, but I am not too familiar with this code, so I might be missing a case where a missing Revision-number should provide some sentinel value (like 0) instead of returning an error. In fact, of the two callsites, one already does such a zero-initialization. remote-testsvn.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/remote-testsvn.c b/remote-testsvn.c index 51fba05..5ddf11c 100644 --- a/remote-testsvn.c +++ b/remote-testsvn.c @@ -90,10 +90,12 @@ static int parse_rev_note(const char *msg, struct rev_note *res) if (end == value || i 0 || i UINT32_MAX) return -1; res-rev_nr = i; + return 0; } msg += len + 1; } - return 0; + /* didn't find it */ + return -1; } static int note2mark_cb(const unsigned char *object_sha1, -- 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: detect when PYTHON_PATH changes
When make is run the python script are created from *.py files that are changed to use the python given by PYTHON_PATH. And PYTHON_PATH is set by default to /usr/bin/python on Linux. This is nice except when you run make another time setting a different PYTHON_PATH, because, as the python scripts have already been created, make finds nothing to do. The goal of this patch is to detect when the PYTHON_PATH changes and to create the python scripts again when this happens. To do that we use the same trick that is done to track prefix, flags and tcl/tk path. We update a GIT-PYTHON-VARS file with the PYTHON_PATH and check if it changed. Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- Makefile | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 4ad6fbd..bd86063 100644 --- a/Makefile +++ b/Makefile @@ -2245,7 +2245,7 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)) git-instaweb: % : unimplemented.sh endif # NO_PERL ifndef NO_PYTHON -$(patsubst %.py,%,$(SCRIPT_PYTHON)): GIT-CFLAGS GIT-PREFIX +$(patsubst %.py,%,$(SCRIPT_PYTHON)): GIT-CFLAGS GIT-PREFIX GIT-PYTHON-VARS $(patsubst %.py,%,$(SCRIPT_PYTHON)): % : %.py $(QUIET_GEN)$(RM) $@ $@+ \ INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C git_remote_helpers -s \ @@ -2636,6 +2636,18 @@ GIT-GUI-VARS: FORCE fi endif +### Detect Python interpreter path changes +ifndef NO_PYTHON +TRACK_VARS = $(subst ','\'',-DPYTHON_PATH='$(PYTHON_PATH_SQ)') + +GIT-PYTHON-VARS: FORCE + @VARS='$(TRACK_VARS)'; \ + if test x$$VARS != x`cat $@ 2/dev/null` ; then \ + echo 12 * new Python interpreter location; \ + echo $$VARS $@; \ +fi +endif + test_bindir_programs := $(patsubst %,bin-wrappers/%,$(BINDIR_PROGRAMS_NEED_X) $(BINDIR_PROGRAMS_NO_X) $(TEST_PROGRAMS_NEED_X)) all:: $(TEST_PROGRAMS) $(test_bindir_programs) -- 1.8.1.rc1.1.g9537e17 -- 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] Documentation: don't link to example mail addresses
Mail addresses in documentation are converted into mailto: hyperlinks in the HTML output and footnotes in man pages. This isn't desirable for cases where the address is used as an example and is not valid. Particularly annoying is the example jane@laptop.(none) which appears in git-shortlog(1) as jane@laptop[1].(none), with note 1 saying: 1. jane@laptop mailto:jane@laptop Fix this by quoting example mail addresses with $$, preventing Asciidoc from processing them. In the case of mailmap.txt, render the address monospaced so that it matches the block examples surrounding that paragraph. Signed-off-by: John Keeping j...@keeping.me.uk --- I can't see any other uses of the $$ quote in the documentation, so it's probably worth noting that I've tested this with Asciidoc 8.6.8, although I can't see anything in the changelog to indicate that Asciidoc's treatment of it has changed recently. Documentation/git-fast-import.txt | 2 +- Documentation/git-tag.txt | 2 +- Documentation/mailmap.txt | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index d1844ea..05913cc 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -427,7 +427,7 @@ they made it. Here `name` is the person's display name (for example ``Com M Itter'') and `email` is the person's email address -(``c...@example.com''). `LT` and `GT` are the literal less-than (\x3c) +(``$$c...@example.com$$''). `LT` and `GT` are the literal less-than (\x3c) and greater-than (\x3e) symbols. These are required to delimit the email address from the other fields in the line. Note that `name` and `email` are free-form and may contain any sequence diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index 247534e..ed63edb 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -129,7 +129,7 @@ This option is only applicable when listing tags without annotation lines. CONFIGURATION - By default, 'git tag' in sign-with-default mode (-s) will use your -committer identity (of the form Your Name your@email.address) to +committer identity (of the form Your Name $$your@email.address$$) to find a key. If you want to use a different default key, you can specify it in the repository configuration as follows: diff --git a/Documentation/mailmap.txt b/Documentation/mailmap.txt index 288f04e..dd89fca 100644 --- a/Documentation/mailmap.txt +++ b/Documentation/mailmap.txt @@ -46,7 +46,7 @@ Jane Doe jane@desktop.(none) Joe R. Developer j...@example.com -Note how there is no need for an entry for jane@laptop.(none), because the +Note how there is no need for an entry for `jane@laptop.(none)`, because the real name of that author is already correct. Example 2: Your repository contains commits from the following -- 1.8.0 -- 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] Documentation: don't link to example mail addresses
On Sat, Dec 15, 2012 at 03:03:15PM +, John Keeping wrote: Mail addresses in documentation are converted into mailto: hyperlinks in the HTML output and footnotes in man pages. This isn't desirable for cases where the address is used as an example and is not valid. Particularly annoying is the example jane@laptop.(none) which appears in git-shortlog(1) as jane@laptop[1].(none), with note 1 saying: 1. jane@laptop mailto:jane@laptop Thanks, this is definitely worth fixing. Fix this by quoting example mail addresses with $$, preventing Asciidoc from processing them. In the case of mailmap.txt, render the address monospaced so that it matches the block examples surrounding that paragraph. I think I'd just render them monospace everywhere. We are very inconsistent about which form of quotes we use in the documentation (I think because most of the developers read the source directly and not the rendered asciidoc). And then we don't have to worry about the $$ construct (and IMHO it makes the source much more readable, and marking the address as a literal looks good in the output, too). -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: [PATCH] Makefile: detect when PYTHON_PATH changes
Christian Couder chrisc...@tuxfamily.org writes: @@ -2636,6 +2636,18 @@ GIT-GUI-VARS: FORCE fi endif +### Detect Python interpreter path changes +ifndef NO_PYTHON +TRACK_VARS = $(subst ','\'',-DPYTHON_PATH='$(PYTHON_PATH_SQ)') + +GIT-PYTHON-VARS: FORCE + @VARS='$(TRACK_VARS)'; \ + if test x$$VARS != x`cat $@ 2/dev/null` ; then \ + echo 12 * new Python interpreter location; \ + echo $$VARS $@; \ +fi +endif Do we have the same issue when you decide to use /usr/local/bin/sh after building with /bin/sh set to SHELL_PATH? - If yes, I presume that there will be follow-up patches to this one, for SHELL_PATH, PERL_PATH, and TCLTK_PATH (there may be other languages but I didn't bother to check). How would the use of language agnostic looking TRACK_VARS variable in this patch affect such follow-up patches? - If no (in other words, if we rebuild shell-scripted porcelains when SHELL_PATH changes), wouldn't it be better to see how it is done and hook into the same mechanism? - If no, and if the approach taken in this patch is better than the one used to rebuild shell scripts (it may limit the scope of rebuilding when path changes, or something, but again, I didn't bother to check), then again follow-up patches to this one to describe dependencies to build scripts in other languages in a similar way to this patch would come in the future. The same question regarding TRACK_VARS applies in this case. By the way, 12 is easier to read if written as just 2, I think. 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
[PATCH/RFCv2 0/2] compiling git with gcc -O3 -Wuninitialized
On Sat, Dec 15, 2012 at 06:09:30AM -0500, Jeff King wrote: Does #define error(fmt, ...) (error_impl(fmt, __VA_ARGS__), -1) cause problems when not used in a return statement? Thanks, that was the cleverness I was missing. Here it is as patches. One problem with this method is that if the function implementation ever changes to _not_ return -1, then we get no warning that our macro and the function implementation have diverged in meaning. [1/2]: make error()'s constant return value more visible [2/2]: silence some -Wuninitialized false positives These would go on top of 1/3 from the original series to make -Wall -O3 clean (I'll repost the series as a whole when it is more obvious what we want to do). -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
[PATCH 1/2] make error()'s constant return value more visible
When git is compiled with gcc -Wuninitialized -O3, some inlined calls provide an additional opportunity for the compiler to do static analysis on variable initialization. For example, with two functions like this: int get_foo(int *foo) { if (something_that_might_fail() 0) return error(unable to get foo); *foo = 0; return 0; } void some_fun(void) { int foo; if (get_foo(foo) 0) return -1; printf(foo is %d\n, foo); } If get_foo() is not inlined, then when compiling some_fun, gcc sees only that a pointer to the local variable is passed, and must assume that it is an out parameter that is initialized after get_foo returns. However, when get_foo() is inlined, the compiler may look at all of the code together and see that some code paths in get_foo() do not initialize the variable. As a result, it prints a warning. But what the compiler can't see is that error() always returns -1, and therefore we know that either we return early from some_fun, or foo ends up initialized, and the code is safe. The warning is a false positive. If we can make the compiler aware that error() will always return -1, it can do a better job of analysis. The simplest method would be to inline the error() function. However, this doesn't work, because gcc will not inline a variadc function. We can work around this by defining a macro. This relies on two gcc extensions: 1. Variadic macros (these are present in C99, but we do not rely on that). 2. Gcc treats the ## paste operator specially between a comma and __VA_ARGS__, which lets our variadic macro work even if no format parameters are passed to error(). Since we are using these extra features, we hide the macro behind an #ifdef. This is OK, though, because our goal was just to help gcc. Signed-off-by: Jeff King p...@peff.net --- git-compat-util.h | 11 +++ usage.c | 1 + 2 files changed, 12 insertions(+) diff --git a/git-compat-util.h b/git-compat-util.h index 2e79b8a..9002bca 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -288,6 +288,17 @@ extern void warning(const char *err, ...) __attribute__((format (printf, 1, 2))) extern int error(const char *err, ...) __attribute__((format (printf, 1, 2))); extern void warning(const char *err, ...) __attribute__((format (printf, 1, 2))); +/* + * Let callers be aware of the constant return value; this can help + * gcc with -Wuninitialized analysis. We have to restrict this trick to + * gcc, though, because of the variadic macro and the magic ## comma pasting + * behavior. But since we're only trying to help gcc, anyway, it's OK; other + * compilers will fall back to using the function as usual. + */ +#ifdef __GNUC__ +#define error(fmt, ...) (error((fmt), ##__VA_ARGS__), -1) +#endif + extern void set_die_routine(NORETURN_PTR void (*routine)(const char *err, va_list params)); extern void set_error_routine(void (*routine)(const char *err, va_list params)); diff --git a/usage.c b/usage.c index 8eab281..40b3de5 100644 --- a/usage.c +++ b/usage.c @@ -130,6 +130,7 @@ void NORETURN die_errno(const char *fmt, ...) va_end(params); } +#undef error int error(const char *err, ...) { va_list params; -- 1.8.0.2.4.g59402aa -- 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] silence some -Wuninitialized false positives
There are a few error functions that simply wrap error() and provide a standardized message text. Like error(), they always return -1; knowing that can help the compiler silence some false positive -Wuninitialized warnings. One strategy would be to just declare these as inline in the header file so that the compiler can see that they always return -1. However, gcc does not always inline them (e.g., it will not inline opterror, even with -O3), which renders our change pointless. Instead, let's follow the same route we did with error() in the last patch, and define a macro that makes the constant return value obvious to the compiler. Signed-off-by: Jeff King p...@peff.net --- Another option would be to force inlining with __attribute(always_inline)__. But I don't like that, as we are affecting the generated code in that case (and any time we are overriding gcc's decision, I have to assume that it is smarter about when to inline than we are). Other variants include: 1. Inline functions, but keep them as one-liners. E.g.: int opterror(...) { real_opterror(...); return -1; } 2. Using these macros even when __GNUC__ isn't set. Unlike the variadic error() macro, these do not use any special features. If we used them everywhere, the functions themselves could be converted to a void return. That would make it less likely that somebody modifying the function in the future would fail to realize that the error return must always be -1. I dunno. All the solutions are a bit ugly. I really do like being -Wall clean, but I wonder if this is spending too much effort to work around the compiler (we could also just mark these few cases as int foo = foo to say we have manually verified that they're OK). cache.h | 3 +++ config.c| 1 + parse-options.c | 18 +- parse-options.h | 4 4 files changed, 17 insertions(+), 9 deletions(-) diff --git a/cache.h b/cache.h index 18fdd18..0e8e5d8 100644 --- a/cache.h +++ b/cache.h @@ -1136,6 +1136,9 @@ extern int config_error_nonbool(const char *); extern int git_env_bool(const char *, int); extern int git_config_system(void); extern int config_error_nonbool(const char *); +#ifdef __GNUC__ +#define config_error_nonbool(s) (config_error_nonbool(s), -1) +#endif extern const char *get_log_output_encoding(void); extern const char *get_commit_output_encoding(void); diff --git a/config.c b/config.c index fb3f868..526f682 100644 --- a/config.c +++ b/config.c @@ -1660,6 +1660,7 @@ int git_config_rename_section(const char *old_name, const char *new_name) * Call this to report error for your variable that should not * get a boolean value (i.e. [my] var means true). */ +#undef config_error_nonbool int config_error_nonbool(const char *var) { return error(Missing value for '%s', var); diff --git a/parse-options.c b/parse-options.c index c1c66bd..67e98a6 100644 --- a/parse-options.c +++ b/parse-options.c @@ -18,15 +18,6 @@ int optbug(const struct option *opt, const char *reason) return error(BUG: switch '%c' %s, opt-short_name, reason); } -int opterror(const struct option *opt, const char *reason, int flags) -{ - if (flags OPT_SHORT) - return error(switch `%c' %s, opt-short_name, reason); - if (flags OPT_UNSET) - return error(option `no-%s' %s, opt-long_name, reason); - return error(option `%s' %s, opt-long_name, reason); -} - static int get_arg(struct parse_opt_ctx_t *p, const struct option *opt, int flags, const char **arg) { @@ -594,3 +585,12 @@ static int parse_options_usage(struct parse_opt_ctx_t *ctx, return usage_with_options_internal(ctx, usagestr, opts, 0, err); } +#undef opterror +int opterror(const struct option *opt, const char *reason, int flags) +{ + if (flags OPT_SHORT) + return error(switch `%c' %s, opt-short_name, reason); + if (flags OPT_UNSET) + return error(option `no-%s' %s, opt-long_name, reason); + return error(option `%s' %s, opt-long_name, reason); +} diff --git a/parse-options.h b/parse-options.h index 71a39c6..e703853 100644 --- a/parse-options.h +++ b/parse-options.h @@ -177,6 +177,10 @@ extern int opterror(const struct option *opt, const char *reason, int flags); extern int optbug(const struct option *opt, const char *reason); extern int opterror(const struct option *opt, const char *reason, int flags); +#ifdef __GNUC__ +#define opterror(o,r,f) (opterror((o),(r),(f)), -1) +#endif + /*- incremental advanced APIs -*/ enum { -- 1.8.0.2.4.g59402aa -- 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] completion: complete refs for git commit -c
The -c and -C options take an existing commit, so let's complete refs, just as we would for --squash or --fixup. Signed-off-by: Jeff King p...@peff.net --- I notice that the existing code just handles the --foo=bar form of most options. By checking $prev, we can also handle --foo bar form (which we have to do for short options like -c). But it would mean duplicating all of the existing logic. I don't know if it's worth it or not, given that nobody has complained. contrib/completion/git-completion.bash | 7 +++ 1 file changed, 7 insertions(+) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 0b77eb1..a4c48e1 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -971,6 +971,13 @@ _git_commit () { __git_has_doubledash return + case $prev in + -c|-C) + __gitcomp_nl $(__git_refs) ${cur} + return + ;; + esac + case $cur in --cleanup=*) __gitcomp default strip verbatim whitespace -- 1.8.0.2.4.g59402aa -- 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/4] Support builds when sys/param.h is missing
David Michael fedora@gmail.com writes: On Fri, Dec 14, 2012 at 6:41 PM, Junio C Hamano gits...@pobox.com wrote: I have this suspicion that nobody would notice if we simply stopped including the header. While I'm not aware of any subtleties it could be causing on other platforms, it does seem fine to drop sys/param.h on my test GNU/Linux systems. I can resend the series and just remove the include, if preferred. I am sure the patch as posted is much safer, but I was hoping that folks on non-Linux platforms may say I tried to compile with the include removed, and I get identical binaries from before. Until that happens, I would prefer queuing your patch as-is. 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] Documentation: don't link to example mail addresses
Jeff King p...@peff.net writes: I think I'd just render them monospace everywhere. We are very inconsistent about which form of quotes we use in the documentation (I think because most of the developers read the source directly and not the rendered asciidoc). And then we don't have to worry about the $$ construct (and IMHO it makes the source much more readable, and marking the address as a literal looks good in the output, too). Agreed---thanks for spotting, John, and thanks for showing the overall direction, 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: [PATCH] git.c: add --index-file command-line option.
Manlio Perillo manlio.peri...@gmail.com writes: Unlike other environment variables (e.g. GIT_WORK_TREE, GIT_NAMESPACE), it was not possible to set the GIT_INDEX_FILE environment variable using the command line. Is this necessary? I'd prefer to see a better reason than just because others have it. -- 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 v2 1/7] Use split_ident_line to parse author and committer
Currently blame.c::get_acline, pretty.c::pp_user_info() and shortlog.c::insert_one_record are parsing author name, email, time and tz themselves. Use ident.c::split_ident_line for better code reuse. Signed-off-by: Antoine Pelisse apeli...@gmail.com --- builtin/blame.c| 59 +++- builtin/shortlog.c | 36 +--- pretty.c | 35 ++- 3 files changed, 52 insertions(+), 78 deletions(-) diff --git a/builtin/blame.c b/builtin/blame.c index cfae569..dd4aff9 100644 --- a/builtin/blame.c +++ b/builtin/blame.c @@ -1343,8 +1343,9 @@ static void get_ac_line(const char *inbuf, const char *what, int mail_len, char *mail, unsigned long *time, const char **tz) { - int len, tzlen, maillen; - char *tmp, *endp, *timepos, *mailpos; + struct ident_split ident; + int len, tzlen, maillen, namelen; + char *tmp, *endp, *mailpos; tmp = strstr(inbuf, what); if (!tmp) @@ -1355,7 +1356,10 @@ static void get_ac_line(const char *inbuf, const char *what, len = strlen(tmp); else len = endp - tmp; - if (person_len = len) { + if (person_len = len) + goto error_out; + + if (split_ident_line(ident, tmp, len)) { error_out: /* Ugh */ *tz = (unknown); @@ -1364,47 +1368,26 @@ static void get_ac_line(const char *inbuf, const char *what, *time = 0; return; } - memcpy(person, tmp, len); - tmp = person; - tmp += len; - *tmp = 0; - while (person tmp *tmp != ' ') - tmp--; - if (tmp = person) - goto error_out; - *tz = tmp+1; - tzlen = (person+len)-(tmp+1); + namelen = ident.name_end - ident.name_begin; + memcpy(person, ident.name_begin, namelen); + person[namelen] = 0; - *tmp = 0; - while (person tmp *tmp != ' ') - tmp--; - if (tmp = person) - goto error_out; - *time = strtoul(tmp, NULL, 10); - timepos = tmp; + maillen = ident.mail_end - ident.mail_begin + 2; + memcpy(mail, ident.mail_begin - 1, maillen); + mail[maillen] = 0; - *tmp = 0; - while (person tmp !(*tmp == ' ' tmp[1] == '')) - tmp--; - if (tmp = person) - return; - mailpos = tmp + 1; - *tmp = 0; - maillen = timepos - tmp; - memcpy(mail, mailpos, maillen); + *time = strtoul(ident.date_begin, NULL, 10); - if (!mailmap.nr) - return; + tzlen = ident.tz_end - ident.tz_begin; - /* -* mailmap expansion may make the name longer. -* make room by pushing stuff down. -*/ - tmp = person + person_len - (tzlen + 1); - memmove(tmp, *tz, tzlen); + /* Place tz at the end of person */ + *tz = tmp = person + person_len - (tzlen + 1); + memcpy(tmp, ident.tz_begin, tzlen); tmp[tzlen] = 0; - *tz = tmp; + + if (!mailmap.nr) + return; /* * Now, convert both name and e-mail using mailmap diff --git a/builtin/shortlog.c b/builtin/shortlog.c index b316cf3..03c6cd7 100644 --- a/builtin/shortlog.c +++ b/builtin/shortlog.c @@ -40,40 +40,24 @@ static void insert_one_record(struct shortlog *log, char emailbuf[1024]; size_t len; const char *eol; - const char *boemail, *eoemail; struct strbuf subject = STRBUF_INIT; + struct ident_split ident; - boemail = strchr(author, ''); - if (!boemail) - return; - eoemail = strchr(boemail, ''); - if (!eoemail) + if (split_ident_line(ident, author, strlen(author))) return; /* copy author name to namebuf, to support matching on both name and email */ - memcpy(namebuf, author, boemail - author); - len = boemail - author; - while (len 0 isspace(namebuf[len-1])) - len--; + len = ident.name_end - ident.name_begin; + memcpy(namebuf, ident.name_begin, len); namebuf[len] = 0; /* copy email name to emailbuf, to allow email replacement as well */ - memcpy(emailbuf, boemail+1, eoemail - boemail); - emailbuf[eoemail - boemail - 1] = 0; - - if (!map_user(log-mailmap, emailbuf, sizeof(emailbuf), namebuf, sizeof(namebuf))) { - while (author boemail isspace(*author)) - author++; - for (len = 0; -len sizeof(namebuf) - 1 author + len boemail; -len++) - namebuf[len] = author[len]; - while (0 len isspace(namebuf[len-1])) - len--; - namebuf[len] = '\0'; - } - else -
[PATCH v2 2/7] mailmap: Remove buffer length limit in map_user
Remove the hard limit set by mail buffer in map_user and use the strbuf API to replace it. Signed-off-by: Antoine Pelisse apeli...@gmail.com --- mailmap.c | 17 ++--- 1 file changed, 6 insertions(+), 11 deletions(-) diff --git a/mailmap.c b/mailmap.c index ea4b471..3bc6491 100644 --- a/mailmap.c +++ b/mailmap.c @@ -193,7 +193,7 @@ int map_user(struct string_list *map, char *end_of_email; struct string_list_item *item; struct mailmap_entry *me; - char buf[1024], *mailbuf; + struct strbuf mailbuf = STRBUF_INIT; int i; /* figure out space requirement for email */ @@ -204,18 +204,14 @@ int map_user(struct string_list *map, if (!end_of_email) return 0; } - if (end_of_email - email + 1 sizeof(buf)) - mailbuf = buf; - else - mailbuf = xmalloc(end_of_email - email + 1); /* downcase the email address */ + strbuf_grow(mailbuf, end_of_email - email); for (i = 0; i end_of_email - email; i++) - mailbuf[i] = tolower(email[i]); - mailbuf[i] = 0; + strbuf_addch(mailbuf, tolower(email[i])); - debug_mm(map_user: map '%s' %s\n, name, mailbuf); - item = string_list_lookup(map, mailbuf); + debug_mm(map_user: map '%s' %s\n, name, mailbuf.buf); + item = string_list_lookup(map, mailbuf.buf); if (item != NULL) { me = (struct mailmap_entry *)item-util; if (me-namemap.nr) { @@ -226,8 +222,7 @@ int map_user(struct string_list *map, item = subitem; } } - if (mailbuf != buf) - free(mailbuf); + strbuf_release(mailbuf); if (item != NULL) { struct mailmap_info *mi = (struct mailmap_info *)item-util; if (mi-name == NULL (mi-email == NULL || maxlen_email == 0)) { -- 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
[PATCH v2 3/7] mailmap: Simplify map_user() interface
mailmap.c::map_user() is simplified to take two strbuf parameters instead of statically allocated buffers. The buffers are still modified in-place, when mapping is required. It actually makes things easier for callers: - Caller must prepare the call by copying author name and email in strbuf (instead of copying in static buffer) - Caller can easily manipulate the buffer afterward. - Caller doesn't have to call strlen() to calculate the size of the new string. Signed-off-by: Antoine Pelisse apeli...@gmail.com --- builtin/blame.c| 164 +++- builtin/shortlog.c | 31 -- mailmap.c | 51 mailmap.h |4 +- pretty.c | 40 ++--- 5 files changed, 139 insertions(+), 151 deletions(-) diff --git a/builtin/blame.c b/builtin/blame.c index dd4aff9..8586850 100644 --- a/builtin/blame.c +++ b/builtin/blame.c @@ -1321,31 +1321,30 @@ static void pass_blame(struct scoreboard *sb, struct origin *origin, int opt) * Information on commits, used for output. */ struct commit_info { - const char *author; - const char *author_mail; + struct strbuf author; + struct strbuf author_mail; unsigned long author_time; - const char *author_tz; + struct strbuf author_tz; /* filled only when asked for details */ - const char *committer; - const char *committer_mail; + struct strbuf committer; + struct strbuf committer_mail; unsigned long committer_time; - const char *committer_tz; + struct strbuf committer_tz; - const char *summary; + struct strbuf summary; }; /* * Parse author/committer line in the commit object buffer */ static void get_ac_line(const char *inbuf, const char *what, - int person_len, char *person, - int mail_len, char *mail, - unsigned long *time, const char **tz) + struct strbuf *name, struct strbuf *mail, + unsigned long *time, struct strbuf *tz) { struct ident_split ident; - int len, tzlen, maillen, namelen; - char *tmp, *endp, *mailpos; + int len; + char *tmp, *endp; tmp = strstr(inbuf, what); if (!tmp) @@ -1356,51 +1355,61 @@ static void get_ac_line(const char *inbuf, const char *what, len = strlen(tmp); else len = endp - tmp; - if (person_len = len) - goto error_out; if (split_ident_line(ident, tmp, len)) { error_out: /* Ugh */ - *tz = (unknown); - strcpy(person, *tz); - strcpy(mail, *tz); + tmp = (unknown); + strbuf_addstr(name, tmp); + strbuf_addstr(mail, tmp); + strbuf_addstr(tz, tmp); *time = 0; return; } - namelen = ident.name_end - ident.name_begin; - memcpy(person, ident.name_begin, namelen); - person[namelen] = 0; + len = ident.name_end - ident.name_begin; + strbuf_add(name, ident.name_begin, len); - maillen = ident.mail_end - ident.mail_begin + 2; - memcpy(mail, ident.mail_begin - 1, maillen); - mail[maillen] = 0; + len = ident.mail_end - ident.mail_begin; + strbuf_add(mail, ident.mail_begin, len); *time = strtoul(ident.date_begin, NULL, 10); - tzlen = ident.tz_end - ident.tz_begin; + len = ident.tz_end - ident.tz_begin; + strbuf_add(tz, ident.tz_begin, len); - /* Place tz at the end of person */ - *tz = tmp = person + person_len - (tzlen + 1); - memcpy(tmp, ident.tz_begin, tzlen); - tmp[tzlen] = 0; - - if (!mailmap.nr) - return; - - /* +/* * Now, convert both name and e-mail using mailmap */ - if (map_user(mailmap, mail+1, mail_len-1, person, tmp-person-1)) { - /* Add a trailing '' to email, since map_user returns plain emails - Note: It already has '', since we replace from mail+1 */ - mailpos = memchr(mail, '\0', mail_len); - if (mailpos mailpos-mail mail_len - 1) { - *mailpos = ''; - *(mailpos+1) = '\0'; - } - } + if (mailmap.nr) + map_user(mailmap, mail, name); + + strbuf_insert(mail, 0, , 1); + strbuf_addch(mail, ''); +} + +static void commit_info_init(struct commit_info *ci) +{ + + strbuf_init(ci-author, 0); + strbuf_init(ci-author_mail, 0); + strbuf_init(ci-author_tz, 0); + strbuf_init(ci-committer, 0); + strbuf_init(ci-committer_mail, 0); + strbuf_init(ci-committer_tz, 0); + strbuf_init(ci-summary, 0); +} + +static void commit_info_destroy(struct commit_info *ci) +{ + +
[PATCH v2 4/7] mailmap: Add mailmap structure to rev_info and pp
the mailmap string_list structure filled with mailmap information is passed along from rev_info to pretty_print_context to provide mailmap information to pretty print each commits with the correct username and email. Signed-off-by: Antoine Pelisse apeli...@gmail.com --- commit.h |1 + log-tree.c |1 + revision.h |1 + 3 files changed, 3 insertions(+) diff --git a/commit.h b/commit.h index b6ad8f3..7f8f987 100644 --- a/commit.h +++ b/commit.h @@ -89,6 +89,7 @@ struct pretty_print_context { char *notes_message; struct reflog_walk_info *reflog_info; const char *output_encoding; + struct string_list *mailmap; }; struct userformat_want { diff --git a/log-tree.c b/log-tree.c index 4f86def..92254fd 100644 --- a/log-tree.c +++ b/log-tree.c @@ -671,6 +671,7 @@ void show_log(struct rev_info *opt) ctx.preserve_subject = opt-preserve_subject; ctx.reflog_info = opt-reflog_info; ctx.fmt = opt-commit_format; + ctx.mailmap = opt-mailmap; pretty_print_commit(ctx, commit, msgbuf); if (opt-add_signoff) diff --git a/revision.h b/revision.h index 059bfff..83a79f5 100644 --- a/revision.h +++ b/revision.h @@ -143,6 +143,7 @@ struct rev_info { const char *subject_prefix; int no_inline; int show_log_size; + struct string_list *mailmap; /* Filter by commit log message */ struct grep_opt grep_filter; -- 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
[PATCH v2 5/7] pretty: Use mailmap to display username and email
Use the mailmap information to display the correct username and email address in all log commands. Signed-off-by: Antoine Pelisse apeli...@gmail.com --- pretty.c | 48 1 file changed, 28 insertions(+), 20 deletions(-) diff --git a/pretty.c b/pretty.c index d05c675..fbf87b7 100644 --- a/pretty.c +++ b/pretty.c @@ -387,6 +387,8 @@ void pp_user_info(const struct pretty_print_context *pp, const char *what, struct strbuf *sb, const char *line, const char *encoding) { + struct strbuf name; + struct strbuf mail; struct ident_split ident; int linelen, namelen; char *line_end, *date; @@ -408,42 +410,48 @@ void pp_user_info(const struct pretty_print_context *pp, if (split_ident_line(ident, line, linelen)) return; - namelen = ident.mail_end - ident.name_begin + 1; + strbuf_init(mail, 0); + strbuf_init(name, 0); + + strbuf_add(mail, ident.mail_begin, ident.mail_end - ident.mail_begin); + strbuf_add(name, ident.name_begin, ident.name_end - ident.name_begin); + + if (pp-mailmap) + map_user(pp-mailmap, mail, name); + + namelen = name.len + mail.len + 3; /* ' ' + '' + '' */ time = strtoul(ident.date_begin, date, 10); tz = strtol(date, NULL, 10); if (pp-fmt == CMIT_FMT_EMAIL) { - int display_name_length; - - display_name_length = ident.name_end - ident.name_begin; - strbuf_addstr(sb, From: ); - if (needs_rfc2047_encoding(line, display_name_length, RFC2047_ADDRESS)) { - add_rfc2047(sb, line, display_name_length, - encoding, RFC2047_ADDRESS); + if (needs_rfc2047_encoding(name.buf, name.len, RFC2047_ADDRESS)) { + add_rfc2047(sb, name.buf, name.len, + encoding, RFC2047_ADDRESS); max_length = 76; /* per rfc2047 */ - } else if (needs_rfc822_quoting(line, display_name_length)) { + } else if (needs_rfc822_quoting(name.buf, name.len)) { struct strbuf quoted = STRBUF_INIT; - add_rfc822_quoted(quoted, line, display_name_length); + add_rfc822_quoted(quoted, name.buf, name.len); strbuf_add_wrapped_bytes(sb, quoted.buf, quoted.len, -6, 1, max_length); strbuf_release(quoted); } else { - strbuf_add_wrapped_bytes(sb, line, display_name_length, - -6, 1, max_length); + strbuf_add_wrapped_bytes(sb, name.buf, name.len, +-6, 1, max_length); } - if (namelen - display_name_length + last_line_length(sb) max_length) { + if (namelen - name.len + last_line_length(sb) max_length) strbuf_addch(sb, '\n'); - if (!isspace(ident.name_end[0])) - strbuf_addch(sb, ' '); - } - strbuf_add(sb, ident.name_end, namelen - display_name_length); - strbuf_addch(sb, '\n'); + + strbuf_addf(sb, %s\n, mail.buf); } else { - strbuf_addf(sb, %s: %.*s%.*s\n, what, + strbuf_addf(sb, %s: %.*s%s %s\n, what, (pp-fmt == CMIT_FMT_FULLER) ? 4 : 0, - , namelen, line); + , name.buf, mail.buf); } + + strbuf_release(mail); + strbuf_release(name); + switch (pp-fmt) { case CMIT_FMT_MEDIUM: strbuf_addf(sb, Date: %s\n, show_date(time, tz, pp-date_mode)); -- 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
[PATCH v2 7/7] test: Add test for --use-mailmap option
The new option '--use-mailmap' can be used to make sure that mailmap file is used to convert name when running log commands. The test is simple and checks that the Author line is correctly replaced when running log. Signed-off-by: Antoine Pelisse apeli...@gmail.com --- t/t4203-mailmap.sh | 14 ++ 1 file changed, 14 insertions(+) diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh index 1f182f6..db043dc 100755 --- a/t/t4203-mailmap.sh +++ b/t/t4203-mailmap.sh @@ -239,6 +239,20 @@ test_expect_success 'Log output (complex mapping)' ' test_cmp expect actual ' +cat expect \EOF +Author: CTO c...@company.xx +Author: Santa Claus santa.cl...@northpole.xx +Author: Santa Claus santa.cl...@northpole.xx +Author: Other Author ot...@author.xx +Author: Other Author ot...@author.xx +Author: Some Dude s...@dude.xx +Author: A U Thor aut...@example.com +EOF +test_expect_success 'Log output with --use-mailmap' ' + git log --use-mailmap | grep Author actual + test_cmp expect actual +' + # git blame cat expect \EOF ^OBJI (A U Thor DATE 1) one -- 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
[PATCH v2 6/7] log: Add --use-mailmap option
Add the --use-mailmap option to log commands. It allows to display names from mailmap file when displaying logs, whatever the format used. Signed-off-by: Antoine Pelisse apeli...@gmail.com --- Documentation/git-log.txt |5 + builtin/log.c |9 - 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt index 585dac4..a99be97 100644 --- a/Documentation/git-log.txt +++ b/Documentation/git-log.txt @@ -47,6 +47,11 @@ OPTIONS Print out the ref name given on the command line by which each commit was reached. +--use-mailmap:: + Use mailmap file to map author and committer names and email + to canonical real names and email addresses. See + linkgit:git-shortlog[1]. + --full-diff:: Without this flag, git log -p path... shows commits that touch the specified paths, and diffs about the same specified diff --git a/builtin/log.c b/builtin/log.c index e7b7db1..d2bd8ce 100644 --- a/builtin/log.c +++ b/builtin/log.c @@ -22,6 +22,7 @@ #include branch.h #include streaming.h #include version.h +#include mailmap.h /* Set a default date-time format for git log (log.date config variable) */ static const char *default_date_mode = NULL; @@ -94,11 +95,12 @@ static void cmd_log_init_finish(int argc, const char **argv, const char *prefix, struct rev_info *rev, struct setup_revision_opt *opt) { struct userformat_want w; - int quiet = 0, source = 0; + int quiet = 0, source = 0, mailmap = 0; const struct option builtin_log_options[] = { OPT_BOOLEAN(0, quiet, quiet, N_(suppress diff output)), OPT_BOOLEAN(0, source, source, N_(show source)), + OPT_BOOLEAN(0, use-mailmap, mailmap, N_(Use mail map file)), { OPTION_CALLBACK, 0, decorate, NULL, NULL, N_(decorate options), PARSE_OPT_OPTARG, decorate_callback}, OPT_END() @@ -136,6 +138,11 @@ static void cmd_log_init_finish(int argc, const char **argv, const char *prefix, if (source) rev-show_source = 1; + if (mailmap) { + rev-mailmap = xcalloc(1, sizeof(struct string_list)); + read_mailmap(rev-mailmap, NULL); + } + if (rev-pretty_given rev-commit_format == CMIT_FMT_RAW) { /* * log --pretty=raw is special; ignore UI oriented -- 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] README: Git is released under the GPLv2, not just the GPL
Stefano Lattarini stefano.lattar...@gmail.com writes: And this is clearly stressed by Linus in the COPYING file. So make it clear in the README as well, to avoid possible misunderstandings. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- I have nothing against this patch, but I am curious if you saw any misunderstandings in the real world, or if you are merely trying to avoid possible ones. README | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/README b/README index d2690ec..c50e6f4 100644 --- a/README +++ b/README @@ -19,9 +19,10 @@ Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. -Git is an Open Source project covered by the GNU General Public License. -It was originally written by Linus Torvalds with help of a group of -hackers around the net. It is currently maintained by Junio C Hamano. +Git is an Open Source project covered by the GNU General Public License +(version 2). It was originally written by Linus Torvalds with help +of a group of hackers around the net. It is currently maintained by +Junio C Hamano. Please read the file INSTALL for installation instructions. -- 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] Documentation: don't link to example mail addresses
On Sat, Dec 15, 2012 at 12:20:18PM -0500, Jeff King wrote: On Sat, Dec 15, 2012 at 03:03:15PM +, John Keeping wrote: Mail addresses in documentation are converted into mailto: hyperlinks in the HTML output and footnotes in man pages. This isn't desirable for cases where the address is used as an example and is not valid. Particularly annoying is the example jane@laptop.(none) which appears in git-shortlog(1) as jane@laptop[1].(none), with note 1 saying: 1. jane@laptop mailto:jane@laptop Thanks, this is definitely worth fixing. Fix this by quoting example mail addresses with $$, preventing Asciidoc from processing them. In the case of mailmap.txt, render the address monospaced so that it matches the block examples surrounding that paragraph. I think I'd just render them monospace everywhere. We are very inconsistent about which form of quotes we use in the documentation (I think because most of the developers read the source directly and not the rendered asciidoc). And then we don't have to worry about the $$ construct (and IMHO it makes the source much more readable, and marking the address as a literal looks good in the output, too). I agree that the source is more readable as monospaced, but I think we need to keep the quotes around the text in git-tag(1) and probably git-fast-import(1) so that it is differentiated from the surrounding text in the man page output. I just tried this and got strange results. Taking the example in git-tag(1): ...of the form ``Your Name your@email.address'' I tried this to preserve the quotes and make the entire quoted text monospaced (I don't think we want to have just the email address monospaced): ...of the form ```Your Name your@email.address`'' which had the desired effect - smart quotes and everything inside rendered monospaced - BUT the email address is hyperlinked! Switching the smart Asciidoc double quotes (``...'') for normal double quotes (...) produces the desired result, but IMHO doesn't look quite as good (on the other hand it looks like there are many more use of ... than ``...'' in the Git documentation). [While searching, the only other example I could find is in git-commit(1) where `A U Thor aut...@example.com` is rendered monospaced without quotes, but I think this hurts readability in the man page output - expect a follow-up patch if we resolve this in the direction of having quotes and monospaced text.] At this point I've exhausted my Asciidoc knowledge and I'm not entirely happy with any of these options. Suggestions? John -- 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: FW: Git log --graph doesn't output color when redirected
Jeff King p...@peff.net writes: On Sat, Dec 15, 2012 at 10:23:10AM +0700, Nguyen Thai Ngoc Duy wrote: On Thu, Dec 13, 2012 at 8:13 PM, Jeff King p...@peff.net wrote: If you are using --format=%C(red) or similar placeholders, they are the odd duck by not respecting the auto-color mode. But they should, shouldn't they? Just asking. I may do it to when I revive nd/pretty-placeholder-with-color-option. If I were designing --format today, I would certainly say so. The only thing holding me back would be backwards compatibility. We could get around that by introducing a new placeholder like %c(color) that behaves like %C(color), except respects the --color flag. I think the %c(color) thing is a good way to go if we want to pursue this. Another possibility without wasting one more special letter would be to allow %C(auto,red), perhaps like this (untested): pretty.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git i/pretty.c w/pretty.c index dba6828..77cf826 100644 --- i/pretty.c +++ w/pretty.c @@ -960,12 +960,19 @@ static size_t format_commit_one(struct strbuf *sb, const char *placeholder, switch (placeholder[0]) { case 'C': if (placeholder[1] == '(') { - const char *end = strchr(placeholder + 2, ')'); + const char *begin = placeholder + 2; + const char *end = strchr(begin, ')'); char color[COLOR_MAXLEN]; + if (!end) return 0; - color_parse_mem(placeholder + 2, - end - (placeholder + 2), + if (!memcmp(begin, auto,, 5)) { + if (!want_color(GIT_COLOR_AUTO)) + return 0; + begin += 5; + } + color_parse_mem(begin, + end - begin, --pretty format, color); strbuf_addstr(sb, color); return end - placeholder + 1; -- 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] README: Git is released under the GPLv2, not just the GPL
Junio C Hamano gits...@pobox.com writes: Stefano Lattarini stefano.lattar...@gmail.com writes: And this is clearly stressed by Linus in the COPYING file. So make it clear in the README as well, to avoid possible misunderstandings. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- I have nothing against this patch, but I am curious if you saw any misunderstandings in the real world, or if you are merely trying to avoid possible ones. README | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/README b/README index d2690ec..c50e6f4 100644 --- a/README +++ b/README @@ -19,9 +19,10 @@ Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. -Git is an Open Source project covered by the GNU General Public License. -It was originally written by Linus Torvalds with help of a group of -hackers around the net. It is currently maintained by Junio C Hamano. +Git is an Open Source project covered by the GNU General Public License +(version 2). It was originally written by Linus Torvalds with help +of a group of hackers around the net. It is currently maintained by +Junio C Hamano. Please read the file INSTALL for installation instructions. The project as a whole is GPLv2, and inclusion of pieces licensed under different but compatible terms does not change it, but we may want to do this instead. I am just one of the group of hackers around the net in the context of this overview, so I think it is OK to drop that currently maintained by bit. The audience of this document does not have to find out and interact with the maintainer. diff --git a/README b/README index d2690ec..c365e3c 100644 --- a/README +++ b/README @@ -19,9 +19,10 @@ Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. -Git is an Open Source project covered by the GNU General Public License. +Git is an Open Source project covered by the GNU General Public +License version 2 (some parts of it are under different licenses). It was originally written by Linus Torvalds with help of a group of -hackers around the net. It is currently maintained by Junio C Hamano. +hackers around the net. Please read the file INSTALL for installation instructions. -- 1.8.1.rc1.148.gfac1be9 -- 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/2] Port to QNX
Matt Kraai kr...@ftbfs.org writes: This series ports Git to QNX. It builds on both QNX 6.3.2 and QNX 6.5.0. The test suite does not pass. Unless the corresponding software is installed, the following arguments must be passed to Make: NO_CURL=1 NO_GETTEXT=1 NO_OPENSSL=1 NO_PERL=1 NO_PYTHON=1 NO_TCLTK=1 [1/2]: Make lock local to fetch_pack QNX 6.3.2's unistd.h declares a function named lock, which causes fetch-pack.c to fail to compile if lock has file-scope. Since it's only used in a single function, move it therein. [2/2]: Port to QNX I do not mind queuing this on 'pu' but do you want to see your ftbfs.org address in the commit objects, or the other one that you are not using to interact with us? -- 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/2] Make lock local to fetch_pack
Matt Kraai kr...@ftbfs.org writes: From: Matt Kraai matt.kr...@amo.abbott.com lock is only used by fetch_pack, so move it into that function. Signed-off-by: Matt Kraai matt.kr...@amo.abbott.com --- fetch-pack.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Eh, did you base your patch on something older than 2d4177c (Make fetch-pack a builtin with an internal API, 2007-09-10)??? -- 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] git.c: add --index-file command-line option.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 15/12/2012 19:02, Junio C Hamano ha scritto: Manlio Perillo manlio.peri...@gmail.com writes: Unlike other environment variables (e.g. GIT_WORK_TREE, GIT_NAMESPACE), it was not possible to set the GIT_INDEX_FILE environment variable using the command line. Is this necessary? I'd prefer to see a better reason than just because others have it. A long running program will be able to tell git to use an alternate index file, without having to modify its own environment, or having to use execvpe (I assume this is the reason why it is possible to specify GIT_WORK_TREE from command line). Regards Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAlDMxzsACgkQscQJ24LbaUSzEQCYymkZa6JrT42OzigRfDgc5Hss gwCgjIzs1b0hEyu1WAgDgCir9XalDN8= =GtMF -END PGP SIGNATURE- -- 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: Proposal: create meaningful aliases for git reset's hard/soft/mixed
On Wednesday 2012-10-03 21:03, Junio C Hamano wrote: I said that git reset --keep started out as an ugly workaround for the lack of git checkout -B $current_branch. Now we have it, so we can afford to make reset --keep less prominently advertised in our tool set. As I already said back then, reset --soft also has outlived its usefulness when commit --amend came, so that leaves only these modes of reset: Soft is still useful, partway. Consider patch splitting (where easily possible): $ git add foo.c bar.c $ git commit -m foo,bar [other commits] $ git rebase -i FOOBARCOMMIT^ [mark foo,bar for edit] $ git reset --soft HEAD^ $ git reset bar.c $ git commit -m foo $ git add bar.c $ git commit -m bar $ git rebase --continue -- 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] README: Git is released under the GPLv2, not just the GPL
On 12/15/2012 07:35 PM, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: Stefano Lattarini stefano.lattar...@gmail.com writes: And this is clearly stressed by Linus in the COPYING file. So make it clear in the README as well, to avoid possible misunderstandings. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- I have nothing against this patch, but I am curious if you saw any misunderstandings in the real world, or if you are merely trying to avoid possible ones. Only playing safe against possible misunderstandings, especially now that the GPLv3 has taken root and has supplanted the v2 in several projects (e.g., Perl, and obviously most GNU packages). README | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/README b/README index d2690ec..c50e6f4 100644 --- a/README +++ b/README @@ -19,9 +19,10 @@ Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. -Git is an Open Source project covered by the GNU General Public License. -It was originally written by Linus Torvalds with help of a group of -hackers around the net. It is currently maintained by Junio C Hamano. +Git is an Open Source project covered by the GNU General Public License +(version 2). It was originally written by Linus Torvalds with help +of a group of hackers around the net. It is currently maintained by +Junio C Hamano. Please read the file INSTALL for installation instructions. The project as a whole is GPLv2, and inclusion of pieces licensed under different but compatible terms does not change it, but we may want to do this instead. I am just one of the group of hackers around the net in the context of this overview, so I think it is OK to drop that currently maintained by bit. The audience of this document does not have to find out and interact with the maintainer. diff --git a/README b/README index d2690ec..c365e3c 100644 --- a/README +++ b/README @@ -19,9 +19,10 @@ Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. -Git is an Open Source project covered by the GNU General Public License. +Git is an Open Source project covered by the GNU General Public +License version 2 (some parts of it are under different licenses). Maybe you could be even more explicit ans state some parts of it are under different licenses, compatible with the GPLv2. But maybe this is just overkill? It was originally written by Linus Torvalds with help of a group of -hackers around the net. It is currently maintained by Junio C Hamano. +hackers around the net. Please read the file INSTALL for installation instructions. Thanks, Stefano -- 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 0/1] cygwin test failures due to printf
Hi Junio, Sorry for being a bit tardy on this; I noticed these test failures on cygwin close to the start of this cycle, just before I went into hospital, but have only just got around to looking into it... In particular, the following tests fail: t0021, t0030, t1410, t3032, t3304, t3404 and t4132. [The list of failing tests is not actually all that interesting, because the fault is not actually with the tests!] These failures are provoked by commit 7bc0911d (test-lib: Fix say_color () not to interpret \a\b\c in the message, 11-10-2012). If we look at t0021 as a representative, then: $ ./t0021-conversion.sh ok 1 - setup ok 2 - check ok 3 - expanded_in_repo 5 [sig] sh 2388 C:\cygwin\bin\sh.exe: *** fatal error - called with threadlist_ix -1 ./test-lib.sh: line 207: 2388 Hangup \ ( TERM=$ORIGINAL_TERM; export TERM; case $1 in error) tput bold; tput setaf 1 ;; skip) tput bold; tput setaf 4 ;; warn) tput bold; tput setaf 3 ;; pass) tput setaf 2 ;; info) tput setaf 3 ;; *) test -n $quiet return ;; esac; shift; printf %s $*; tput sgr0; echo ) ok 4 - filter shell-escaped filenames ok 5 - required filter success ok 6 - required filter smudge failure ok 7 - required filter clean failure # passed all 7 test(s) 1..7 $ We see that the --color version of say_color(), despite the bash builtin printf function crashing the shell (sh.exe is actually bash for me), passes just fine. Note that the message passed to say_color() is printed before the shell is aborted (via SIGHUP), but that the tput sgr0; echo has been skipped. This results in the occasional line of output in the wrong colour. This has been happening for several years and, given that there are no adverse consequences (ignoring the additional error message spew), I have been happy to ignore this problem. :D Note that the --no-color version of say_color() did not have this problem since it used echo, rather than printf, until commit 7bc0911d ... $ ./t0021-conversion.sh --no-color ok 1 - setup ok 2 - check ok 3 - expanded_in_repo 6 [sig] sh 2740 C:\cygwin\bin\sh.exe: *** fatal error - called with threadlist_ix -1 Hangup $ Note that, unlike the --color version of say_color(), the printf call is not contained within a sub-shell. Indeed, a simple solution to this problem would be to execute the body of the function from within a (...) sub-shell. This actually works, since the extra error message spew does not cause a TAP syntax error to confuse 'prove'. However, I would never suggest this as a solution, given that it already takes over 3 hours to run the tests... Also, note that another solution is to call the external version of printf (e.g. via /usr/bin/printf) but, again, I would not suggest adding to the fork-exec load by replacing a call to a shell builtin with an external program... Note that: $ cygcheck /bin/sh.exe C:/cygwin/bin/sh.exe C:/cygwin/bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll C:/cygwin/bin\cygintl-8.dll C:/cygwin/bin\cygiconv-2.dll C:/cygwin/bin\cygreadline6.dll C:/cygwin/bin\cygncurses-8.dll C:\WINDOWS\system32\USER32.dll C:\WINDOWS\system32\GDI32.dll $ $ strings /bin/cygwin1.dll | grep 'called with' called with threadlist_ix %d called with invalid value %d openlog called with (%s, %d, %d) $ So, the error message is coming from the cygwin dll (no surprise there). I have a fairly recent source snapshot of cygwin, but this message or the code that uses it is not present. In order to debug this further, I would need to find the source code for the version I am using (1.5.22). This does not excite me too much. ;-) As a simpler solution, the patch which follows allows me to customize the function used to do the output. This allows me to revert to using echo and, as a bonus, fixes the --color version of say_color() at the same time. I admit that I find this solution a bit ugly, but it has (at least) two virtues: 1. it works! 2. it's not as ugly as some other solutions I had tried. :-P ATB, Ramsay Jones -- 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] tests: Allow customization of how say_color() prints
Since commit 7bc0911d (test-lib: Fix say_color () not to interpret \a\b\c in the message, 11-10-2012), the --no-color version of say_color() has been using the (bash builtin) printf function, rather than echo, to print the testsuite output. Due to an intermittent (and rare) failure of the printf builtin function on some older versions of cygwin, this leads to several (currently 7) test failures. In order the fix the test failures, we provide a means to customize the function used by say_color() to print the output. The function is customized using GIT_TEST_PRINT[_LN] variables, which are set by default to keep the current behaviour unchanged, but may used from (say) the config.mak file to re-instate the use of echo. This could be done by adding the following to config.mak: GIT_TEST_PRINT=echo -nE GIT_TEST_PRINT_LN=echo -E export GIT_TEST_PRINT GIT_TEST_PRINT_LN Note that the GIT_TEST_PRINT variable is used in the --color version of say_color(), and does not provide the line termination character. In contrast, the GIT_TEST_PRINT_LN variable is used by the --no-color version of say_color() and does provide the line termination. Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- Makefile | 6 ++ t/test-lib.sh | 13 +++-- 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 736ecd4..4f7803e 100644 --- a/Makefile +++ b/Makefile @@ -2603,6 +2603,12 @@ GIT-BUILD-OPTIONS: FORCE ifdef GIT_TEST_OPTS @echo GIT_TEST_OPTS=\''$(subst ','\'',$(subst ','\'',$(GIT_TEST_OPTS)))'\' $@ endif +ifdef GIT_TEST_PRINT + @echo GIT_TEST_PRINT=\''$(subst ','\'',$(subst ','\'',$(GIT_TEST_PRINT)))'\' $@ +endif +ifdef GIT_TEST_PRINT_LN + @echo GIT_TEST_PRINT_LN=\''$(subst ','\'',$(subst ','\'',$(GIT_TEST_PRINT_LN)))'\' $@ +endif ifdef GIT_TEST_CMP @echo GIT_TEST_CMP=\''$(subst ','\'',$(subst ','\'',$(GIT_TEST_CMP)))'\' $@ endif diff --git a/t/test-lib.sh b/t/test-lib.sh index f50f834..9dcf3c1 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -202,6 +202,15 @@ do esac done +if test -z $GIT_TEST_PRINT +then + GIT_TEST_PRINT=printf %s +fi +if test -z $GIT_TEST_PRINT_LN +then + GIT_TEST_PRINT_LN=printf %s\n +fi + if test -n $color then say_color () { @@ -221,7 +230,7 @@ then test -n $quiet return;; esac shift - printf %s $* + $GIT_TEST_PRINT $* tput sgr0 echo ) @@ -230,7 +239,7 @@ else say_color() { test -z $1 test -n $quiet return shift - printf %s\n $* + $GIT_TEST_PRINT_LN $* } fi -- 1.8.0 -- 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] t3070: Disable some failing fnmatch tests
The failing tests make use of a POSIX character class, '[:xdigit:]' in this case, which some versions of the fnmatch() library function do not support. In the spirit of commit f1cf7b79 (t3070: disable unreliable fnmatch tests, 15-10-2012), we disable the fnmatch() half of these tests. Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- Hi Junio, This is against next (branch 'nd/wildmatch'). As an alternative solution, I could build with NO_FNMATCH, since the compat version does support the POSIX charater classes. ATB, Ramsay Jones t/t3070-wildmatch.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh index 3155eab..d5bafef 100755 --- a/t/t3070-wildmatch.sh +++ b/t/t3070-wildmatch.sh @@ -120,9 +120,9 @@ match 0 x '1' '[[:digit:][:upper:][:spaci:]]' match 1 x ' ' '[[:digit:][:upper:][:space:]]' match 0 x '.' '[[:digit:][:upper:][:space:]]' match 1 x '.' '[[:digit:][:punct:][:space:]]' -match 1 1 '5' '[[:xdigit:]]' -match 1 1 'f' '[[:xdigit:]]' -match 1 1 'D' '[[:xdigit:]]' +match 1 x '5' '[[:xdigit:]]' +match 1 x 'f' '[[:xdigit:]]' +match 1 x 'D' '[[:xdigit:]]' match 1 x '_' '[[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:graph:][:lower:][:print:][:punct:][:space:][:upper:][:xdigit:]]' match 1 x '_' '[[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:graph:][:lower:][:print:][:punct:][:space:][:upper:][:xdigit:]]' match 1 x '.' '[^[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:lower:][:space:][:upper:][:xdigit:]]' -- 1.8.0 -- 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] mailmap.c: Fix a sparse warning
In particular, sparse issues an Using plain integer as NULL pointer warning (line 214), since an integer zero is passed as the second actual argument in a strbuf_detach() call. The expected type for this parameter is 'size_t *'. In order to suppress the warning, we simply pass a NULL pointer constant instead. Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- Hi Antoine, When you re-roll your mailmap patches (branch 'ap/log-mailmap') could you please squash this into commit a09b6cd9 (mailmap: Remove buffer length limit in map_user, 11-12-2012). Thanks! ATB, Ramsay Jones mailmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mailmap.c b/mailmap.c index e636278..0608eb3 100644 --- a/mailmap.c +++ b/mailmap.c @@ -211,7 +211,7 @@ int map_user(struct string_list *map, for (i = 0; i end_of_email - email; i++) strbuf_addch(buf, tolower(email[i])); strbuf_addch(buf, 0); - mailbuf = strbuf_detach(buf, 0); + mailbuf = strbuf_detach(buf, NULL); debug_mm(map_user: map '%s' %s\n, name, mailbuf); item = string_list_lookup(map, mailbuf); -- 1.8.0 -- 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/2] Make lock local to fetch_pack
Junio C Hamano gits...@pobox.com writes: Matt Kraai kr...@ftbfs.org writes: From: Matt Kraai matt.kr...@amo.abbott.com lock is only used by fetch_pack, so move it into that function. Signed-off-by: Matt Kraai matt.kr...@amo.abbott.com --- fetch-pack.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Eh, did you base your patch on something older than 2d4177c (Make fetch-pack a builtin with an internal API, 2007-09-10)??? Ah, nevermind. I see we refactored this out recently but that is still in flight. -- 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] git.c: add --index-file command-line option.
Manlio Perillo manlio.peri...@gmail.com writes: Il 15/12/2012 19:02, Junio C Hamano ha scritto: Manlio Perillo manlio.peri...@gmail.com writes: Unlike other environment variables (e.g. GIT_WORK_TREE, GIT_NAMESPACE), it was not possible to set the GIT_INDEX_FILE environment variable using the command line. Is this necessary? I'd prefer to see a better reason than just because others have it. A long running program will be able to tell git to use an alternate index file, without having to modify its own environment,... Hrm, isn't that the single-shot environment export syntax GIT_INDEX_FILE=foo git blah is for? Is there a real-world need for this? -- 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] README: Git is released under the GPLv2, not just the GPL
Stefano Lattarini stefano.lattar...@gmail.com writes: On 12/15/2012 07:35 PM, Junio C Hamano wrote: ... -Git is an Open Source project covered by the GNU General Public License. +Git is an Open Source project covered by the GNU General Public +License version 2 (some parts of it are under different licenses). Maybe you could be even more explicit ans state some parts of it are under different licenses, compatible with the GPLv2. But maybe this is just overkill? I personally do not think it is an overkill; because this clarify that we are version 2, followed by not everything is, but as a whole it is still GPLv2 is in the end about covering our ass, it is better to be as clear as possible without making it into a novel. -- 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] README: Git is released under the GPLv2, not just the GPL
On 12/15/2012 08:39 PM, Junio C Hamano wrote: Stefano Lattarini stefano.lattar...@gmail.com writes: On 12/15/2012 07:35 PM, Junio C Hamano wrote: ... -Git is an Open Source project covered by the GNU General Public License. +Git is an Open Source project covered by the GNU General Public +License version 2 (some parts of it are under different licenses). Maybe you could be even more explicit ans state some parts of it are under different licenses, compatible with the GPLv2. But maybe this is just overkill? I personally do not think it is an overkill; because this clarify that we are version 2, followed by not everything is, but as a whole it is still GPLv2 is in the end about covering our ass, it is better to be as clear as possible without making it into a novel. Well, if you put it this way :-) I agree that it's better be safe than be sorry. Thanks, Stefano -- 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] Makefile: detect when PYTHON_PATH changes
From: Junio C Hamano gits...@pobox.com Subject: Re: [PATCH] Makefile: detect when PYTHON_PATH changes Date: Sat, 15 Dec 2012 09:29:48 -0800 Christian Couder chrisc...@tuxfamily.org writes: @@ -2636,6 +2636,18 @@ GIT-GUI-VARS: FORCE fi endif +### Detect Python interpreter path changes +ifndef NO_PYTHON +TRACK_VARS = $(subst ','\'',-DPYTHON_PATH='$(PYTHON_PATH_SQ)') + +GIT-PYTHON-VARS: FORCE +@VARS='$(TRACK_VARS)'; \ +if test x$$VARS != x`cat $@ 2/dev/null` ; then \ +echo 12 * new Python interpreter location; \ +echo $$VARS $@; \ +fi +endif Do we have the same issue when you decide to use /usr/local/bin/sh after building with /bin/sh set to SHELL_PATH? - If yes, I presume that there will be follow-up patches to this one, for SHELL_PATH, PERL_PATH, and TCLTK_PATH (there may be other languages but I didn't bother to check). How would the use of language agnostic looking TRACK_VARS variable in this patch affect such follow-up patches? Actually, just above the above hunk, there is: ### Detect Tck/Tk interpreter path changes ifndef NO_TCLTK TRACK_VARS = $(subst ','\'',-DTCLTK_PATH='$(TCLTK_PATH_SQ)') GIT-GUI-VARS: FORCE @VARS='$(TRACK_VARS)'; \ if test x$$VARS != x`cat $@ 2/dev/null` ; then \ echo 12 * new Tcl/Tk interpreter location; \ echo $$VARS $@; \ fi endif But you are right, TRACK_VARS should probably be something like TRACK_TCLTK when used for TCLTK and TRACK_PYTHON when used for Python. By the way it looks like GIT-GUI-VARS is not used, so perhaps the detection of Tck/Tk interpreter path changes above could be removed. (The detection is done in git-gui/Makefile too.) About shell, there is the following: SCRIPT_DEFINES = $(SHELL_PATH_SQ):$(DIFF_SQ):$(GIT_VERSION):\ $(localedir_SQ):$(NO_CURL):$(USE_GETTEXT_SCHEME):$(SANE_TOOL_PATH_SQ):\ $(gitwebdir_SQ):$(PERL_PATH_SQ) and then GIT-SCRIPT-DEFINES: FORCE @FLAGS='$(SCRIPT_DEFINES)'; \ if test x$$FLAGS != x`cat $@ 2/dev/null` ; then \ echo 12 * new script parameters; \ echo $$FLAGS $@; \ fi $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh GIT-SCRIPT-DEFINES $(QUIET_GEN)$(cmd_munge_script) \ chmod +x $@+ \ mv $@+ $@ $(SCRIPT_LIB) : % : %.sh GIT-SCRIPT-DEFINES $(QUIET_GEN)$(cmd_munge_script) \ mv $@+ $@ So it looks to me that at least for SHELL_PATH, things are done properly. - If no (in other words, if we rebuild shell-scripted porcelains when SHELL_PATH changes), wouldn't it be better to see how it is done and hook into the same mechanism? You would like me to just add $(PYTHON_PATH_SQ) in SCRIPT_DEFINES and then use GIT-SCRIPT-DEFINES instead of GIT-PYTHON-VARS to decide if python scripts should be rebuilt? - If no, and if the approach taken in this patch is better than the one used to rebuild shell scripts (it may limit the scope of rebuilding when path changes, or something, but again, I didn't bother to check), Yeah, I think it is better because it limits the scope of rebuilding, and because nothing is done for Python, while there are some mechanisms in place for other languages. then again follow-up patches to this one to describe dependencies to build scripts in other languages in a similar way to this patch would come in the future. The same question regarding TRACK_VARS applies in this case. I agree about TRACK_VARS. About other languages, I will have another look, but it seems that they already have what they need. By the way, 12 is easier to read if written as just 2, I think. Ok I will change this. Thanks, Christian. -- 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/7] Allow git log to use mailmap file
Antoine Pelisse apeli...@gmail.com writes: Implement the feature suggested by Rich Mindwinter and Junio C Hamano (and following his advices) Allows git show/log commands to map author and committer names and emails using the mailmap file. Updates related to this second series: - All tests are successful after each patch - Use split_ident_line in shortlog.c - Documentation has been added to git-log.txt - Test has been added to check that we use the file - Lots of improvements in the way strbufs are used - New interface to map_user() - Bunch of other fixes The updated map_user() and its users look much nicer now. Applying your patches with git am --whitespace=error spots a few style violations, though. git glog --committer/--author is still not looking for mailmap user names. I think we should stop using the header grep mechanism for these and instead keep two separate grep expressions in struct rev_info and use them in revision.c::commit_match(). The unification of header filter and message grep filter done in 2d10c55 (git log: Unify header_filter and message_filter into one., 2006-09-20) may not have been a good idea. 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
[ANNOUNCE] Git v1.8.1-rc2
A release candidate Git v1.8.1-rc2 is now available for testing at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: 0a65a3d203b8d6e320f15abb040e1137e333c967 git-1.8.1.rc2.tar.gz e6bc111686e6864cc3f078b9523ef1057a7fff8f git-htmldocs-1.8.1.rc2.tar.gz 2c97472ae861454ff445868c40b49db66fa09f50 git-manpages-1.8.1.rc2.tar.gz Also the following public repositories all have a copy of the v1.8.1-rc2 tag and the master branch that the tag points at: url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v1.8.1 Release Notes (draft) Backward compatibility notes In the next major release (not *this* one), we will change the behavior of the git push command. When git push [$there] does not say what to push, we have used the traditional matching semantics so far (all your branches were sent to the remote as long as there already are branches of the same name over there). We will use the simple semantics that pushes the current branch to the branch with the same name, only when the current branch is set to integrate with that remote branch. There is a user preference configuration variable push.default to change this, and git push will warn about the upcoming change until you set this variable in this release. git branch --set-upstream is deprecated and may be removed in a relatively distant future. git branch [-u|--set-upstream-to] has been introduced with a saner order of arguments to replace it. Updates since v1.8.0 UI, Workflows Features * Command-line completion scripts for tcsh and zsh have been added. * A new remote-helper interface for Mercurial has been added to contrib/remote-helpers. * We used to have a workaround for a bug in ancient less that causes it to exit without any output when the terminal is resized. The bug has been fixed in less version 406 (June 2007), and the workaround has been removed in this release. * Some documentation pages that used to ship only in the plain text format are now formatted in HTML as well. * git-prompt scriptlet (in contrib/completion) can be told to paint pieces of the hints in the prompt string in colors. * A new configuration variable diff.context can be used to give the default number of context lines in the patch output, to override the hardcoded default of 3 lines. * When git checkout checks out a branch, it tells the user how far behind (or ahead) the new branch is relative to the remote tracking branch it builds upon. The message now also advises how to sync them up by pushing or pulling. This can be disabled with the advice.statusHints configuration variable. * git config --get used to diagnose presence of multiple definitions of the same variable in the same configuration file as an error, but it now applies the last one wins rule used by the internal configuration logic. Strictly speaking, this may be an API regression but it is expected that nobody will notice it in practice. * git log -p -Sstring now looks for the string after applying the textconv filter (if defined); earlier it inspected the contents of the blobs without filtering. * git format-patch learned the --notes=ref option to give notes for the commit after the three-dash lines in its output. * git log --grep=pcre learned to honor the grep.patterntype configuration set to perl. * git replace -d object now interprets object as an extended SHA-1 (e.g. HEAD~4 is allowed), instead of only accepting full hex object name. * git rm $submodule used to punt on removing a submodule working tree to avoid losing the repository embedded in it. Because recent git uses a mechanism to separate the submodule repository from the submodule working tree, git rm learned to detect this case and removes the submodule working tree when it is safe to do so. * git send-email used to prompt for the sender address, even when the committer identity is well specified (e.g. via user.name and user.email configuration variables). The command no longer gives this prompt when not necessary. * git send-email did not allow non-address garbage strings to appear after addresses on Cc: lines in the patch files (and when told to pick them up to find more recipients), e.g. Cc: Stable Kernel sta...@k.org # for v3.2 and up The command now strips # for v3.2 and up part before adding the remainder of this line to the list of recipients. * git submodule add learned to add a new submodule at the same path as the path where an unrelated submodule was bound to in an existing revision via the --name option. * git submodule sync
Re: [PATCH] git.c: add --index-file command-line option.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 15/12/2012 20:36, Junio C Hamano ha scritto: [...] Unlike other environment variables (e.g. GIT_WORK_TREE, GIT_NAMESPACE), it was not possible to set the GIT_INDEX_FILE environment variable using the command line. Is this necessary? I'd prefer to see a better reason than just because others have it. A long running program will be able to tell git to use an alternate index file, without having to modify its own environment,... Hrm, isn't that the single-shot environment export syntax GIT_INDEX_FILE=foo git blah is for? Is there a real-world need for this? This works with a shell. I'm using Python to write a custom git command. Regards Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDM8yQACgkQscQJ24LbaUTftQCbBC7D9P7Sqlr9GzWuCIcIHPf2 aQcAn13+d4trLZS4izGvZtoaopMav4nV =vfb6 -END PGP SIGNATURE- -- 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/2] Port to QNX
On Sat, Dec 15, 2012 at 10:38:30AM -0800, Junio C Hamano wrote: I do not mind queuing this on 'pu' but do you want to see your ftbfs.org address in the commit objects, or the other one that you are not using to interact with us? Great! I'd prefer to use the amo.abbott.com address in the commit objects, since that's where I did the work. I'm using this email address because it doesn't require figuring out how to send proper emails via Outlook and/or Exchange. -- Matt -- 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 v4 0/4] nd/invalidate-i-t-a-cache-tree
This version also fixes the CE_REMOVE bug I mentioned. As a side effect, the bug fix makes the i-t-a fix cleaner. Nguyễn Thái Ngọc Duy (4): cache-tree: remove dead i-t-a code in verify_cache() cache-tree: replace for loops in update_one with while loops cache-tree: fix writing cache-tree when CE_REMOVE is present cache-tree: invalidate i-t-a paths after generating trees cache-tree.c | 61 +-- cache-tree.h | 1 + t/t2203-add-intent.sh | 20 + 3 files changed, 65 insertions(+), 17 deletions(-) -- 1.8.0.rc2.23.g1fb49df -- 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 v4 1/4] cache-tree: remove dead i-t-a code in verify_cache()
This code is added in 331fcb5 (git add --intent-to-add: do not let an empty blob be committed by accident - 2008-11-28) to forbid committing when i-t-a entries are present. When we allow that, we forgot to remove this. Noticed-by: Junio C Hamano gits...@pobox.com Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- cache-tree.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/cache-tree.c b/cache-tree.c index 28ed657..e2beab5 100644 --- a/cache-tree.c +++ b/cache-tree.c @@ -166,12 +166,8 @@ static int verify_cache(struct cache_entry **cache, fprintf(stderr, ...\n); break; } - if (ce_stage(ce)) - fprintf(stderr, %s: unmerged (%s)\n, - ce-name, sha1_to_hex(ce-sha1)); - else - fprintf(stderr, %s: not added yet\n, - ce-name); + fprintf(stderr, %s: unmerged (%s)\n, + ce-name, sha1_to_hex(ce-sha1)); } } if (funny) -- 1.8.0.rc2.23.g1fb49df -- 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 v4 2/4] cache-tree: replace for loops in update_one with while loops
The loops in update_one can be increased in two different ways: step by one for files and by n for directories. for loop is not suitable for this as it always steps by one and special handling is required for directories. Replace them with while loops for clarity. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- cache-tree.c | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/cache-tree.c b/cache-tree.c index e2beab5..44eed28 100644 --- a/cache-tree.c +++ b/cache-tree.c @@ -259,7 +259,8 @@ static int update_one(struct cache_tree *it, /* * Find the subtrees and update them. */ - for (i = 0; i entries; i++) { + i = 0; + while (i entries) { struct cache_entry *ce = cache[i]; struct cache_tree_sub *sub; const char *path, *slash; @@ -271,8 +272,10 @@ static int update_one(struct cache_tree *it, break; /* at the end of this level */ slash = strchr(path + baselen, '/'); - if (!slash) + if (!slash) { + i++; continue; + } /* * a/bbb/c (base = a/, slash = /c) * == @@ -289,7 +292,7 @@ static int update_one(struct cache_tree *it, flags); if (subcnt 0) return subcnt; - i += subcnt - 1; + i += subcnt; sub-used = 1; } @@ -300,7 +303,8 @@ static int update_one(struct cache_tree *it, */ strbuf_init(buffer, 8192); - for (i = 0; i entries; i++) { + i = 0; + while (i entries) { struct cache_entry *ce = cache[i]; struct cache_tree_sub *sub; const char *path, *slash; @@ -320,7 +324,7 @@ static int update_one(struct cache_tree *it, if (!sub) die(cache-tree.c: '%.*s' in '%s' not found, entlen, path + baselen, path); - i += sub-cache_tree-entry_count - 1; + i += sub-cache_tree-entry_count; sha1 = sub-cache_tree-sha1; mode = S_IFDIR; } @@ -328,6 +332,7 @@ static int update_one(struct cache_tree *it, sha1 = ce-sha1; mode = ce-ce_mode; entlen = pathlen - baselen; + i++; } if (mode != S_IFGITLINK !missing_ok !has_sha1_file(sha1)) { strbuf_release(buffer); -- 1.8.0.rc2.23.g1fb49df -- 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 v4 3/4] cache-tree: fix writing cache-tree when CE_REMOVE is present
entry_count is used in update_one() for two purposes: 1. to skip through the number of processed entries in in-memory index 2. to record the number of entries this cache-tree covers on disk Unfortunately when CE_REMOVE is present these numbers are not the same because CE_REMOVE entries are automatically removed before writing to disk but entry_count is not adjusted and still counts CE_REMOVE entries. Separate the two use cases into two different variables. #1 is taken care by the new field count in struct cache_tree_sub and entry_count is prepared for #2. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- cache-tree.c | 30 +++--- cache-tree.h | 1 + 2 files changed, 24 insertions(+), 7 deletions(-) diff --git a/cache-tree.c b/cache-tree.c index 44eed28..2c10b2e 100644 --- a/cache-tree.c +++ b/cache-tree.c @@ -238,6 +238,7 @@ static int update_one(struct cache_tree *it, int entries, const char *base, int baselen, + int *skip_count, int flags) { struct strbuf buffer; @@ -245,6 +246,8 @@ static int update_one(struct cache_tree *it, int dryrun = flags WRITE_TREE_DRY_RUN; int i; + *skip_count = 0; + if (0 = it-entry_count has_sha1_file(it-sha1)) return it-entry_count; @@ -264,7 +267,7 @@ static int update_one(struct cache_tree *it, struct cache_entry *ce = cache[i]; struct cache_tree_sub *sub; const char *path, *slash; - int pathlen, sublen, subcnt; + int pathlen, sublen, subcnt, subskip; path = ce-name; pathlen = ce_namelen(ce); @@ -289,10 +292,13 @@ static int update_one(struct cache_tree *it, cache + i, entries - i, path, baselen + sublen + 1, + subskip, flags); if (subcnt 0) return subcnt; i += subcnt; + sub-count = subcnt; /* to be used in the next loop */ + *skip_count += subskip; sub-used = 1; } @@ -324,7 +330,7 @@ static int update_one(struct cache_tree *it, if (!sub) die(cache-tree.c: '%.*s' in '%s' not found, entlen, path + baselen, path); - i += sub-cache_tree-entry_count; + i += sub-count; sha1 = sub-cache_tree-sha1; mode = S_IFDIR; } @@ -340,8 +346,18 @@ static int update_one(struct cache_tree *it, mode, sha1_to_hex(sha1), entlen+baselen, path); } - if (ce-ce_flags (CE_REMOVE | CE_INTENT_TO_ADD)) - continue; /* entry being removed or placeholder */ + /* +* CE_REMOVE entries are removed before the index is +* written to disk. Skip them to remain consistent +* with the future on-disk index. +*/ + if (ce-ce_flags CE_REMOVE) { + *skip_count = *skip_count + 1; + continue; + } + + if (ce-ce_flags CE_INTENT_TO_ADD) + continue; strbuf_grow(buffer, entlen + 100); strbuf_addf(buffer, %o %.*s%c, mode, entlen, path + baselen, '\0'); @@ -361,7 +377,7 @@ static int update_one(struct cache_tree *it, } strbuf_release(buffer); - it-entry_count = i; + it-entry_count = i - *skip_count; #if DEBUG fprintf(stderr, cache-tree update-one (%d ent, %d subtree) %s\n, it-entry_count, it-subtree_nr, @@ -375,11 +391,11 @@ int cache_tree_update(struct cache_tree *it, int entries, int flags) { - int i; + int i, skip; i = verify_cache(cache, entries, flags); if (i) return i; - i = update_one(it, cache, entries, , 0, flags); + i = update_one(it, cache, entries, , 0, skip, flags); if (i 0) return i; return 0; diff --git a/cache-tree.h b/cache-tree.h index d8cb2e9..55d0f59 100644 --- a/cache-tree.h +++ b/cache-tree.h @@ -7,6 +7,7 @@ struct cache_tree; struct cache_tree_sub { struct cache_tree *cache_tree; + int count; /* internally used by update_one() */ int namelen; int used; char name[FLEX_ARRAY]; -- 1.8.0.rc2.23.g1fb49df -- 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
[PATCH v4 4/4] cache-tree: invalidate i-t-a paths after generating trees
Intent-to-add entries used to forbid writing trees so it was not a problem. After commit 3f6d56d (commit: ignore intent-to-add entries instead of refusing - 2012-02-07), we can generate trees from an index with i-t-a entries. However, the commit forgets to invalidate all paths leading to i-t-a entries. With fully valid cache-tree (e.g. after commit or write-tree), diff operations may prefer cache-tree to index and not see i-t-a entries in the index, because cache-tree does not have them. Reported-by: Jonathon Mah m...@jonathonmah.com Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- cache-tree.c | 14 -- t/t2203-add-intent.sh | 20 2 files changed, 32 insertions(+), 2 deletions(-) diff --git a/cache-tree.c b/cache-tree.c index 2c10b2e..37e4d00 100644 --- a/cache-tree.c +++ b/cache-tree.c @@ -244,6 +244,7 @@ static int update_one(struct cache_tree *it, struct strbuf buffer; int missing_ok = flags WRITE_TREE_MISSING_OK; int dryrun = flags WRITE_TREE_DRY_RUN; + int to_invalidate = 0; int i; *skip_count = 0; @@ -333,6 +334,8 @@ static int update_one(struct cache_tree *it, i += sub-count; sha1 = sub-cache_tree-sha1; mode = S_IFDIR; + if (sub-cache_tree-entry_count 0) + to_invalidate = 1; } else { sha1 = ce-sha1; @@ -356,8 +359,15 @@ static int update_one(struct cache_tree *it, continue; } - if (ce-ce_flags CE_INTENT_TO_ADD) + /* +* CE_INTENT_TO_ADD entries exist on on-disk index but +* they are not part of generated trees. Invalidate up +* to root to force cache-tree users to read elsewhere. +*/ + if (ce-ce_flags CE_INTENT_TO_ADD) { + to_invalidate = 1; continue; + } strbuf_grow(buffer, entlen + 100); strbuf_addf(buffer, %o %.*s%c, mode, entlen, path + baselen, '\0'); @@ -377,7 +387,7 @@ static int update_one(struct cache_tree *it, } strbuf_release(buffer); - it-entry_count = i - *skip_count; + it-entry_count = to_invalidate ? -1 : i - *skip_count; #if DEBUG fprintf(stderr, cache-tree update-one (%d ent, %d subtree) %s\n, it-entry_count, it-subtree_nr, diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh index ec35409..2a4a749 100755 --- a/t/t2203-add-intent.sh +++ b/t/t2203-add-intent.sh @@ -62,5 +62,25 @@ test_expect_success 'can commit -a with an i-t-a entry' ' git commit -a -m all ' +test_expect_success 'cache-tree invalidates i-t-a paths' ' + git reset --hard + mkdir dir + : dir/foo + git add dir/foo + git commit -m foo + + : dir/bar + git add -N dir/bar + git diff --cached --name-only actual + echo dir/bar expect + test_cmp expect actual + + git write-tree /dev/null + + git diff --cached --name-only actual + echo dir/bar expect + test_cmp expect actual +' + test_done -- 1.8.0.rc2.23.g1fb49df -- 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] t3070: Disable some failing fnmatch tests
On Sun, Dec 16, 2012 at 2:19 AM, Ramsay Jones ram...@ramsay1.demon.co.uk wrote: The failing tests make use of a POSIX character class, '[:xdigit:]' in this case, which some versions of the fnmatch() library function do not support. In the spirit of commit f1cf7b79 (t3070: disable unreliable fnmatch tests, 15-10-2012), we disable the fnmatch() half of these tests. I have no problem with this. You're on cygwin, right? -- Duy -- 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] git.c: add --index-file command-line option.
I Manlio Perillo manlio.peri...@gmail.com writes: This works with a shell. I'm using Python to write a custom git command. I would be very surprised if Python lacked a way to spawn a subprocess with an environment modified from the current process. -- 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] tests: Allow customization of how say_color() prints
Ramsay Jones ram...@ramsay1.demon.co.uk writes: diff --git a/t/test-lib.sh b/t/test-lib.sh index f50f834..9dcf3c1 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -202,6 +202,15 @@ do esac done +if test -z $GIT_TEST_PRINT +then + GIT_TEST_PRINT=printf %s +fi +if test -z $GIT_TEST_PRINT_LN +then + GIT_TEST_PRINT_LN=printf %s\n +fi + if test -n $color then say_color () { @@ -221,7 +230,7 @@ then test -n $quiet return;; esac shift - printf %s $* + $GIT_TEST_PRINT $* tput sgr0 echo ) @@ -230,7 +239,7 @@ else say_color() { test -z $1 test -n $quiet return shift - printf %s\n $* + $GIT_TEST_PRINT_LN $* } fi As you said, this is ugly and also unwieldy in that I do not see an easy way for a platform/builder to define something that needs to pass a parameter with $IFS in it in these two variables. Why does your printf die 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 v4 3/4] cache-tree: fix writing cache-tree when CE_REMOVE is present
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: entry_count is used in update_one() for two purposes: 1. to skip through the number of processed entries in in-memory index 2. to record the number of entries this cache-tree covers on disk Unfortunately when CE_REMOVE is present these numbers are not the same because CE_REMOVE entries are automatically removed before writing to disk but entry_count is not adjusted and still counts CE_REMOVE entries. Nicely explained. I wonder if we can also add a piece of test to the patch 4/4 to demonstrate the issue with CE_REMOVE entries, though. 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