Re: [msysGit] [PATCH 12/14] Fix pointer - integer casts on IL32P64 systems
On Mon, Sep 29, 2014 at 10:43:41PM +0200, Johannes Sixt wrote: Am 28.09.2014 um 15:24 schrieb Marat Radchenko: This commit touches regcomp.c and poll.c from Gnulib, both were fixed upstream in 2012 the same way. Wrt ShellExecute, see [1]. [1]: http://blogs.msdn.com/b/oldnewthing/archive/2006/11/08/1035971.aspx Please do not force readers to visit a web site; provide at least a summary. No problem, will expand commit message. This breaks with In file included from compat/regex/regex.c:77: compat/regex/regcomp.c: In function 'parse_dup_op': compat/regex/regcomp.c:2580: error: 'intptr_t' undeclared (first use in this function) when compiled using the msysgit environment. Aargh! No idea how this slipped through. Will reroll. -- 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] MinGW(-W64) compilation
This patch series fixes building on modern MinGW and MinGW-W64 (including x86_64!). *Compilation* tested on: - MSVC - msysGit environment (twice) - Linux cross-toolchain i686-pc-mingw32 - Linux cross-toolchain i686-w64-mingw32 - Linux cross-toolchain x86_64-w64-mingw32 Attention: in order to build on MinGW-W64, you need to use 'v1.x', 'v2.x' or 'sf/v3.x' branches from MinGW-W64 repo because MinGW-W64 releases do not yet have a fix for https://sourceforge.net/p/mingw-w64/bugs/397 -- 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 09/14] MINGW: config.mak.uname: reorganize MinGW settings
HAVE_LIBCHARSET_H and NO_R_TO_GCC_LINKER are not specific to msysGit, they're general MinGW settings. Logic behind HAVE_LIBCHARSET_H: if user is on MinGW and has iconv, we expect him to have libcharset.h. If user doesn't have iconv, he has to explicitly say so via NO_ICONV=1 regardless of this commit. Signed-off-by: Marat Radchenko ma...@slonopotamus.org --- config.mak.uname | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/config.mak.uname b/config.mak.uname index c7aaa1c..f79c0e0 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -532,11 +532,11 @@ ifneq (,$(wildcard ../THIS_IS_MSYSGIT)) prefix = INSTALL = /bin/install EXTLIBS += /mingw/lib/libz.a - NO_R_TO_GCC_LINKER = YesPlease INTERNAL_QSORT = YesPlease - HAVE_LIBCHARSET_H = YesPlease NO_GETTEXT = YesPlease endif + HAVE_LIBCHARSET_H = YesPlease + NO_R_TO_GCC_LINKER = YesPlease endif ifeq ($(uname_S),QNX) COMPAT_CFLAGS += -DSA_RESTART=0 -- 2.1.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
[PATCH 01/14] MINGW: compat/mingw.h: do not attempt to redefine lseek on mingw-w64
Unlike MinGW, MinGW-W64 has lseek already properly defined in io.h. Signed-off-by: Marat Radchenko ma...@slonopotamus.org Acked-by: Eric Faye-Lund kusmab...@gmail.com --- compat/mingw.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/compat/mingw.h b/compat/mingw.h index df0e320..ed79368 100644 --- a/compat/mingw.h +++ b/compat/mingw.h @@ -281,7 +281,9 @@ static inline int getrlimit(int resource, struct rlimit *rlp) * Use mingw specific stat()/lstat()/fstat() implementations on Windows. */ #define off_t off64_t +#ifndef lseek #define lseek _lseeki64 +#endif /* use struct stat with 64 bit st_size */ #ifdef stat -- 2.1.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
[PATCH 05/14] MINGW: config.mak.uname: allow using cURL for non-msysGit builds
Is it absolutely valid and possible to have cURL in generic MinGW environment. Building Git without cURL is still possible by passing NO_CURL=1 Signed-off-by: Marat Radchenko ma...@slonopotamus.org Acked-by: Eric Faye-Lund kusmab...@gmail.com --- config.mak.uname | 2 -- 1 file changed, 2 deletions(-) diff --git a/config.mak.uname b/config.mak.uname index 20cbdcf..324a7fc 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -531,8 +531,6 @@ ifneq (,$(wildcard ../THIS_IS_MSYSGIT)) INTERNAL_QSORT = YesPlease HAVE_LIBCHARSET_H = YesPlease NO_GETTEXT = YesPlease -else - NO_CURL = YesPlease endif endif ifeq ($(uname_S),QNX) -- 2.1.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
[PATCH 06/14] MINGW: compat/winansi.c: do not redefine CONSOLE_FONT_INFOEX
Unlike MinGW, MinGW-W64 has CONSOLE_FONT_INFOEX already properly defined
in wincon.h.
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
compat/winansi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/winansi.c b/compat/winansi.c
index efc5bb3..0ac3297 100644
--- a/compat/winansi.c
+++ b/compat/winansi.c
@@ -22,7 +22,7 @@ static int non_ascii_used = 0;
static HANDLE hthread, hread, hwrite;
static HANDLE hconsole1, hconsole2;
-#ifdef __MINGW32__
+#if defined(__MINGW32__) !defined(__MINGW64_VERSION_MAJOR)
typedef struct _CONSOLE_FONT_INFOEX {
ULONG cbSize;
DWORD nFont;
--
2.1.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
[PATCH 03/14] MINGW: compat/mingw.h: drop fork() definition
fork() is not used in MinGW builds but causes a compiler warning
on x86_64 MinGW-W64: conflicting types for built-in function 'fork'
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
Acked-by: Eric Faye-Lund kusmab...@gmail.com
---
compat/mingw.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index ed79368..948a174 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -93,8 +93,6 @@ static inline int symlink(const char *oldpath, const char
*newpath)
{ errno = ENOSYS; return -1; }
static inline int fchmod(int fildes, mode_t mode)
{ errno = ENOSYS; return -1; }
-static inline pid_t fork(void)
-{ errno = ENOSYS; return -1; }
static inline unsigned int alarm(unsigned int seconds)
{ return 0; }
static inline int fsync(int fd)
--
2.1.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
[PATCH 07/14] Fix BASIC_LDFLAGS and COMPAT_CFLAGS for 64bit MinGW-w64
From: Ray Donnelly mingw.andr...@gmail.com Signed-off-by: Ray Donnelly mingw.andr...@gmail.com Signed-off-by: Marat Radchenko ma...@slonopotamus.org --- config.mak.uname | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/config.mak.uname b/config.mak.uname index 324a7fc..4470a928 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -6,6 +6,7 @@ uname_O := $(shell sh -c 'uname -o 2/dev/null || echo not') uname_R := $(shell sh -c 'uname -r 2/dev/null || echo not') uname_P := $(shell sh -c 'uname -p 2/dev/null || echo not') uname_V := $(shell sh -c 'uname -v 2/dev/null || echo not') +CC_MACH := $(shell sh -c '$(CC) -dumpmachine 2/dev/null || echo not') ifdef MSVC # avoid the MingW and Cygwin configuration sections @@ -509,12 +510,15 @@ ifneq (,$(findstring MINGW,$(uname_S))) NO_POSIX_GOODIES = UnfortunatelyYes DEFAULT_HELP_FORMAT = html NO_D_INO_IN_DIRENT = YesPlease - COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -D_USE_32BIT_TIME_T -DNOGDI -Icompat -Icompat/win32 + COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -DNOGDI -Icompat -Icompat/win32 + ifneq (,$(findstring i686,$(CC_MACH))) + COMPAT_CFLAGS += -D_USE_32BIT_TIME_T + BASIC_LDFLAGS += -Wl,--large-address-aware + endif COMPAT_CFLAGS += -DSTRIP_EXTENSION=\.exe\ COMPAT_OBJS += compat/mingw.o compat/winansi.o \ compat/win32/pthread.o compat/win32/syslog.o \ compat/win32/dirent.o - BASIC_LDFLAGS += -Wl,--large-address-aware EXTLIBS += -lws2_32 GITLIBS += git.res PTHREAD_LIBS = -- 2.1.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
[PATCH 08/14] MINGW: git-compat-util.h: use inttypes.h for printf macros
All MinGW flavors have inttypes.h, so just include it.
However, we need to pass -D__USE_MINGW_ANSI_STDIO=1 to select
GNU-compatible macro definitions on MinGW-W64:
http://sourceforge.net/p/mingw-w64/wiki2/gnu%20printf/
As a side-effect, Git no longer builds with MSVC 2010 due to
its lack of stdint.h but hopefully that is not a problem.
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
compat/mingw.h| 2 --
compat/msvc.h | 3 +++
config.mak.uname | 3 ++-
git-compat-util.h | 11 ++-
4 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index d113b19..4bae842 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -353,8 +353,6 @@ static inline char *mingw_find_last_dir_sep(const char
*path)
int mingw_offset_1st_component(const char *path);
#define offset_1st_component mingw_offset_1st_component
#define PATH_SEP ';'
-#define PRIuMAX I64u
-#define PRId64 I64d
void mingw_open_html(const char *path);
#define open_html mingw_open_html
diff --git a/compat/msvc.h b/compat/msvc.h
index a63d878..84a03f9 100644
--- a/compat/msvc.h
+++ b/compat/msvc.h
@@ -17,6 +17,9 @@
typedef int pid_t;
+#define PRIuMAX I64u
+#define PRId64 I64d
+
static __inline int strcasecmp (const char *s1, const char *s2)
{
int size1 = strlen(s1);
diff --git a/config.mak.uname b/config.mak.uname
index 4470a928..c7aaa1c 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -328,6 +328,7 @@ ifeq ($(uname_S),Windows)
NO_PREAD = YesPlease
NEEDS_CRYPTO_WITH_SSL = YesPlease
NO_LIBGEN_H = YesPlease
+ NO_INTTYPES_H = UnfortunatelyYes
NO_POLL = YesPlease
NO_SYMLINK_HEAD = YesPlease
NO_IPV6 = YesPlease
@@ -510,7 +511,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
NO_POSIX_GOODIES = UnfortunatelyYes
DEFAULT_HELP_FORMAT = html
NO_D_INO_IN_DIRENT = YesPlease
- COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -DNOGDI -Icompat -Icompat/win32
+ COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -D__USE_MINGW_ANSI_STDIO=1
-DNOGDI -Icompat -Icompat/win32
ifneq (,$(findstring i686,$(CC_MACH)))
COMPAT_CFLAGS += -D_USE_32BIT_TIME_T
BASIC_LDFLAGS += -Wl,--large-address-aware
diff --git a/git-compat-util.h b/git-compat-util.h
index 0c4e663..9d2d5ab 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -96,6 +96,12 @@
#define GIT_WINDOWS_NATIVE
#endif
+#ifndef NO_INTTYPES_H
+#include inttypes.h
+#else
+#include stdint.h
+#endif
+
#include unistd.h
#include stdio.h
#include sys/stat.h
@@ -147,11 +153,6 @@
#include netdb.h
#include pwd.h
#include sys/un.h
-#ifndef NO_INTTYPES_H
-#include inttypes.h
-#else
-#include stdint.h
-#endif
#ifdef NO_INTPTR_T
/*
* On I16LP32, ILP32 and LP64 long is the save bet, however
--
2.1.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
[PATCH 04/14] MINGW: do not fail at redefining pid_t on MinGW-W64
pid_t is available in sys/types.h on both MinGW and MinGW-W64
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
Acked-by: Eric Faye-Lund kusmab...@gmail.com
---
compat/mingw.h | 1 -
compat/msvc.h | 2 ++
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index 948a174..d113b19 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -5,7 +5,6 @@
* things that are not available in header files
*/
-typedef int pid_t;
typedef int uid_t;
typedef int socklen_t;
#define hstrerror strerror
diff --git a/compat/msvc.h b/compat/msvc.h
index 580bb55..a63d878 100644
--- a/compat/msvc.h
+++ b/compat/msvc.h
@@ -15,6 +15,8 @@
#define strtoull _strtoui64
#define strtoll _strtoi64
+typedef int pid_t;
+
static __inline int strcasecmp (const char *s1, const char *s2)
{
int size1 = strlen(s1);
--
2.1.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
[PATCH 02/14] MSVC: config.mak.uname: drop -D__USE_MINGW_ACCESS from CFLAGS
-D__USE_MINGW_ACCESS only affects MinGW and does nothing when MSVC is used. Signed-off-by: Marat Radchenko ma...@slonopotamus.org Acked-by: Eric Faye-Lund kusmab...@gmail.com --- config.mak.uname | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config.mak.uname b/config.mak.uname index a2f380f..20cbdcf 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -368,7 +368,7 @@ ifeq ($(uname_S),Windows) COMPAT_OBJS = compat/msvc.o compat/winansi.o \ compat/win32/pthread.o compat/win32/syslog.o \ compat/win32/dirent.o - COMPAT_CFLAGS = -D__USE_MINGW_ACCESS -DNOGDI -DHAVE_STRING_H -Icompat -Icompat/regex -Icompat/win32 -DSTRIP_EXTENSION=\.exe\ + COMPAT_CFLAGS = -DNOGDI -DHAVE_STRING_H -Icompat -Icompat/regex -Icompat/win32 -DSTRIP_EXTENSION=\.exe\ BASIC_LDFLAGS = -IGNORE:4217 -IGNORE:4049 -NOLOGO -SUBSYSTEM:CONSOLE EXTLIBS = user32.lib advapi32.lib shell32.lib wininet.lib ws2_32.lib invalidcontinue.obj PTHREAD_LIBS = -- 2.1.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
[PATCH 12/14] Fix pointer - integer casts on IL32P64 systems
This commit touches regcomp.c and poll.c from Gnulib,
both were fixed upstream in 2012 the same way.
Also, this commit touches regex_internal.h from Gnulib,
which was fixed upstream in 2005.
Wrt ShellExecute in winansi.c, quoting [1]:
MSDN says you can cast the result to an integer and compare the result
against 32... You could cast in the other direction, comparing the return
value against (HINSTANCE)32... Or you could cast the result to an INT_PTR
and compare the result against 32.
We use the third option: cast HINSTANCE to intptr_t.
[1]: http://blogs.msdn.com/b/oldnewthing/archive/2006/11/08/1035971.aspx
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
compat/mingw.c| 8
compat/poll/poll.c| 2 +-
compat/regex/regcomp.c| 4 ++--
compat/regex/regex_internal.h | 1 +
compat/win32/pthread.h| 2 +-
compat/winansi.c | 2 +-
pack-revindex.c | 2 +-
sha1_file.c | 8
8 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index c5c37e5..27925d9 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -674,13 +674,13 @@ int pipe(int filedes[2])
errno = err_win_to_posix(GetLastError());
return -1;
}
- filedes[0] = _open_osfhandle((int)h[0], O_NOINHERIT);
+ filedes[0] = _open_osfhandle((intptr_t)h[0], O_NOINHERIT);
if (filedes[0] 0) {
CloseHandle(h[0]);
CloseHandle(h[1]);
return -1;
}
- filedes[1] = _open_osfhandle((int)h[1], O_NOINHERIT);
+ filedes[1] = _open_osfhandle((intptr_t)h[1], O_NOINHERIT);
if (filedes[0] 0) {
close(filedes[0]);
CloseHandle(h[1]);
@@ -1819,7 +1819,7 @@ void mingw_open_html(const char *unixpath)
const char *, const char *, const char *, INT);
T ShellExecute;
HMODULE shell32;
- int r;
+ intptr_t r;
shell32 = LoadLibrary(shell32.dll);
if (!shell32)
@@ -1829,7 +1829,7 @@ void mingw_open_html(const char *unixpath)
die(cannot run browser);
printf(Launching default browser to display HTML ...\n);
- r = (int)ShellExecute(NULL, open, htmlpath, NULL, \\,
SW_SHOWNORMAL);
+ r = (intptr_t)ShellExecute(NULL, open, htmlpath, NULL, \\,
SW_SHOWNORMAL);
FreeLibrary(shell32);
/* see the MSDN documentation referring to the result codes here */
if (r = 32) {
diff --git a/compat/poll/poll.c b/compat/poll/poll.c
index a9b41d8..8941249 100644
--- a/compat/poll/poll.c
+++ b/compat/poll/poll.c
@@ -76,7 +76,7 @@
#ifdef WIN32_NATIVE
-#define IsConsoleHandle(h) (((long) (h) 3) == 3)
+#define IsConsoleHandle(h) (((intptr_t) (h) 3) == 3)
static BOOL
IsSocketHandle (HANDLE h)
diff --git a/compat/regex/regcomp.c b/compat/regex/regcomp.c
index 06f3088..d8bde06 100644
--- a/compat/regex/regcomp.c
+++ b/compat/regex/regcomp.c
@@ -2577,7 +2577,7 @@ parse_dup_op (bin_tree_t *elem, re_string_t *regexp,
re_dfa_t *dfa,
old_tree = NULL;
if (elem-token.type == SUBEXP)
-postorder (elem, mark_opt_subexp, (void *) (long) elem-token.opr.idx);
+postorder (elem, mark_opt_subexp, (void *) (intptr_t) elem-token.opr.idx);
tree = create_tree (dfa, elem, NULL, (end == -1 ? OP_DUP_ASTERISK : OP_ALT));
if (BE (tree == NULL, 0))
@@ -3806,7 +3806,7 @@ create_token_tree (re_dfa_t *dfa, bin_tree_t *left,
bin_tree_t *right,
static reg_errcode_t
mark_opt_subexp (void *extra, bin_tree_t *node)
{
- int idx = (int) (long) extra;
+ int idx = (int) (intptr_t) extra;
if (node-token.type == SUBEXP node-token.opr.idx == idx)
node-token.opt_subexp = 1;
diff --git a/compat/regex/regex_internal.h b/compat/regex/regex_internal.h
index 4184d7f..da12670 100644
--- a/compat/regex/regex_internal.h
+++ b/compat/regex/regex_internal.h
@@ -26,6 +26,7 @@
#include stdio.h
#include stdlib.h
#include string.h
+#include stdint.h
#if defined HAVE_LANGINFO_H || defined HAVE_LANGINFO_CODESET || defined _LIBC
# include langinfo.h
diff --git a/compat/win32/pthread.h b/compat/win32/pthread.h
index 8ad1873..6ccfb7b 100644
--- a/compat/win32/pthread.h
+++ b/compat/win32/pthread.h
@@ -77,7 +77,7 @@ extern pthread_t pthread_self(void);
static inline int pthread_exit(void *ret)
{
- ExitThread((DWORD)ret);
+ ExitThread((DWORD)(uintptr_t)ret);
}
typedef DWORD pthread_key_t;
diff --git a/compat/winansi.c b/compat/winansi.c
index 0ac3297..ca4c295 100644
--- a/compat/winansi.c
+++ b/compat/winansi.c
@@ -452,7 +452,7 @@ static HANDLE duplicate_handle(HANDLE hnd)
HANDLE hresult, hproc = GetCurrentProcess();
if (!DuplicateHandle(hproc, hnd, hproc, hresult, 0, TRUE,
DUPLICATE_SAME_ACCESS))
- die_lasterr(DuplicateHandle(%li) failed, (long) hnd);
+ die_lasterr(DuplicateHandle(%p)
[PATCH 14/14] MINGW: config.mak.uname: auto-detect MinGW build from compiler
When crosscompiling, one cannot rely on `uname` from host system. Signed-off-by: Marat Radchenko ma...@slonopotamus.org --- config.mak.uname | 5 + 1 file changed, 5 insertions(+) diff --git a/config.mak.uname b/config.mak.uname index 9f7037e..182da50 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -14,6 +14,11 @@ ifdef MSVC uname_O := Windows endif +ifneq (,$(findstring mingw,$(CC_MACH))) + uname_S := MINGW + uname_O := MINGW +endif + # We choose to avoid if .. else if .. else .. endif endif # because maintaining the nesting to match is a pain. If # we had elif things would have been much nicer... -- 2.1.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
[PATCH 13/14] git-compat-util.h: fix integer overflow on IL32P64 systems
Signed-off-by: Marat Radchenko ma...@slonopotamus.org --- git-compat-util.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-compat-util.h b/git-compat-util.h index 9d2d5ab..5f6659c 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -474,7 +474,7 @@ extern int git_munmap(void *start, size_t length); #endif #define DEFAULT_PACKED_GIT_LIMIT \ - ((1024L * 1024L) * (sizeof(void*) = 8 ? 8192 : 256)) + ((size_t)(1024L * 1024L) * (sizeof(void*) = 8 ? 8192 : 256)) #ifdef NO_PREAD #define pread git_pread -- 2.1.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
[PATCH 10/14] Makefile: introduce CROSS_COMPILE variable
To ease cross-compilation process, introduce a single variable with the prefix to all compiler-related executables. Define CROSS_COMPILE=foo- if your compiler and binary utilities are foo-cc, foo-ar, foo-strip, etc. More specific variables override this, so if you set CC=gcc CROSS_COMPILE=ia64-linux-gnu- then the compiler will be 'gcc', not 'ia64-linux-gnu-gcc'. Signed-off-by: Marat Radchenko ma...@slonopotamus.org --- Makefile | 19 +-- config.mak.uname | 2 +- 2 files changed, 14 insertions(+), 7 deletions(-) diff --git a/Makefile b/Makefile index f34a2d4..c412996 100644 --- a/Makefile +++ b/Makefile @@ -339,6 +339,11 @@ all:: # return NULL when it receives a bogus time_t. # # Define HAVE_CLOCK_GETTIME if your platform has clock_gettime in librt. +# +# Define CROSS_COMPILE=foo- if your compiler and binary utilities +# are foo-cc, foo-ar, foo-strip, etc. More specific variables +# override this, so if you set CC=gcc CROSS_COMPILE=ia64-linux-gnu- +# then the compiler will be 'gcc', not 'ia64-linux-gnu-gcc'. GIT-VERSION-FILE: FORCE @$(SHELL_PATH) ./GIT-VERSION-GEN @@ -350,7 +355,6 @@ CFLAGS = -g -O2 -Wall LDFLAGS = ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS) ALL_LDFLAGS = $(LDFLAGS) -STRIP ?= strip # Among the variables below, these: # gitexecdir @@ -390,8 +394,12 @@ htmldir_relative = $(patsubst $(prefix)/%,%,$(htmldir)) export prefix bindir sharedir sysconfdir gitwebdir localedir -CC = cc -AR = ar +AR = $(CROSS_COMPILE)ar +CC = $(CROSS_COMPILE)cc +GCOV = $(CROSS_COMPILE)gcov +RC = $(CROSS_COMPILE)windres +STRIP = $(CROSS_COMPILE)strip + RM = rm -f DIFF = diff TAR = tar @@ -404,13 +412,12 @@ XGETTEXT = xgettext MSGFMT = msgfmt PTHREAD_LIBS = -lpthread PTHREAD_CFLAGS = -GCOV = gcov export TCL_PATH TCLTK_PATH SPARSE_FLAGS = - +RCFLAGS = ### --- END CONFIGURATION SECTION --- @@ -1669,7 +1676,7 @@ $(SCRIPT_LIB) : % : %.sh GIT-SCRIPT-DEFINES mv $@+ $@ git.res: git.rc GIT-VERSION-FILE - $(QUIET_RC)$(RC) \ + $(QUIET_RC)$(RC) $(RCFLAGS) \ $(join -DMAJOR= -DMINOR=, $(wordlist 1,2,$(subst -, ,$(subst ., ,$(GIT_VERSION) \ -DGIT_VERSION=\\\$(GIT_VERSION)\\\ $ -o $@ diff --git a/config.mak.uname b/config.mak.uname index f79c0e0..9f7037e 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -523,7 +523,7 @@ ifneq (,$(findstring MINGW,$(uname_S))) EXTLIBS += -lws2_32 GITLIBS += git.res PTHREAD_LIBS = - RC = windres -O coff + RCFLAGS += -O coff NATIVE_CRLF = YesPlease X = .exe SPARSE_FLAGS = -Wno-one-bit-signed-bitfield -- 2.1.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
[PATCH 11/14] compat/nedmalloc/malloc.c.h: fix compilation under MinGW-W64
1. Unlike MinGW, MinGW-W64 already provides _ReadWriteBarrier macro,
so don't try to redefine it.
2. MinGW-W64 has a strange definition FORCEINLINE as
extern __inline__ __attribute__((__always_inline__,__gnu_inline__))
'extern' doesn't work together with 'static', so #undef MinGW-W64
version of FORCEINLINE.
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
compat/nedmalloc/malloc.c.h | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/compat/nedmalloc/malloc.c.h b/compat/nedmalloc/malloc.c.h
index f216a2a..a6c8cac 100644
--- a/compat/nedmalloc/malloc.c.h
+++ b/compat/nedmalloc/malloc.c.h
@@ -715,6 +715,10 @@ struct mallinfo {
#endif /* HAVE_USR_INCLUDE_MALLOC_H */
#endif /* NO_MALLINFO */
+#ifdef __MINGW64_VERSION_MAJOR
+ #undef FORCEINLINE
+#endif
+
/*
Try to persuade compilers to inline. The most critical functions for
inlining are defined as macros, so these aren't used for them.
@@ -1382,7 +1386,9 @@ LONG __cdecl _InterlockedExchange(LONG volatile *Target,
LONG Value);
/*** Atomic operations ***/
#if (__GNUC__ * 1 + __GNUC_MINOR__ * 100 + __GNUC_PATCHLEVEL__) 40100
-#define _ReadWriteBarrier() __sync_synchronize()
+#ifndef _ReadWriteBarrier
+ #define _ReadWriteBarrier() __sync_synchronize()
+#endif
#else
static __inline__ __attribute__((always_inline)) long
__sync_lock_test_and_set(volatile long * const Target, const long Value)
{
--
2.1.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] Do not make trace.c/getnanotime an inlined function
On Tue, Sep 30, 2014 at 12:48 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
On Sun, Sep 28, 2014 at 2:50 PM, Ben Walton bdwal...@gmail.com wrote:
Oracle Studio compilers don't allow for static variables in functions
that are defined to be inline. GNU C does permit this. Let's reference
the C99 standard though, which doesn't allow for inline functions to
contain modifiable static variables.
Signed-off-by: Ben Walton bdwal...@gmail.com
---
trace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/trace.c b/trace.c
index b6f25a2..4778608 100644
--- a/trace.c
+++ b/trace.c
@@ -385,7 +385,7 @@ static inline uint64_t gettimeofday_nanos(void)
* Returns nanoseconds since the epoch (01/01/1970), for performance
tracing
* (i.e. favoring high precision over wall clock time accuracy).
*/
-inline uint64_t getnanotime(void)
+uint64_t getnanotime(void)
{
static uint64_t offset;
Would moving this offset outside getnanotime() work?
I am not sure what the definition of work is.
The function computes the difference between the returned value from
gettimeofday(2) and a custom highres_nanos() just once and returns
the value it got from gettimeofday the first time, and then for
subsequent calls massages the returned value from highres_nanos() to
be consistent with the value returned from gettimeofday using the
offset it computed in the first call.
If we have two copies of this function, two independent probes to
these pair of underlying functions will be made to compute their
offsets.
Hmm.. no. Even if the function is inlined in multiple places, inline
code still points to the same offset variable. So the
gettimeofday_nanos()/highres_nanos() pair should only be called once.
Tested with gcc.
--
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 v6 00/39] Lockfile correctness and refactoring
On 09/26/2014 06:31 PM, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: * Rebase to current master. When you say this, could you be a bit more descriptive? Has the series updated to use something new that appeared on 'master' since the last series was posted and needed to be rebased? Or did you just made sure that the series applied on top of the current master still works, even though you have been running rebase -i on the same fork point since the previous round? If the former, naming what it now uses i.e. rebased to current master, to redo PATCH x,y,z using the new X recently graduated would be helpful. If the latter, well, not rebasing is preferrable if the changes are still viable on the previous fork point, to be absolutely honest. I have always routinely rebased my series to the current master each time I reroll them. I thought that was helpful. Thanks for the info that you prefer that I not do it. In the future I will only rebase to master if I see that there would be nontrivial conflicts or if I would like to take advantage of something that has graduated. I've always tried to mention when the rebases were nontrivial. In this case it was unproblematic. As an aside, I've always found it wishy-washy to talk about current master and fork points and stuff when (AFAIK) format-patch-generated emails don't mention the fork point. So unless my cover letter specifies the fork point as an unambiguous commit name, there is no basis *anyway* to expect that you will apply the patch series in the same context that I developed it. Another victim of the format-patch information shredder :-( Cheers, Michael -- Michael Haggerty mhag...@alum.mit.edu -- 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] MinGW(-W64) compilation
On Tue, Sep 30, 2014 at 2:02 PM, Marat Radchenko ma...@slonopotamus.org wrote: This patch series fixes building on modern MinGW and MinGW-W64 (including x86_64!). *Compilation* tested on: - MSVC - msysGit environment (twice) - Linux cross-toolchain i686-pc-mingw32 Thanks. I always wanted to do this but never got around to clean up and submit. There's a problem with include order in Makefile. I don't want to specify CROSS_COMPILE or CC=mingw32-gcc from command line any time I make a build, so I put all those in config.mak. But because this file is included after config.mak.uname, all the default settings for MINGW is ignored. I'm not sure if we can move config.mak up before config.mak.uname. If we can't I'm ok with including a new file (config.mak.pre or something) before config.mak.uname. That would make make (no arguments) work for me. -- 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 v6 02/39] api-lockfile: revise and expand the documentation
On 09/26/2014 08:33 PM, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: Document a couple more functions and the flags argument as used by hold_lock_file_for_update() and hold_lock_file_for_append(). Reorganize the document to make it more accessible. Helped-by: Jonathan Nieder jrnie...@gmail.com Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- Documentation/technical/api-lockfile.txt | 199 ++- 1 file changed, 145 insertions(+), 54 deletions(-) Nicely done. +* Mutual exclusion and atomic file updates. When we want to change a + file, we create a lockfile `filename.lock`, write the new file + contents into it, and then rename the lockfile to its final + destination `filename`. We create the `filename.lock` file with + `O_CREAT|O_EXCL` so that we can notice and fail if somebody else has + already locked the file. You may want to say then atomically rename the lockfile to its final destination to commit the changes and unlock the file. here; that way, your mention of commit in the next paragraph would become easier to understand. Good; will change. [...] +Calling sequence + + +The caller: + +* Allocates a variable `struct lock_file lock` in the bss section or + heap, initialized to zeros. It cannot be an auto variable allocated + on the stack. Because the `lock_file` structure is used in an + `atexit(3)` handler, its storage has to stay throughout the life of + the program, even after the file changes have been committed or + rolled back. It is easier to read if you pushed the second sentence (which is a rephrase of the first one) and third sentence (which explains why the second sentence is true) out of line as a side-note, I think, or probably remove them from here (see below). I was being repetitive because I didn't want the docs to depend on the user remembering what the bss section is (which, technically, is also not part of the C standard). I think a better way would be to just not mention bss section at all and reword the rest. Maybe something like The caller: * Allocates a variable `struct lock_file lock`, initialized to zeros. Because the `lock_file` structure is used in an `atexit(3)` handler, its storage has to remain valid throughout the life of the program; e.g., it should be a static variable or space allocated on the heap. Better? +* Attempts to create a lockfile by passing that variable and the path + of the final destination (e.g. `$GIT_DIR/index`) to + `hold_lock_file_for_update` or `hold_lock_file_for_append`. + +* Writes new content for the destination file by writing to the file + descriptor returned by those functions (also available via + `lock-fd`). + +When finished writing, the caller can: + +* Close the file descriptor and rename the lockfile to its final + destination by calling `commit_lock_file`. + +* Close the file descriptor and remove the lockfile by calling + `rollback_lock_file`. + +* Close the file descriptor without removing or renaming the lockfile + by calling `close_lock_file`, and later call `commit_lock_file` or + `rollback_lock_file`. + +At this point, the `lock_file` object must not be freed or altered, +because it is still registered in the `lock_file_list`. However, it +may be reused; just pass it to another call of +`hold_lock_file_for_update` or `hold_lock_file_for_append`. It feels a bit conflicting between must not be freed or ALTERED and it may be REUSED. Drop or altered to reduce confusion? And this repeats the third sentence I suggested to remove from the first paragraph (above 'see below' refers here). The purpose of or altered is to make sure that users don't imagine that they should memset() the structure to zeros or something before reusing it (especially since the caller instructions earlier say that the object should be initialized to zeros). Would it help if I change s/altered/altered by the caller/ ? I will also drop because it is still registered in the `lock_file_list`. Is it allowed to tell the name of this lock_file to other people and let them read from it? The answer is yes but it is not obvious from this description. Also mention how the above interact with reopen_lock_file() here? I'll take a stab at it, though TBH I haven't really studied the use case for reopen_lock_file(). You might be better able to provide insight into this topic. +If the program exits before you have called one of `commit_lock_file`, +`rollback_lock_file`, or `close_lock_file`, an `atexit(3)` handler +will close and remove the lockfile, essentially rolling back any +uncommitted changes. s/essentially //; Done. +Error handling +-- + +The `hold_lock_file_*` functions return a file descriptor on success +or -1 on failure (unless `LOCK_DIE_ON_ERROR` is used; see below). On +errors, `errno` describes the reason for
Re: `git log relative_path_to_object` does not respect the --work-tree path
Ok. Yes, it 's kind of tricky. But the `-- path` does both things. `-- path` looks for the relative path within the current directory but defaults to the work-tree root if your current directory does not belong to the repo. About `git -C dir`, awesome feature, I love that, but it's not my point. (and I'm actually maintaining the ruby-git gem, supporting git = 1.6 T_T) I really appreciate your feedback. Regards, -- Roberto Decurnex On Mon, Sep 29, 2014 at 5:56 PM, Jonathan Nieder jrnie...@gmail.com wrote: Hi Roberto, Roberto Eduardo Decurnex Gorosito wrote: When passing objects to the `git log`, by just naming them or using the `--objects` option, relative paths are evaluated using the current working directory instead of the current working tree path. Why should they be relative to the worktree root? When you use relative paths within a worktree, they are not relative to the worktree root. For example, the following works within a clone of git.git: $ cd Documentation $ git log git.txt You might be looking for 'git -C directory', which chdirs to the named directory so paths are relative to there. Hope that helps, Jonathan -- 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 v6 02/39] api-lockfile: revise and expand the documentation
On 09/26/2014 10:40 PM, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: +If you need to close the file descriptor you obtained from a +`hold_lock_file_*` function yourself, do so by calling +`close_lock_file`. You should never call `close(2)` yourself! This is sometimes untenable, isn't it? A caller may want to freopen(3) a stream on the fd to write into it and then fclose(3); which would not know to call close_lock_file() but calls close(2). You are absolutely correct. I carried this text over from the old version, where it was just as inaccurate. I didn't fix it because IMO the correct fix is to add a stdio-oriented entry point to the lockfile API, and teach the lockfile code to handle closing the FILE correctly when necessary. But I didn't want to add even more changes to this patch series, so I am working on this as a separate patch series. I hope to submit it soon. Michael -- Michael Haggerty mhag...@alum.mit.edu -- 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 v6 27/39] try_merge_strategy(): use a statically-allocated lock_file object
On 09/26/2014 09:00 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
Even the one lockfile object needn't be allocated each time the
function is called. Instead, define one statically-allocated
lock_file object and reuse it for every call.
Suggested-by: Jeff King p...@peff.net
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
...
-hold_locked_index(lock, 1);
+hold_locked_index(lock, 1);
refresh_cache(REFRESH_QUIET);
if (active_cache_changed
-write_locked_index(the_index, lock, COMMIT_LOCK))
+write_locked_index(the_index, lock, COMMIT_LOCK))
I wondered if the next step would be to lose the lock parameter
from {hold,write}_locked_index() and have them work on a
process-global lock, but that would not work well.
The reason why this patch works is because we are only working with
a single destination (i.e. $GIT_INDEX_FILE typically .git/index),
right?
Interesting.
Ummm, this patch wasn't supposed to be interesting. If it is then maybe
I made a mistake...
My reasoning was that after the lock is acquired, it is released
unconditionally before the function exits. Therefore, it should be no
problem to reuse it each time the function is called.
Of course, one gap in this argument is the possibility that this
function calls itself recursively. The fact that it calls
merge_recursive() should have alerted me to this possibility. So let me
check...
* try_merge_strategy() is only called by cmd_merge()
* cmd_merge() is only called by the command dispatcher
So I don't see a way for this function to call itself recursively within
a single process.
A second possible gap in this argument would be if this function can be
called from multiple threads. But hardly any of our code is thread-safe,
so I hardly think that is likely.
What am I missing?
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
--
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
I WANT TO INVEST.......
My dear good friend, Good day to you,i got your contact from a business directory in my agent office and i decide to contact you directly for the sake of business. My full name is Mrs Mariam Mohammed we are from Congo,I am now searching for a reliable and experience business partner I have found out that middle-east is very good for investment currently. You and my son will need to agree on a percentage we will give you after the investment has been concluded,for your direction of the lucrative investment either in middle-east or any country of your choice under your supervision I advise you to contact my son immediately for meeting and conclusion, and discuss on how to see face to face and discuss more detain. Thank you once again for your interest. Mrs Mariam Mohammed. -- 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] git-prompt.sh: shorter equal upstream branch name
From: Julien Carsique julien.carsi...@gmail.com
When using the name option of GIT_PS1_SHOWUPSTREAM to show the upstream
abbrev name, if the upstream name is the same as the local name, then some
space could be saved in the prompt. This is especially needed on long branch
names.
Replace the upstream name with the sign '=' if equal to the local one.
Example:[master * u= origin/=]$
instead of: [master * u= origin/master]$
Signed-off-by: Julien Carsique julien.carsi...@gmail.com
---
contrib/completion/git-prompt.sh | 7 +++
1 file changed, 7 insertions(+)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index c5473dc..a9aba20 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -209,6 +209,13 @@ __git_ps1_show_upstream ()
if [[ -n $count -n $name ]]; then
__git_ps1_upstream_name=$(git rev-parse \
--abbrev-ref $upstream 2/dev/null)
+
+ __head=${b##refs/heads/}
+ if [ $__head = ${__git_ps1_upstream_name##*/} ];
then
+
__git_ps1_upstream_name=${__git_ps1_upstream_name/$__head/=}
+ fi
+ unset __head
+
if [ $pcmode = yes ] [ $ps1_expanded = yes ]; then
p=$p \${__git_ps1_upstream_name}
else
--
2.1.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] Do not make trace.c/getnanotime an inlined function
Duy Nguyen pclo...@gmail.com writes: Hmm.. no. Even if the function is inlined in multiple places, inline code still points to the same offset variable. OK, 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 v6 02/39] api-lockfile: revise and expand the documentation
On Tue, Sep 30, 2014 at 03:41:55PM +0200, Michael Haggerty wrote: I didn't fix it because IMO the correct fix is to add a stdio-oriented entry point to the lockfile API, and teach the lockfile code to handle closing the FILE correctly when necessary. I think so, too, after our discussion[1] surrounding 9540ce5 (refs: write packed_refs file using stdio, 2014-09-10). But I didn't want to add even more changes to this patch series, so I am working on this as a separate patch series. I hope to submit it soon. Yay. -Peff [1] http://thread.gmane.org/gmane.comp.version-control.git/256729/focus=256734 -- 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 v6 02/39] api-lockfile: revise and expand the documentation
Michael Haggerty mhag...@alum.mit.edu writes: I was being repetitive because I didn't want the docs to depend on the user remembering what the bss section is (which, technically, is also not part of the C standard). I think a better way would be to just not mention bss section at all and reword the rest. Maybe something like The caller: * Allocates a variable `struct lock_file lock`, initialized to zeros. Because the `lock_file` structure is used in an `atexit(3)` handler, its storage has to remain valid throughout the life of the program; e.g., it should be a static variable or space allocated on the heap. Better? Somewhat. I like that you droped BSS, though. Allocates a 'struct lock_file' either as a static variable or on the heap, initialized to zeros. Once you use the structure to call hold_lock_file_* family of functions, it belongs to the lockfile subsystem and its storage must remain valid throughout the life of the program (i.e. you cannot use an on-stack variable to hold this structure). It feels a bit conflicting between must not be freed or ALTERED and it may be REUSED. Drop or altered to reduce confusion? And this repeats the third sentence I suggested to remove from the first paragraph (above 'see below' refers here). The purpose of or altered is to make sure that users don't imagine that they should memset() the structure to zeros or something before reusing it (especially since the caller instructions earlier say that the object should be initialized to zeros). Would it help if I change s/altered/altered by the caller/ ? The fundamental rule is that callers outside the lockfile system must not touch individual members of struct lock_file that is live. They must not free, they must not alter, they must not do anything other than calling the lockfile API functions. While it is natural that the readers would understand such a rule must be followed for a lockfile that is in either the initialized, locked, closed-but-not-committed state, I agree that it is not just possible but likely that people misunderstand and think that once a lockfile is committed or rolled back it no longer has to follow that rule. We would want to make sure readers do not fall into such a misunderstanding. I dunno. Your if you memset it to NULs, you will break the linked list of the lock and the whole lockfile system and the element cannot even be reused. may be the most important thing you may have wanted to say, but it is not conveyed by that change at all, at least to me. A small voice in the back of my skull keeps telling me that a rule that is hard to document and explain is a rule that does not make sense. Is it possible to allow commit and rollback to safely remove the structure from the atexit(3) list (aka no longer owned by the lockfile subsystem)? Is it allowed to tell the name of this lock_file to other people and let them read from it? The answer is yes but it is not obvious from this description. Also mention how the above interact with reopen_lock_file() here? I'll take a stab at it, though TBH I haven't really studied the use case for reopen_lock_file(). You might be better able to provide insight into this topic. You would want to be able to do this: - hold a lock on a file (say, the index); - update it in preparation to commit it; - write it out and make sure the contents is on the disk platter, in preparation to call another program and allow it (and nobody else) to inspect the contents you wrote, while still holding the lock yourself. In our set of API functions, close_lock_file is what lets us do this. - further update it, write it out and commit. We need to read it first, open(2) it to write, write(2), and commit_lock_file(). The set of API functions you described in the document, there is no way to say I already have a lock on that file, just let me open(2) for writing because I have further updates and that is where reopen comes in. -- 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] t0090: avoid passing empty string to printf %d
FreeBSD's printf(1) doesn't accept empty strings for numerical format
specifiers:
$ printf %d\n /dev/null; echo $?
printf: : expected numeric value
1
Initialize the AWK variable c to make sure the shell variable
subtree_count always contains a numerical value, in order to keep the
subsequently called printf happy.
Signed-off-by: Rene Scharfe l@web.de
---
t/t0090-cache-tree.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t0090-cache-tree.sh b/t/t0090-cache-tree.sh
index f9648a8..158cf4f 100755
--- a/t/t0090-cache-tree.sh
+++ b/t/t0090-cache-tree.sh
@@ -22,7 +22,7 @@ generate_expected_cache_tree_rec () {
# ls-files might have foo/bar, foo/bar/baz, and foo/bar/quux
# We want to count only foo because it's the only direct child
subtrees=$(git ls-files|grep /|cut -d / -f 1|uniq)
- subtree_count=$(echo $subtrees|awk '$1 {++c} END {print c}')
+ subtree_count=$(echo $subtrees|awk -v c=0 '$1 {++c} END {print c}')
entries=$(git ls-files|wc -l)
printf SHA $dir (%d entries, %d subtrees)\n $entries
$subtree_count
for subtree in $subtrees
--
2.1.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 v6 02/39] api-lockfile: revise and expand the documentation
Jeff King p...@peff.net writes: On Tue, Sep 30, 2014 at 03:41:55PM +0200, Michael Haggerty wrote: I didn't fix it because IMO the correct fix is to add a stdio-oriented entry point to the lockfile API, and teach the lockfile code to handle closing the FILE correctly when necessary. I think so, too, after our discussion[1] surrounding 9540ce5 (refs: write packed_refs file using stdio, 2014-09-10). Yeah, but we already write packed-refs via stdio, so the stdio oriented lockfile API entry points can no longer be just on the mythical todo list but needs to become reality before we can merge this topic sanely. But I didn't want to add even more changes to this patch series, so I am working on this as a separate patch series. I hope to submit it soon. Yay. Yay. 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 v6 27/39] try_merge_strategy(): use a statically-allocated lock_file object
Michael Haggerty mhag...@alum.mit.edu writes:
On 09/26/2014 09:00 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
Even the one lockfile object needn't be allocated each time the
function is called. Instead, define one statically-allocated
lock_file object and reuse it for every call.
Suggested-by: Jeff King p...@peff.net
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
...
- hold_locked_index(lock, 1);
+ hold_locked_index(lock, 1);
refresh_cache(REFRESH_QUIET);
if (active_cache_changed
- write_locked_index(the_index, lock, COMMIT_LOCK))
+ write_locked_index(the_index, lock, COMMIT_LOCK))
I wondered if the next step would be to lose the lock parameter
from {hold,write}_locked_index() and have them work on a
process-global lock, but that would not work well.
The reason why this patch works is because we are only working with
a single destination (i.e. $GIT_INDEX_FILE typically .git/index),
right?
Interesting.
Ummm, this patch wasn't supposed to be interesting. If it is then maybe
I made a mistake...
Well, Interesting is very different from Questionable.
This lock can never have multiple active instances, as you
mentioned.
We didn't have to change this for so long since the function was
written; that probably is because this sequence:
lock = hold_lock();
use(lock);
commit(lock); /* or rollback(lock) */
is so obviously natural to callers of the API, and commit/rollback
looks very much like a declaration that we are done with the object
and its resource can be freed.
This change makes sense because the API does not actually allow us
to free the resource held to use this lock, so reducing the number
of struct lock_file ever used during the life of the program makes
difference, especially when you use many, even when not many of them
you need to hold at the same time.
Which was counter-intuitive to me, and the realization did not hit
me until I thought about it, which made it an Interesting change.
It may at the same be suggesting that once in the lockfile subsystem,
the resource becomes reclaimable may be something we would want to
fix, though.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Submodules and GIT_ALTERNATE_OBJECT_DIRECTORIES
Hi list, I'd like to shorten the time needed by our continuous integration (CI) tool to clone the source repositories. Currently the full clone takes about 10 minutes (even from local server). Our main repository has several submodules so the CI tool runs git submodule update --init. My idea was to use GIT_ALTERNATE_OBJECT_DIRECTORIES to cache objects from several submodule repositories locally. However, this does not work because GIT_ALTERNATE_OBJECT_DIRECTORIES is considered local to the super-project and is not propagated to the git clone for submodules (git-submodule.sh calls clear_local_git_env). My question is why is GIT_ALTERNATE_OBJECT_DIRECTORIES considered local to the repository? If I could modify the command-line I would use the git submodule update with the --reference option, which is propagated to clones of all submodules. Letting GIT_ALTERNATE_OBJECT_DIRECTORIES propagate to the submodules should have the same effect as --reference option. So why it is not propagated? Thanks, -Michal -- 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 v2.1.2
The latest maintenance release Git v2.1.2 is now available at the usual places. With this, v2.1.x has all the important fixes that have been already applied to the 'master' front for the next feature release. It also contains some updates to German translation. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.1.2' tag and the 'maint' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git 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 v2.1.2 Release Notes * git push over HTTP transport had an artificial limit on number of refs that can be pushed imposed by the command line length. * When receiving an invalid pack stream that records the same object twice, multiple threads got confused due to a race. * An attempt to remove the entire tree in the git fast-import input stream caused it to misbehave. * Reachability check (used in git prune and friends) did not add a detached HEAD as a starting point to traverse objects still in use. * git config --add section.var val used to lose existing section.var whose value was an empty string. * git fsck failed to report that it found corrupt objects via its exit status in some cases. Changes since v2.1.1 are as follows: Jeff King (5): send-pack: take refspecs over stdin index-pack: fix race condition with duplicate bases fsck: exit with non-zero status upon error from fsck_obj() config: avoid a funny sentinel value a^ fsck: return non-zero status on missing ref tips Junio C Hamano (1): Git 2.1.2 Max Kirillov (1): reachable.c: add HEAD to reachability starting commits Maxim Bublis (2): t9300: test filedelete command fast-import: fix segfault in store_tree() Phillip Sz (2): l10n: de.po: change Email to E-Mail l10n: de.po: use comma before um Ralf Thielow (1): po/TEAMS: add new member to German translation team Sergey Organov (2): Documentation/git-rebase.txt: -f forces a rebase that would otherwise be a no-op Documentation/git-rebase.txt: upstream must be given to specify branch Tanay Abhra (1): make config --add behave correctly for empty and NULL values -- 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 (Sep 2014, #09; Tue, 30)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. Many fixes on the 'master' has been merged down to 'maint' and the tip of the latter is at v2.1.2 now. Among the topics that have been cooking in 'next', easier ones have all graduated to 'master'. During the remainder of this cycle, I would like to see these topics to be in 'master' by the end of the 8th week in late October: - ref transaction updates by Ronnie and Jonathan - lockfile updates by Michael - replacement for contrib/workdir by Duy All of them are of rather nontrivial size, and would need to be in 'next' for at least a few weeks, which would mean they must be in a good enough shape to go incremental by mid October. I suspect that we might be cutting it a bit too close for some of them but we'll see. Side note: I am not saying that I will ignore other topics; I am just saying that I care about these three topics because their changes have large impact on the current codebase, and they have big positive impact on the future when done right. We want to see atomic updates to multiple refs. We want to see our locks behave sensibly. We want to see safer way to work with multiple working trees checked out of a single repository. Other topics in flight are of smaller impact that I would not worry too much about and tend to require less brainpower to judge if the design is good, and I'd be happy to see them go through the usual 'pu' to 'next' to 'master' with their own pace, either by the end of this cycle, extending into the next cycle---in that sense I do not care too much about them to single any 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 -- [New Topics] * dt/cache-tree-repair (2014-09-30) 1 commit - t0090: avoid passing empty string to printf %d This fixes a topic that has graduated to 'master'. Will merge to 'next'. -- [Graduated to master] * jc/test-lazy-prereq (2014-06-13) 1 commit (merged to 'next' on 2014-09-25 at ed479f3) + tests: drop GIT_*_TIMING_TESTS environment variable support Test-script clean-up. * jt/itimer-autoconf (2014-08-29) 3 commits (merged to 'next' on 2014-09-25 at efd65ba) + autoconf: check for setitimer() + autoconf: check for struct itimerval + git-compat-util.h: add missing semicolon after struct itimerval (this branch is used by jt/timer-settime.) setitmer(2) and related API elements can be configured from Makefile but autoconf did not know about it. * pr/use-default-sigpipe-setting (2014-09-22) 2 commits (merged to 'next' on 2014-09-24 at 2d678ed) + mingw.h: add dummy functions for sigset_t operations + unblock and unignore SIGPIPE We used to get confused when a process called us with SIGPIPE ignored; we do want to die with SIGPIPE when the output is not read by default, and do ignore the signal when appropriate. * sb/merge-recursive-copy-paste-fix (2014-09-23) 2 commits (merged to 'next' on 2014-09-24 at b8dfbef) + merge-recursive: remove stale commented debugging code + merge-recursive: fix copy-paste mistake git merge-recursive had a small bug that could have made it mishandle one side deleted, the other side did not touch it in a rare corner case, where the other side actually did touch to cause the blob object names to be different but both blobs before and after the change normalize to the same (e.g. correcting mistake to check in a blob with CRLF line endings by replacing it with another blob that records the same contents with LF line endings). -- [Stalled] * rs/ref-transaction (2014-09-12) 20 commits . remote rm/prune: print a message when writing packed-refs fails . ref_transaction_commit: bail out on failure to remove a ref . lockfile: remove unable_to_lock_error . refs.c: do not permit err == NULL . for-each-ref.c: improve message before aborting on broken ref . refs.c: fix handling of badly named refs . branch -d: avoid repeated symref resolution . refs.c: change resolve_ref_unsafe reading argument to be a flags field . refs.c: make write_ref_sha1 static . fetch.c: change s_update_ref to use a ref transaction . refs.c: ref_transaction_commit: distinguish name conflicts from other errors . refs.c: pass a skip list to name_conflict_fn . refs.c: call lock_ref_sha1_basic directly from commit . refs.c: move the check for valid refname to lock_ref_sha1_basic . rename_ref: don't ask read_ref_full where the ref came from . refs.c: pass the ref log message to _create/delete/update instead of _commit . refs.c: add an err argument to delete_ref_loose . wrapper.c: add a new function unlink_or_msg . wrapper.c:
Re: [git] What's cooking in git.git (Sep 2014, #09; Tue, 30)
On Tue, Sep 30, 2014 at 01:23:18PM -0700, Junio C Hamano wrote: Here are the topics that have been cooking. It looks like my boring git-mailinfo doc patch [1] fell through the cracks here ;). Or maybe it's just cooking a bit longer before getting queued? Cheers, Trevor [1]: Gmane: http://article.gmane.org/gmane.comp.version-control.git/257460 Subject: [PATCH] docs/git-mailinfo: Mention the manual separator (---) Message-ID: 28b04f1c17f2cc2fe252948bc0b7bb10df24b489.1411571629.git.wk...@tremily.us Date: Wed, 24 Sep 2014 08:25:32 -0700 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: What's cooking in git.git (Sep 2014, #09; Tue, 30)
W. Trevor King wk...@tremily.us writes: On Tue, Sep 30, 2014 at 01:23:18PM -0700, Junio C Hamano wrote: Here are the topics that have been cooking. It looks like my boring git-mailinfo doc patch [1] fell through the cracks here ;). Or maybe it's just cooking a bit longer before getting queued? Nobody is cooking it as far as I remember. Did I see any discussion on it? I looked at the new text and I find it fairly objectionable. A review in a separate message will follow. -- 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] docs/git-mailinfo: Mention the manual separator (---)
W. Trevor King wk...@tremily.us writes: And explain how it interacts with the scissors setting. Signed-off-by: W. Trevor King wk...@tremily.us --- The three-dash limit comes from f0658cf2 (restrict the patch filtering, 2007-03-12), but I couldn't find any associated documentation. Since the effect is so similar to the scissors line, I thought about adding the information to the --scissors entry. The manual separator is really independent from the scissors though, so I settled on explaining both separators in the DESCRIPTION. This patch is against 'maint'. Documentation/git-mailinfo.txt | 23 +++ 1 file changed, 23 insertions(+) diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt index 164a3c6..6c6c527 100644 --- a/Documentation/git-mailinfo.txt +++ b/Documentation/git-mailinfo.txt @@ -21,6 +21,29 @@ written out to the standard output to be used by 'git am' to create a commit. It is usually not necessary to use this command directly. See linkgit:git-am[1] instead. +The commit message extracted from the e-mail depends on the scissors +setting (see '--[no-]scissors' in the OPTIONS section). ... It encourages a wrong way to look at it to phrase it like this. The scissors marker is not about commit log message alone, as you can have in-body headers like From: and Subject: to override them after the marker, and also in-body headers before the scissors are ignored (it is not even We read From: from the part before the scissors but then let it be overriden with another From: after the scissors ). The right way to look at it is this: The scissors line will cause everything before it discarded and Git pretends as if the body of the message begins after it. If we are extending the documentation on ---, it should also mention the caveats, namely, it is encouraged to indent the extra message by a SP or something to make sure that it is not mistaken as part of the patch. I suspect that this omission from this patch stems from content after the separator is discarded, which is not the case. Content after the separator is fed to git apply as a patch. apply may discard non-patch and the end result may be that the garbage disappears, but that is not the primary reason why it does not appear in the resulting log message. If anything, --- separates between the log part from patch part. The second example concentrates too heavily on log message which makes it a not-very-good addition as-is. +Besides the +scissors option (which discards content before the scissors), you can +also use '---' as a separator (which discards content after the +separator). For example, without scissors you can have a body like +this: + + +Your commit message. +--- +Comments that aren't part of the commit message. + + +With scissors, you can have a body like this: + + +Comments that aren't part of the commit message. +---8--- +Your commit message. +--- +More comments that aren't part of the commit message. + + OPTIONS --- -- 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-prompt.sh: shorter equal upstream branch name
On 2014-09-30 11:36, Julien Carsique wrote:
From: Julien Carsique julien.carsi...@gmail.com
When using the name option of GIT_PS1_SHOWUPSTREAM to show the upstream
abbrev name, if the upstream name is the same as the local name, then some
space could be saved in the prompt. This is especially needed on long branch
names.
Replace the upstream name with the sign '=' if equal to the local one.
Example:[master * u= origin/=]$
instead of: [master * u= origin/master]$
Seems like a good idea to me.
Signed-off-by: Julien Carsique julien.carsi...@gmail.com
---
contrib/completion/git-prompt.sh | 7 +++
1 file changed, 7 insertions(+)
Please add some new tests in t/9903-bash-prompt.sh. In particular:
* upstream ref in refs/heads
* upstream is git-svn
* branch names containing slashes
diff --git a/contrib/completion/git-prompt.sh
b/contrib/completion/git-prompt.sh
index c5473dc..a9aba20 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -209,6 +209,13 @@ __git_ps1_show_upstream ()
if [[ -n $count -n $name ]]; then
__git_ps1_upstream_name=$(git rev-parse \
--abbrev-ref $upstream 2/dev/null)
+
+ __head=${b##refs/heads/}
To avoid colliding with other stuff, this variable should either be
local or prefixed with '__git_ps1'.
+ if [ $__head = ${__git_ps1_upstream_name##*/} ];
then
This comparison breaks on branches containing a slash (e.g., foo/bar).
Also, how does this interact with git-svn? (I don't use git-svn so I'm
not very familiar with how it manages refs.)
Assuming remote names can't contain a slash (which I think is true), a
safer approach might be parse the full ref and special-case refs/remotes:
__git_ps1_upstream_name=$(git rev-parse \
--abbrev-ref ${upstream} 2/dev/null)
local tmp
tmp=$(git rev-parse --symbolic-full-name ${upstream} 2/dev/null)
case ${tmp} in
refs/remotes/*)
# todo: can ${b} be something other than refs/heads/* here?
[ ${__git_ps1_upstream_name#*/} != ${b#refs/heads/} ] \
|| __git_ps1_upstream_name=${__git_ps1_upstream_name%%/*}/\=
;;
esac
Additional cases could be added to handle git-svn if needed.
+
__git_ps1_upstream_name=${__git_ps1_upstream_name/$__head/=}
* This could break if ${__head} contains any pattern-special
characters.
* While this syntax works in both Bash and Zsh (assuming no
pattern-special characters), my preference is to stick to POSIX[1]
when possible. For example, assuming the upstream name is
always in refs/remotes (which is not true, but this is an example)
and remote names can't contain a '/', you could do this:
__git_ps1_upstream_name=${__git_ps1_upstream_name%%/*}/\=
* I don't think the CodingGuidelines explicitly prohibit long lines
for shell code, and this file already contains plenty of long
lines, but I really dislike lines longer than 80 characters.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
+ fi
+ unset __head
+
if [ $pcmode = yes ] [ $ps1_expanded = yes ]; then
p=$p \${__git_ps1_upstream_name}
else
-Richard
--
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] docs/git-mailinfo: Mention the manual separator (---)
On Tue, Sep 30, 2014 at 02:12:58PM -0700, Junio C Hamano wrote:
If we are extending the documentation on ---, …
Ah, I see that the --- are actually mentioned already in the
DISCUSSION section of git-am(1) since 2499857b (git-am documentation:
describe what is taken from where, 2007-03-24). I expected the docs
to be either in git-mailinfo(1) (since the code added by f0658cf2
(restrict the patch filtering, 2007-03-12) is in mailinfo) or to match
a grep for '---'. Maybe we should drop this patch in favor of notes
in git-mailinfo(1) and git-format-patch(1) pointing folks at the
DISCUSSION section in git-am(1) and a more easily grepable “three
dashes ('---') in gi-am(1)?
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] git-prompt.sh: shorter equal upstream branch name
Julien Carsique julien.carsi...@gmail.com writes:
From: Julien Carsique julien.carsi...@gmail.com
When using the name option of GIT_PS1_SHOWUPSTREAM to show the upstream
abbrev name, if the upstream name is the same as the local name, then some
space could be saved in the prompt. This is especially needed on long branch
names.
Replace the upstream name with the sign '=' if equal to the local one.
Example:[master * u= origin/=]$
instead of: [master * u= origin/master]$
Signed-off-by: Julien Carsique julien.carsi...@gmail.com
---
contrib/completion/git-prompt.sh | 7 +++
1 file changed, 7 insertions(+)
diff --git a/contrib/completion/git-prompt.sh
b/contrib/completion/git-prompt.sh
index c5473dc..a9aba20 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -209,6 +209,13 @@ __git_ps1_show_upstream ()
if [[ -n $count -n $name ]]; then
__git_ps1_upstream_name=$(git rev-parse \
--abbrev-ref $upstream 2/dev/null)
+
+ __head=${b##refs/heads/}
+ if [ $__head = ${__git_ps1_upstream_name##*/} ];
then
When you are on your xyz branch that was forked off of
refs/remote/origin/xyz/xyz, $__git_ps1_upstream_name would be
origin/xyz/xyz and $__head is xyz at this point. The latter
matches the former after stripping */ maximally from its front
(i.e. xyz). It is unclear if you really want to make these two
match, but as long as you correctly abbreviate you would not lose
information, I would imagine. I am guessing that you would want to
see origin/xyz/= in such a case, and if you started your xyz off
of origin/abc/xyz, you would want origin/abc/=.
+
__git_ps1_upstream_name=${__git_ps1_upstream_name/$__head/=}
Now, what does ${__git_ps1_upstream_name/$__head/=} give us?
This should not do regexp substitution in the first place, I would
think. You made sure $__head is the tail-matching substring of the
longer variable, so you chop that many bytes off of the latter.
Is this new feature something everybody should want unconditionally,
or are there valid reasons why some people may not want to see this
abbreviation happen (even if the implementation were not buggy)?
+ fi
+ unset __head
Unlike __git_ps1_upstream_name, this __head does not have to be
visible outside this function. Wouldn't it be better to declare it
as local (this is bash prompt and we can afford to step outside
POSIX) and there is no need to unset after use if you did so, no?
if [ $pcmode = yes ] [ $ps1_expanded = yes ]; then
p=$p \${__git_ps1_upstream_name}
else
--
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-prompt.sh: shorter equal upstream branch name
Richard Hansen rhan...@bbn.com writes:
Additional cases could be added to handle git-svn if needed.
Thanks for a review (everything I omitted above looked good to me).
+
__git_ps1_upstream_name=${__git_ps1_upstream_name/$__head/=}
* This could break if ${__head} contains any pattern-special
characters.
... but I do not think refnames can have *, ? and such so it may not
be relevant ;-).
* While this syntax works in both Bash and Zsh (assuming no
pattern-special characters), my preference is to stick to POSIX[1]
when possible.
Nah. The existing script is full of bash-isms like local you
suggested to add (and other constructs like shell arrays and [[ ]]
tests, I suspect), and there is no hope to fix them to stick to
the bare-minimum POSIX, and there is no need to do so (isn't this
bash-prompt script after all?)
* I don't think the CodingGuidelines explicitly prohibit long lines
for shell code, and this file already contains plenty of long
lines, but I really dislike lines longer than 80 characters.
Yes, I dislike overlong lines, too. But I also dislike lines that
are artificially chopped into
shorter pieces without
good reason ;-).
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] docs/git-mailinfo: Mention the manual separator (---)
W. Trevor King wk...@tremily.us writes:
... Maybe we should drop this patch in favor of notes
in git-mailinfo(1) and git-format-patch(1) pointing folks at the
DISCUSSION section in git-am(1) and a more easily grepable “three
dashes ('---') in gi-am(1)?
I am all for dropping new changes and expecially duplicates ;-)
Because I would be a bad judge for suggesting the place that a new
reader likely expects to find relevant information, as I am not a
new reader who does not know where to start looking, I'll let others
figure out where the best places to add enhancements to are.
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] init - Honour the global core.filemode setting
Hi Torsten,
Thank you for taking the time to review my patch.
On 28 September 2014 04:52, Torsten Bögershausen tbo...@web.de wrote:
On 2014-09-28 02.37, Hilco Wijbenga wrote:
If ~/.gitconfig contains a core.filemode entry then git init
should honour that setting.
Signed-off-by: Hilco Wijbenga hilco.wijbe...@gmail.com
---
This bit me at work where I have to work with Windows. Git on Cygwin
and the Eclipse Git plugin do not agree on file attributes so I had
set filemode = false in ~/.gitconfig.
This feels strange.
Each and every repo has a core.filemode setting.
Or should have.
Did you manage to create a repo without core.filemode in repo/.git/config ?
And if yes, how?
Perhaps I completely misunderstand the meaning of core.filemode but I
thought it determined whether Git cared about changes in file
properties? So this is client OS related and independent of the repo?
A few weeks later, I did a git init and, some time later yet, I
noticed the strange behaviour of Cygwin/Eclipse again.
I do not fully understand which strange behaviour you experied,
so I need to guess.
The problem is simply that Eclipse's Git sees changes that Cygwin's
Git does not. It's some sort of unfortunate consequence of trying to
pretend to be Linux on Windows, I guess. The only way to get them to
agree was to set core.filemode to false. Now you might rightly argue
that Eclipse and/or Windows and/or Cygwin should be fixed but that's a
much bigger undertaking than simply setting an existing Git property.
:-)
This was very
surprising because things had been working well until then. It took
quite a bit of research before I realized that git init always sets
filemode. I think filemode should only be set if not set already
in the global config (similar to log_all_ref_updates).
That is part of the whole story:
In general, git init probes the file system, if the executable bit
is working as expected.
So if you create a Git repository under VFAT, the executable bit is not
supported.
Git will notice that, and set core.filemode = false.
NTFS is a different story:
Cygwin has support for the executable bit under NTFS, but Msysit does not.
Agreed. That is what I concluded from the code.
So if you share a Git repository between Msysgit and cygwin, it may be
better
to set core.filemode to false.
Possibly. I would argue that that is up to the individual developer.
There is however a problem with your patch, or 2:
When you set core.filemode = false in your ~/.gitconfig,
another developer may have core.filemode = true in his config.
If you manage to share the repo using a network, git will behave different
for the 2 users.
Isn't that what everything in ~/gitconfig is for? So that I can set
attributes appropriate to my working environment? Besides, that is
already the case if developer A uses a VFAT system and developer B
uses NTFS or JFS or EXTn or ..., right? (As you also indicated above.)
Solution:
Set core.filemode for this repo alwways in the repo. (as we do today in
git.git)
I suppose you could set it to false, yes. But then it affects
everybody, that seems like going for the lowest common denominator?
When you run git init with ~/.gitconfig = true, you should
anyway probe the file system, as it may not support file mode, and
core.filemode may be false.
So the solution that I can see is:
(Some pseudo-code:)
if (git config (global config ) == false) ||
(git config (~/.config ) == false) then
git_config_set(core.filemode, false);
else
probe the file system and set core.filemode as we do today
fi
Yeah, I actually considered that (well, something less complete,
actually :-) ) but decided to go for the simpler approach that I
showed. My assumption is that the developer working with the repo
knows what he is doing. It seems wrong for Git to override that
decision. Then again, I don't really see any advantage in setting
core.filemode to true when working with, say, a VFAT filesystem, so
ignoring it in that case might be okay. Would such a setup do active
damage, though?
The usual caveat applies: this is my first patch. Having said that,
please feel free to be pedantic and strict. It's a small patch so I
would imagine that fixing any problems should not take long (assuming
it is acceptable at all, of course). I'd like to know I did it right.
:-)
AFAICT, all tests passed. Should a separate test be added for this change?
I think yes.
Okay, I'll have to figure out how to do that.
Under which system did you test ?
Windows?
CYWGIN ?
MingWW/Msysgit ?
Linux ?
Only Linux. I don't really run Windows at home.
- /* Check filemode trustability */
- filemode = TEST_FILEMODE;
- if (TEST_FILEMODE !lstat(path, st1)) {
- struct stat st2;
- filemode = (!chmod(path, st1.st_mode ^ S_IXUSR)
- !lstat(path, st2)
- st1.st_mode != st2.st_mode);
+ /* Do not override the global filemode setting. */
+ if (trust_executable_bit == -1) {
+ /* Check filemode
Re: What's cooking in git.git (Sep 2014, #09; Tue, 30)
On Tue, Sep 30, 2014 at 01:23:18PM -0700, Junio C Hamano wrote: Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. * da/include-compat-util-first-in-c (2014-09-15) 4 commits - SQUASH??? - check-headers: add header usage checks for .c files - Makefile: add check-headers target - cleanups: ensure that git-compat-util.h is included first So... what is happening to this topic? I think the bottom one is a reasonable clean-up without too much churn, but I am not sure about the rest. Agreed. The SQUASH??? commit could be squashed in, but it might just be better to take the bottom commit and drop the rest since they aren't really that helpful. Thanks, -- David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-prompt.sh: shorter equal upstream branch name
On 2014-09-30 18:35, Junio C Hamano wrote:
Richard Hansen rhan...@bbn.com writes:
* While this syntax works in both Bash and Zsh (assuming no
pattern-special characters), my preference is to stick to POSIX[1]
when possible.
Nah. The existing script is full of bash-isms like local you
suggested to add (and other constructs like shell arrays and [[ ]]
tests, I suspect),
True.
and there is no hope to fix them to stick to
the bare-minimum POSIX,
I don't think it'd be hard to convert it to pure POSIX if there was a
desire to do so. The biggest challenge would be 'local', which would
require subshells or uniquified prefixed global variables. Both of
those are likely to make the code a bit grotesque.
and there is no need to do so (isn't this
bash-prompt script after all?)
It would be unwise to go to great lengths to avoid Bashisms, but I think
it would be smart to use POSIX syntax when it is easy to do so. Rarely
is it hard or awkward to use POSIX syntax ('local' and arrays are two
major exceptions), so Bashisms like the ${//} expansion in this patch
are usually unnecessary divergences from a ubiquitous standard. POSIX
is a stable foundation, and it's easy to get POSIX shell code to run
consistently on all POSIX-like shells.
One of these days I'll try converting git-prompt.sh to POSIX -- I'm
curious to see how bad it would be.
-Richard
--
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
