Re: What's cooking in git.git (Oct 2013, #07; Mon, 28)
On 30/10/13 20:30, Torsten Bögershausen wrote:
> On 2013-10-30 20.06, Ramsay Jones wrote:
>> On 30/10/13 17:14, Torsten Bögershausen wrote:
>>> On 2013-10-30 18.01, Vicent Martí wrote:
On Wed, Oct 30, 2013 at 5:51 PM, Torsten Bögershausen
wrote:
> There is a name clash under cygwin 1.7 (1.5 is OK)
> The following "first aid hot fix" works for me:
> /Torsten
If Cygwin declares its own bswap_64, wouldn't it be better to use it
instead of overwriting it with our own?
>>> Yes,
>>> this will be part of a longer patch.
>>> I found that some systems have something like this:
>>>
>>> #define htobe64(x) bswap_64(x)
>>> And bswap_64 is a function, so we can not detect it by "asking"
>>> #ifdef bswap_64
>>> ..
>>> #endif
>>>
>>>
>>> But we can use
>>> #ifdef htobe64
>>> ...
>>> #endif
>>> and this will be part of a bigger patch.
>>>
>>> And, in general, we should avoid to introduce functions which may have a
>>> name clash.
>>> Using the git_ prefix for function names is a good practice.
>>> So in order to unbrake the compilation error under cygwin 17,
>>> the "hotfix" can be used.
>>
>> heh, my patch (given below) took a different approach, but
>>
>> ATB,
>> Ramsay Jones
>>
>> -- >8 --
>> Subject: [PATCH] compat/bswap.h: Fix redefinition of bswap_64 error on cygwin
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 8bit
>>
>> Since commit 452e0f20 ("compat: add endianness helpers", 24-10-2013)
>> the cygwin build has failed like so:
>>
>> GIT_VERSION = 1.8.4.1.804.g1f3748b
>> * new build flags
>> CC credential-store.o
>> In file included from git-compat-util.h:305:0,
>> from cache.h:4,
>> from credential-store.c:1:
>> compat/bswap.h:67:24: error: redefinition of 'bswap_64'
>> In file included from /usr/include/endian.h:32:0,
>> from /usr/include/cygwin/types.h:21,
>> from /usr/include/sys/types.h:473,
>> from /usr/include/sys/unistd.h:9,
>> from /usr/include/unistd.h:4,
>> from git-compat-util.h:98,
>> from cache.h:4,
>> from credential-store.c:1:
>> /usr/include/byteswap.h:31:1: note: previous definition of \
>> ‘bswap_64’ was here
>> Makefile:1985: recipe for target 'credential-store.o' failed
>> make: *** [credential-store.o] Error 1
>>
>> Note that cygwin has a defintion of 'bswap_64' in the
>> header file (which had already been included by git-compat-util.h).
>> In order to suppress the error, ensure that the header
>> is included, just like the __GNUC__/__GLIBC__ case, rather than
>> attempting to define a fallback implementation.
>>
>> Signed-off-by: Ramsay Jones
>> ---
>> compat/bswap.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/compat/bswap.h b/compat/bswap.h
>> index ea1a9ed..b864abd 100644
>> --- a/compat/bswap.h
>> +++ b/compat/bswap.h
>> @@ -61,7 +61,7 @@ static inline uint32_t git_bswap32(uint32_t x)
>> # define ntohll(n) (n)
>> # define htonll(n) (n)
>> #elif __BYTE_ORDER == __LITTLE_ENDIAN
>> -# if defined(__GNUC__) && defined(__GLIBC__)
>> +# if defined(__GNUC__) && (defined(__GLIBC__) || defined(__CYGWIN__))
>> # include
>> # else /* GNUC & GLIBC */
>> static inline uint64_t bswap_64(uint64_t val)
>>
>
> Nice, much better.
>
> And here comes a patch for a big endian machine.
> I tryied to copy-paste a patch in my mail program,
> not sure if this applies.
>
> -- >8 --
> Subject: [PATCH] compat/bswap.h: htonll and ntohll for big endian
>
> Since commit 452e0f20 ("compat: add endianness helpers", 24-10-2013)
> the build on a Linux/ppc gave a warning like this:
> CC ewah/ewah_io.o
> ewah/ewah_io.c: In function ‘ewah_serialize_to’:
> ewah/ewah_io.c:81: warning: implicit declaration of function ‘htonll’
> ewah/ewah_io.c: In function ‘ewah_read_mmap’:
> ewah/ewah_io.c:132: warning: implicit declaration of function ‘ntohll’
>
> Fix it by placing the #endif for "#ifdef bswap32" at the right place.
>
> Signed-off-by: Torsten Bögershausen
> ---
> compat/bswap.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/compat/bswap.h b/compat/bswap.h
> index ea1a9ed..b4ddab0
> --- a/compat/bswap.h
> +++ b/compat/bswap.h
> @@ -46,6 +46,7 @@ static inline uint32_t git_bswap32(uint32_t x)
> #undef htonl
> #define ntohl(x) bswap32(x)
> #define htonl(x) bswap32(x)
> +#endif
>
> #ifndef __BYTE_ORDER
> # if defined(BYTE_ORDER) && defined(LITTLE_ENDIAN) &&
> defined(BIG_ENDIAN)
> @@ -82,4 +83,3 @@ static inline uint64_t bswap_64(uint64_t val)
> # error "Can't define htonll or ntohll!"
> #endif
>
> -#endif
>
> .
>
Yep, this was the first thing I did as well! ;-) (*late* last night)
I haven't had time today to look into fixing up the msvc build
(or a complete re-write), so I look forward
Re: What's cooking in git.git (Oct 2013, #07; Mon, 28)
On 2013-10-30 20.06, Ramsay Jones wrote:
> On 30/10/13 17:14, Torsten Bögershausen wrote:
>> On 2013-10-30 18.01, Vicent Martí wrote:
>>> On Wed, Oct 30, 2013 at 5:51 PM, Torsten Bögershausen wrote:
There is a name clash under cygwin 1.7 (1.5 is OK)
The following "first aid hot fix" works for me:
/Torsten
>>>
>>> If Cygwin declares its own bswap_64, wouldn't it be better to use it
>>> instead of overwriting it with our own?
>> Yes,
>> this will be part of a longer patch.
>> I found that some systems have something like this:
>>
>> #define htobe64(x) bswap_64(x)
>> And bswap_64 is a function, so we can not detect it by "asking"
>> #ifdef bswap_64
>> ..
>> #endif
>>
>>
>> But we can use
>> #ifdef htobe64
>> ...
>> #endif
>> and this will be part of a bigger patch.
>>
>> And, in general, we should avoid to introduce functions which may have a
>> name clash.
>> Using the git_ prefix for function names is a good practice.
>> So in order to unbrake the compilation error under cygwin 17,
>> the "hotfix" can be used.
>
> heh, my patch (given below) took a different approach, but
>
> ATB,
> Ramsay Jones
>
> -- >8 --
> Subject: [PATCH] compat/bswap.h: Fix redefinition of bswap_64 error on cygwin
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Since commit 452e0f20 ("compat: add endianness helpers", 24-10-2013)
> the cygwin build has failed like so:
>
> GIT_VERSION = 1.8.4.1.804.g1f3748b
> * new build flags
> CC credential-store.o
> In file included from git-compat-util.h:305:0,
> from cache.h:4,
> from credential-store.c:1:
> compat/bswap.h:67:24: error: redefinition of 'bswap_64'
> In file included from /usr/include/endian.h:32:0,
> from /usr/include/cygwin/types.h:21,
> from /usr/include/sys/types.h:473,
> from /usr/include/sys/unistd.h:9,
> from /usr/include/unistd.h:4,
> from git-compat-util.h:98,
> from cache.h:4,
> from credential-store.c:1:
> /usr/include/byteswap.h:31:1: note: previous definition of \
> ‘bswap_64’ was here
> Makefile:1985: recipe for target 'credential-store.o' failed
> make: *** [credential-store.o] Error 1
>
> Note that cygwin has a defintion of 'bswap_64' in the
> header file (which had already been included by git-compat-util.h).
> In order to suppress the error, ensure that the header
> is included, just like the __GNUC__/__GLIBC__ case, rather than
> attempting to define a fallback implementation.
>
> Signed-off-by: Ramsay Jones
> ---
> compat/bswap.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/compat/bswap.h b/compat/bswap.h
> index ea1a9ed..b864abd 100644
> --- a/compat/bswap.h
> +++ b/compat/bswap.h
> @@ -61,7 +61,7 @@ static inline uint32_t git_bswap32(uint32_t x)
> # define ntohll(n) (n)
> # define htonll(n) (n)
> #elif __BYTE_ORDER == __LITTLE_ENDIAN
> -#if defined(__GNUC__) && defined(__GLIBC__)
> +#if defined(__GNUC__) && (defined(__GLIBC__) || defined(__CYGWIN__))
> #include
> #else /* GNUC & GLIBC */
> static inline uint64_t bswap_64(uint64_t val)
>
Nice, much better.
And here comes a patch for a big endian machine.
I tryied to copy-paste a patch in my mail program,
not sure if this applies.
-- >8 --
Subject: [PATCH] compat/bswap.h: htonll and ntohll for big endian
Since commit 452e0f20 ("compat: add endianness helpers", 24-10-2013)
the build on a Linux/ppc gave a warning like this:
CC ewah/ewah_io.o
ewah/ewah_io.c: In function ‘ewah_serialize_to’:
ewah/ewah_io.c:81: warning: implicit declaration of function ‘htonll’
ewah/ewah_io.c: In function ‘ewah_read_mmap’:
ewah/ewah_io.c:132: warning: implicit declaration of function ‘ntohll’
Fix it by placing the #endif for "#ifdef bswap32" at the right place.
Signed-off-by: Torsten Bögershausen
---
compat/bswap.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/bswap.h b/compat/bswap.h
index ea1a9ed..b4ddab0
--- a/compat/bswap.h
+++ b/compat/bswap.h
@@ -46,6 +46,7 @@ static inline uint32_t git_bswap32(uint32_t x)
#undef htonl
#define ntohl(x) bswap32(x)
#define htonl(x) bswap32(x)
+#endif
#ifndef __BYTE_ORDER
# if defined(BYTE_ORDER) && defined(LITTLE_ENDIAN) && defined(BIG_ENDIAN)
@@ -82,4 +83,3 @@ static inline uint64_t bswap_64(uint64_t val)
# error "Can't define htonll or ntohll!"
#endif
-#endif
--
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 (Oct 2013, #07; Mon, 28)
On 30/10/13 17:39, Torsten Bögershausen wrote:
> On 2013-10-30 18.14, Torsten Bögershausen wrote:
>> On 2013-10-30 18.01, Vicent Martí wrote:
>>> On Wed, Oct 30, 2013 at 5:51 PM, Torsten Bögershausen wrote:
There is a name clash under cygwin 1.7 (1.5 is OK)
The following "first aid hot fix" works for me:
/Torsten
>>>
>>> If Cygwin declares its own bswap_64, wouldn't it be better to use it
>>> instead of overwriting it with our own?
>> Yes,
>> this will be part of a longer patch.
>> I found that some systems have something like this:
>>
>> #define htobe64(x) bswap_64(x)
>> And bswap_64 is a function, so we can not detect it by "asking"
>> #ifdef bswap_64
>> ..
>> #endif
>>
>>
>> But we can use
>> #ifdef htobe64
>> ...
>> #endif
>> and this will be part of a bigger patch.
>>
>> And, in general, we should avoid to introduce functions which may have a
>> name clash.
>> Using the git_ prefix for function names is a good practice.
>> So in order to unbrake the compilation error under cygwin 17,
>> the "hotfix" can be used.
>> /Torsten
> I just realized that there seem to problems to compile pu under msysgit.
> More investigation needed here.
... I noticed this too, and my patch is given below (I have another
patch for mingw which fixes some printf format warnings too) ...
However, you would not be surprised to hear that this breaks on msvc
too, so I too was planning a larger re-write ... :-D
ATB,
Ramsay Jones
-- >8 --
Subject: [PATCH] compat/bswap.h: Fix failure to determine endianness on MinGW
Since commit 452e0f20 ("compat: add endianness helpers", 24-10-2013)
added the 'ntohll' and 'htonll' helpers, the MinGW build has failed
like so:
GIT_VERSION = 1.8.4.1.804.g1f3748b
* new build flags
CC credential-store.o
In file included from git-compat-util.h:305,
from cache.h:4,
from credential-store.c:1:
compat/bswap.h:56:4: error: #error "Cannot determine endianness"
make: *** [credential-store.o] Error 1
The #error is triggered because the 'endian macros' BYTE_ORDER,
LITTLE_ENDIAN and BIG_ENDIAN not being defined. On MinGW, these macros
are defined in the header file. In order to suppress the
error, set the build variable NEEDS_SYS_PARAM_H, which will cause the
"git-compat-util.h" header file to include .
Signed-off-by: Ramsay Jones
---
config.mak.uname | 1 +
1 file changed, 1 insertion(+)
diff --git a/config.mak.uname b/config.mak.uname
index 82d549e..c03ea1e 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -469,6 +469,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
pathsep = ;
NO_PREAD = YesPlease
NEEDS_CRYPTO_WITH_SSL = YesPlease
+ NEEDS_SYS_PARAM_H = YesPlease
NO_LIBGEN_H = YesPlease
NO_POLL = YesPlease
NO_SYMLINK_HEAD = YesPlease
--
1.8.4
--
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 (Oct 2013, #07; Mon, 28)
On 30/10/13 17:14, Torsten Bögershausen wrote:
> On 2013-10-30 18.01, Vicent Martí wrote:
>> On Wed, Oct 30, 2013 at 5:51 PM, Torsten Bögershausen wrote:
>>> There is a name clash under cygwin 1.7 (1.5 is OK)
>>> The following "first aid hot fix" works for me:
>>> /Torsten
>>
>> If Cygwin declares its own bswap_64, wouldn't it be better to use it
>> instead of overwriting it with our own?
> Yes,
> this will be part of a longer patch.
> I found that some systems have something like this:
>
> #define htobe64(x) bswap_64(x)
> And bswap_64 is a function, so we can not detect it by "asking"
> #ifdef bswap_64
> ..
> #endif
>
>
> But we can use
> #ifdef htobe64
> ...
> #endif
> and this will be part of a bigger patch.
>
> And, in general, we should avoid to introduce functions which may have a
> name clash.
> Using the git_ prefix for function names is a good practice.
> So in order to unbrake the compilation error under cygwin 17,
> the "hotfix" can be used.
heh, my patch (given below) took a different approach, but
ATB,
Ramsay Jones
-- >8 --
Subject: [PATCH] compat/bswap.h: Fix redefinition of bswap_64 error on cygwin
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Since commit 452e0f20 ("compat: add endianness helpers", 24-10-2013)
the cygwin build has failed like so:
GIT_VERSION = 1.8.4.1.804.g1f3748b
* new build flags
CC credential-store.o
In file included from git-compat-util.h:305:0,
from cache.h:4,
from credential-store.c:1:
compat/bswap.h:67:24: error: redefinition of 'bswap_64'
In file included from /usr/include/endian.h:32:0,
from /usr/include/cygwin/types.h:21,
from /usr/include/sys/types.h:473,
from /usr/include/sys/unistd.h:9,
from /usr/include/unistd.h:4,
from git-compat-util.h:98,
from cache.h:4,
from credential-store.c:1:
/usr/include/byteswap.h:31:1: note: previous definition of \
‘bswap_64’ was here
Makefile:1985: recipe for target 'credential-store.o' failed
make: *** [credential-store.o] Error 1
Note that cygwin has a defintion of 'bswap_64' in the
header file (which had already been included by git-compat-util.h).
In order to suppress the error, ensure that the header
is included, just like the __GNUC__/__GLIBC__ case, rather than
attempting to define a fallback implementation.
Signed-off-by: Ramsay Jones
---
compat/bswap.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/bswap.h b/compat/bswap.h
index ea1a9ed..b864abd 100644
--- a/compat/bswap.h
+++ b/compat/bswap.h
@@ -61,7 +61,7 @@ static inline uint32_t git_bswap32(uint32_t x)
# define ntohll(n) (n)
# define htonll(n) (n)
#elif __BYTE_ORDER == __LITTLE_ENDIAN
-# if defined(__GNUC__) && defined(__GLIBC__)
+# if defined(__GNUC__) && (defined(__GLIBC__) || defined(__CYGWIN__))
# include
# else /* GNUC & GLIBC */
static inline uint64_t bswap_64(uint64_t val)
--
1.8.4
--
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 (Oct 2013, #07; Mon, 28)
On 2013-10-30 18.14, Torsten Bögershausen wrote: > On 2013-10-30 18.01, Vicent Martí wrote: >> On Wed, Oct 30, 2013 at 5:51 PM, Torsten Bögershausen wrote: >>> There is a name clash under cygwin 1.7 (1.5 is OK) >>> The following "first aid hot fix" works for me: >>> /Torsten >> >> If Cygwin declares its own bswap_64, wouldn't it be better to use it >> instead of overwriting it with our own? > Yes, > this will be part of a longer patch. > I found that some systems have something like this: > > #define htobe64(x) bswap_64(x) > And bswap_64 is a function, so we can not detect it by "asking" > #ifdef bswap_64 > .. > #endif > > > But we can use > #ifdef htobe64 > ... > #endif > and this will be part of a bigger patch. > > And, in general, we should avoid to introduce functions which may have a > name clash. > Using the git_ prefix for function names is a good practice. > So in order to unbrake the compilation error under cygwin 17, > the "hotfix" can be used. > /Torsten I just realized that there seem to problems to compile pu under msysgit. More investigation needed here. -- 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 (Oct 2013, #07; Mon, 28)
On 2013-10-30 18.01, Vicent Martí wrote: > On Wed, Oct 30, 2013 at 5:51 PM, Torsten Bögershausen wrote: >> There is a name clash under cygwin 1.7 (1.5 is OK) >> The following "first aid hot fix" works for me: >> /Torsten > > If Cygwin declares its own bswap_64, wouldn't it be better to use it > instead of overwriting it with our own? Yes, this will be part of a longer patch. I found that some systems have something like this: #define htobe64(x) bswap_64(x) And bswap_64 is a function, so we can not detect it by "asking" #ifdef bswap_64 .. #endif But we can use #ifdef htobe64 ... #endif and this will be part of a bigger patch. And, in general, we should avoid to introduce functions which may have a name clash. Using the git_ prefix for function names is a good practice. So in order to unbrake the compilation error under cygwin 17, the "hotfix" can be used. /Torsten -- 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 (Oct 2013, #07; Mon, 28)
On Wed, Oct 30, 2013 at 5:51 PM, Torsten Bögershausen wrote: > There is a name clash under cygwin 1.7 (1.5 is OK) > The following "first aid hot fix" works for me: > /Torsten If Cygwin declares its own bswap_64, wouldn't it be better to use it instead of overwriting it with our own? -- 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 (Oct 2013, #07; Mon, 28)
On 2013-10-28 20.28, Junio C Hamano wrote:
> * jk/pack-bitmap (2013-10-28) 20 commits
There is a name clash under cygwin 1.7 (1.5 is OK)
The following "first aid hot fix" works for me:
/Torsten
$ git diff
diff --git a/compat/bswap.h b/compat/bswap.h
index ea1a9ed..8dc39be 100644
--- a/compat/bswap.h
+++ b/compat/bswap.h
@@ -64,7 +64,7 @@ static inline uint32_t git_bswap32(uint32_t x)
# if defined(__GNUC__) && defined(__GLIBC__)
# include
# else /* GNUC & GLIBC */
-static inline uint64_t bswap_64(uint64_t val)
+static inline uint64_t git_bswap_64(uint64_t val)
{
return ((val & (uint64_t)0x00ffULL) << 56)
| ((val & (uint64_t)0xff00ULL) << 40)
@@ -76,8 +76,8 @@ static inline uint64_t bswap_64(uint64_t val)
| ((val & (uint64_t)0xff00ULL) >> 56);
}
# endif /* GNUC & GLIBC */
-# define ntohll(n) bswap_64(n)
-# define htonll(n) bswap_64(n)
+# define ntohll(n) git_bswap_64(n)
+# define htonll(n) git_bswap_64(n)
#else /* __BYTE_ORDER */
# error "Can't define htonll or ntohll!"
#endif
--
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 (Oct 2013, #07; Mon, 28)
Hi Karsten Junio C Hamano writes: > * kb/fast-hashmap (2013-10-22) 12 commits > - remove old hash.[ch] implementation > - read-cache.c: fix memory leaks caused by removed cache entries I found more valgrind breakage related to this commit, in t2101.[3567] (sorry for only reporting them so late, I probably missed them in the last run). E.g. I get this: $ ./t2101-update-index-reupdate.sh --valgrind-only=3 ok 1 - update-index --add ok 2 - update-index --again expecting success: git update-index --remove --again && git ls-files -s >current && cmp current expected ==21665== Invalid read of size 1 ==21665==at 0x4C2C762: __GI_strlen (mc_replace_strmem.c:405) ==21665==by 0x484B0E: update_one (update-index.c:305) ==21665==by 0x485466: do_reupdate (update-index.c:582) ==21665==by 0x4858FB: reupdate_callback (update-index.c:696) ==21665==by 0x4EB5E7: get_value (parse-options.c:96) ==21665==by 0x4EBEC5: parse_long_opt (parse-options.c:302) ==21665==by 0x4EC5CD: parse_options_step (parse-options.c:474) ==21665==by 0x486115: cmd_update_index (update-index.c:824) ==21665==by 0x405999: run_builtin (git.c:314) ==21665==by 0x405B2C: handle_internal_command (git.c:477) ==21665==by 0x405C46: run_argv (git.c:523) ==21665==by 0x405DE2: main (git.c:606) ==21665== Address 0x5bee774 is 84 bytes inside a block of size 90 free'd ==21665==at 0x4C2ACDA: free (vg_replace_malloc.c:468) ==21665==by 0x4F9360: remove_index_entry_at (read-cache.c:482) ==21665==by 0x4F9536: remove_file_from_index (read-cache.c:522) ==21665==by 0x4841DF: remove_one_path (update-index.c:68) ==21665==by 0x48422E: process_lstat_error (update-index.c:83) ==21665==by 0x4846BB: process_path (update-index.c:211) ==21665==by 0x484AC2: update_one (update-index.c:301) ==21665==by 0x485466: do_reupdate (update-index.c:582) ==21665==by 0x4858FB: reupdate_callback (update-index.c:696) ==21665==by 0x4EB5E7: get_value (parse-options.c:96) ==21665==by 0x4EBEC5: parse_long_opt (parse-options.c:302) ==21665==by 0x4EC5CD: parse_options_step (parse-options.c:474) [...] not ok 3 - update-index --remove --again # git update-index --remove --again && #git ls-files -s >current && #cmp current expected ok 4 - first commit ok 5 - update-index again ok 6 - update-index --update from subdir ok 7 - update-index --update with pathspec # failed 1 among 7 test(s) 1..7 The errors for tests 5-7 look like they're the same piece of code breaking. -- Thomas Rast t...@thomasrast.ch -- 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
What's cooking in git.git (Oct 2013, #07; Mon, 28)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. It is already 10th week of this cycle, but somehow I completely forgot where in the cycle we were. Sorry about that. I'll tag 1.8.5-rc0 in a few days by the end of this month, and then hopefully we will have two to three -rc weeks after that, aiming for the final 1.8.5 release sometime late November (tentative schedule at http://tinyurl.com/gitCal). As promised/requested, the final steps for 2.0 are in 'next'; they, together with a handful topics that have been merged to 'next' fairly recently, will _not_ be part of the upcoming 1.8.5 release, but will be carried over in 'next' to the next cycle. Also there is 1.8.4.2 maintenance release out. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [Graduated to "master"] * ew/keepalive (2013-10-16) 2 commits (merged to 'next' on 2013-10-16 at 56fd9f3) + http: use curl's tcp keepalive if available (merged to 'next' on 2013-10-14 at 24d786f) + http: enable keepalive on TCP sockets The HTTP transport will try to use TCP keepalive when able. * jc/revision-range-unpeel (2013-10-15) 1 commit (merged to 'next' on 2013-10-16 at d04ddfe) + revision: do not peel tags used in range notation "git rev-list --objects ^v1.0^ v1.0" gave v1.0 tag itself in the output, but "git rev-list --objects v1.0^..v1.0" did not. * jk/remote-literal-string-leakfix (2013-10-15) 1 commit (merged to 'next' on 2013-10-18 at 6abddac) + remote: do not copy "origin" string literal * jk/split-broken-ident (2013-10-15) 1 commit (merged to 'next' on 2013-10-18 at 8f4b8b7) + split_ident: parse timestamp from end of line Make the fall-back parsing of commit objects with broken author or committer lines more robust to pick up the timestamps. * jx/relative-path-regression-fix (2013-10-14) 3 commits (merged to 'next' on 2013-10-18 at b4af45f) + Use simpler relative_path when set_git_dir (merged to 'next' on 2013-10-14 at 704b9ee) + relative_path should honor dos-drive-prefix + test: use unambigous leading path (/foo) for MSYS Will merge to 'master' and later to 'maint'. * sb/repack-in-c (2013-10-22) 1 commit (merged to 'next' on 2013-10-23 at 5d7ac72) + Reword repack documentation to no longer state it's a script Finishing touches to update documentation. * sg/prompt-svn-remote-fix (2013-10-15) 1 commit (merged to 'next' on 2013-10-18 at 20b47eb) + bash prompt: don't use '+=' operator in show upstream code path Bash portability fix. -- [New Topics] * bw/solaris-sed-tr-test-portability (2013-10-28) 2 commits - Avoid difference in tr semantics between System V and BSD - Change sed i\ usage to something Solaris' sed can handle Needs a bit of reroll. * fc/transport-helper-fixes (2013-10-28) 13 commits - test: remote-helper: add test for force pushes - git-remote-testgit: support the new 'force' option - fixup! transport-helper: add 'force' to 'export' helpers - transport-helper: don't update refs in dry-run - transport-helper: add support to delete branches - fast-export: add support to delete refs - fast-import: add support to delete refs - transport-helper: add support for old:new refspec - fast-export: add new --refspec option - fast-export: improve argument parsing - transport-helper: check for 'forced update' message - transport-helper: fix extra lines - transport-helper: add 'force' to 'export' helpers * jh/loose-object-dirs-creation-race (2013-10-28) 1 commit - sha1_file.c:create_tmpfile(): Fix race when creating loose object dirs * js/test-help-format-windows-port-fix (2013-10-28) 1 commit - PATCH] t3200: do not open a HTML manual page when DEFAULT_MAN_FORMAT is html Will merge to 'next' after amending the title. * js/tests-windows-port-fix (2013-10-28) 3 commits - tests: undo special treatment of CRLF for Windows - Windows: a test_cmp that is agnostic to random LF <> CRLF conversions - t5300-pack-object: do not compare binary data using test_cmp Will merge to 'next'. * nd/liteal-pathspecs (2013-10-28) 1 commit - pathspec: stop --*-pathspecs impact on internal parse_pathspec() uses * rs/web-browse-xdg-open (2013-10-28) 1 commit - web--browse: Add support for xdg-open. Will merge to 'next'. * sb/refs-code-cleanup (2013-10-28) 2 commits - cache: remove unused function 'have_git_dir' - refs: remove unused function invalidate_ref_cache Will merge to 'next'. * th/reflog-annotated-tag (2013-10-28) 1 commit - reflog: handle lightweight and annotated tags equally -- [Stalled] * np/pack-v4 (2013-09-18) 90 commits . packv4-parse.c: add tree offset caching . t1050: replace one instance of
