RE: [PATCH 4/4] Declare that HP NonStop systems require strings.h

2012-12-15 Thread Joachim Schmitz
 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

2012-12-15 Thread Thomas Ackermann

- 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)

2012-12-15 Thread Nguyen Thai Ngoc Duy
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)

2012-12-15 Thread Felipe Contreras
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

2012-12-15 Thread Jeff King
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

2012-12-15 Thread Johannes Sixt
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

2012-12-15 Thread Jeff King
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

2012-12-15 Thread Florian Achleitner
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

2012-12-15 Thread Christian Couder
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

2012-12-15 Thread John Keeping
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

2012-12-15 Thread Jeff King
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

2012-12-15 Thread Junio C Hamano
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

2012-12-15 Thread Jeff King
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

2012-12-15 Thread Jeff King
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

2012-12-15 Thread Jeff King
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

2012-12-15 Thread Jeff King
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

2012-12-15 Thread Junio C Hamano
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

2012-12-15 Thread Junio C Hamano
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.

2012-12-15 Thread Junio C Hamano
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

2012-12-15 Thread Antoine Pelisse
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

2012-12-15 Thread Antoine Pelisse
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

2012-12-15 Thread Antoine Pelisse
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

2012-12-15 Thread Antoine Pelisse
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

2012-12-15 Thread Antoine Pelisse
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

2012-12-15 Thread Antoine Pelisse
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

2012-12-15 Thread Antoine Pelisse
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

2012-12-15 Thread Junio C Hamano
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

2012-12-15 Thread John Keeping
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

2012-12-15 Thread Junio C Hamano
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

2012-12-15 Thread Junio C Hamano
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

2012-12-15 Thread Junio C Hamano
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

2012-12-15 Thread Junio C Hamano
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.

2012-12-15 Thread Manlio Perillo
-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

2012-12-15 Thread Jan Engelhardt

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

2012-12-15 Thread Stefano Lattarini
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

2012-12-15 Thread Ramsay Jones

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

2012-12-15 Thread Ramsay Jones

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

2012-12-15 Thread Ramsay Jones

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

2012-12-15 Thread Ramsay Jones

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

2012-12-15 Thread Junio C Hamano
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.

2012-12-15 Thread Junio C Hamano
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

2012-12-15 Thread Junio C Hamano
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

2012-12-15 Thread Stefano Lattarini
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

2012-12-15 Thread Christian Couder
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

2012-12-15 Thread Junio C Hamano
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

2012-12-15 Thread Junio C Hamano
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.

2012-12-15 Thread Manlio Perillo
-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

2012-12-15 Thread Matt Kraai
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

2012-12-15 Thread Nguyễn Thái Ngọc Duy
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()

2012-12-15 Thread Nguyễn Thái Ngọc Duy
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

2012-12-15 Thread Nguyễn Thái Ngọc Duy
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

2012-12-15 Thread Nguyễn Thái Ngọc Duy
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

2012-12-15 Thread Nguyễn Thái Ngọc Duy
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

2012-12-15 Thread Nguyen Thai Ngoc Duy
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.

2012-12-15 Thread Junio C Hamano
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

2012-12-15 Thread Junio C Hamano
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

2012-12-15 Thread Junio C Hamano
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