threads / patch / 20638

patch, 11 partsFix build failure at VC because function declare use old style at regex.c

Subject: [PATCH 01/11] Fix build failure at VC because function declare use old style at regex.c

## tl;dr

26 messages between Aug 17, 2009 and Aug 19, 2009. Diffs are folded; open one to read it.

replies: 25people: 8as markdown or json

Frank Li· Aug 17, 2009, 16:01 UTC · lore
regerror declare function argument type after function define.
Signed-off-by: Frank Li <lznuaa@gmail.com>
---
 compat/regex/regex.c |    6 +-----
 1 files changed, 1 insertions(+), 5 deletions(-)
Show changes to compat/regex/regex.c +1 −5
diff --git a/compat/regex/regex.c b/compat/regex/regex.c
index 5ea0075..5728de1 100644
--- a/compat/regex/regex.c
+++ b/compat/regex/regex.c
@@ -4852,11 +4852,7 @@ regexec (preg, string, nmatch, pmatch, eflags)
    from either regcomp or regexec.   We don't use PREG here.  */
 
 size_t
-regerror (errcode, preg, errbuf, errbuf_size)
-    int errcode;
-    const regex_t *preg;
-    char *errbuf;
-    size_t errbuf_size;
+regerror (int errcode, const regex_t * preg, char * errbuf,size_t errbuf_size)
 {
   const char *msg;
   size_t msg_size;
-- 
1.6.4.msysgit.0
Frank Li· Aug 17, 2009, 16:01 UTC · re: Frank Li · lore

[PATCH 02/11] Fix declare variable at mid of function

Some compiler such as MSVC can't support declear variable at mid of funtion at c file.
Signed-off-by: Frank Li <lznuaa@gmail.com>
---
 compat/mingw.c |   16 ++++++++++++----
 help.c         |    3 ++-
 run-command.c  |    2 ++
 3 files changed, 16 insertions(+), 5 deletions(-)
Show changes to 3 files +16 −5

compat/mingw.c, help.c, run-command.c

diff --git a/compat/mingw.c b/compat/mingw.c
index bed4178..75c74b1 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -123,13 +123,17 @@ int mingw_open (const char *filename, int oflags, ...)
 {
 	va_list args;
 	unsigned mode;
+	int fd;
+
 	va_start(args, oflags);
 	mode = va_arg(args, int);
 	va_end(args);
 
 	if (!strcmp(filename, "/dev/null"))
 		filename = "nul";
-	int fd = open(filename, oflags, mode);
+
+	fd = open(filename, oflags, mode);
+
 	if (fd < 0 && (oflags & O_CREAT) && errno == EACCES) {
 		DWORD attrs = GetFileAttributes(filename);
 		if (attrs != INVALID_FILE_ATTRIBUTES && (attrs & FILE_ATTRIBUTE_DIRECTORY))
@@ -580,10 +584,11 @@ static char **get_path_split(void)
 
 static void free_path_split(char **path)
 {
+	char **p = path;
+
 	if (!path)
 		return;
 
-	char **p = path;
 	while (*p)
 		free(*p++);
 	free(path);
@@ -1108,9 +1113,11 @@ int sigaction(int sig, struct sigaction *in, struct sigaction *out)
 #undef signal
 sig_handler_t mingw_signal(int sig, sig_handler_t handler)
 {
+	sig_handler_t old;
+
 	if (sig != SIGALRM)
 		return signal(sig, handler);
-	sig_handler_t old = timer_fn;
+	old = timer_fn;
 	timer_fn = handler;
 	return old;
 }
@@ -1197,8 +1204,9 @@ struct dirent *mingw_readdir(DIR *dir)
 
 	if (dir->dd_handle == (long)INVALID_HANDLE_VALUE && dir->dd_stat == 0)
 	{
+		DWORD lasterr;
 		handle = FindFirstFileA(dir->dd_name, &buf);
-		DWORD lasterr = GetLastError();
+		lasterr = GetLastError();
 		dir->dd_handle = (long)handle;
 		if (handle == INVALID_HANDLE_VALUE && (lasterr != ERROR_NO_MORE_FILES)) {
 			errno = err_win_to_posix(lasterr);
diff --git a/help.c b/help.c
index 6c46d8b..399b0b4 100644
--- a/help.c
+++ b/help.c
@@ -127,7 +127,7 @@ static int is_executable(const char *name)
 		return 0;
 
 #ifdef __MINGW32__
-	/* cannot trust the executable bit, peek into the file instead */
+{	/* cannot trust the executable bit, peek into the file instead */
 	char buf[3] = { 0 };
 	int n;
 	int fd = open(name, O_RDONLY);
@@ -140,6 +140,7 @@ static int is_executable(const char *name)
 				st.st_mode |= S_IXUSR;
 		close(fd);
 	}
+}
 #endif
 	return st.st_mode & S_IXUSR;
 }
diff --git a/run-command.c b/run-command.c
index ff3d8e2..d1df7ab 100644
--- a/run-command.c
+++ b/run-command.c
@@ -123,6 +123,7 @@ int start_command(struct child_process *cmd)
 		exit(127);
 	}
 #else
+{
 	int s0 = -1, s1 = -1, s2 = -1;	/* backups of stdin, stdout, stderr */
 	const char **sargv = cmd->argv;
 	char **env = environ;
@@ -186,6 +187,7 @@ int start_command(struct child_process *cmd)
 		dup2(s1, 1), close(s1);
 	if (s2 >= 0)
 		dup2(s2, 2), close(s2);
+}
 #endif
 
 	if (cmd->pid < 0) {
-- 
1.6.4.msysgit.0
Frank Li· Aug 17, 2009, 16:01 UTC · re: Frank Li · lore

[PATCH 03/11] Define SNPRINTF_SIZE_CORR 1 when use MSVC build git

There are not NUL at vsnprintf verstion of MSVC when rearch max len. Define vsnprintf to _vsnprintf. vsnprintf have deprecated.

Signed-off-by: Frank Li <lznuaa@gmail.com>
---
 compat/snprintf.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)
Show changes to compat/snprintf.c +6 −1
diff --git a/compat/snprintf.c b/compat/snprintf.c
index 6c0fb05..47b2b8a 100644
--- a/compat/snprintf.c
+++ b/compat/snprintf.c
@@ -6,7 +6,7 @@
  * number of characters to write without the trailing NUL.
  */
 #ifndef SNPRINTF_SIZE_CORR
-#if defined(__MINGW32__) && defined(__GNUC__) && __GNUC__ < 4
+#if defined(__MINGW32__) && defined(__GNUC__) && __GNUC__ < 4 || defined(_MSC_VER)
 #define SNPRINTF_SIZE_CORR 1
 #else
 #define SNPRINTF_SIZE_CORR 0
@@ -14,6 +14,11 @@
 #endif
 
 #undef vsnprintf
+
+#if defined(_MSC_VER)
+#define vsnprintf _vsnprintf
+#endif
+
 int git_vsnprintf(char *str, size_t maxsize, const char *format, va_list ap)
 {
 	char *s;
-- 
1.6.4.msysgit.0
Frank Li· Aug 17, 2009, 16:01 UTC · re: Frank Li · lore

[PATCH 04/11] Add _MSC_VER predefine macro to make same behaviors with __MINGW32__ Enable MSVC build. MSVC have the save behaviors with msysgit.

Signed-off-by: Frank Li <lznuaa@gmail.com>
---
 help.c        |    2 +-
 pager.c       |    4 ++--
 run-command.c |    8 ++++----
 run-command.h |    2 +-
 setup.c       |    2 +-
 5 files changed, 9 insertions(+), 9 deletions(-)
Show changes to 5 files +9 −9

help.c, pager.c, run-command.c, run-command.h, setup.c

diff --git a/help.c b/help.c
index 399b0b4..a311241 100644
--- a/help.c
+++ b/help.c
@@ -126,7 +126,7 @@ static int is_executable(const char *name)
 	    !S_ISREG(st.st_mode))
 		return 0;
 
-#ifdef __MINGW32__
+#if defined(__MINGW32__) || defined(_MSC_VER)
 {	/* cannot trust the executable bit, peek into the file instead */
 	char buf[3] = { 0 };
 	int n;
diff --git a/pager.c b/pager.c
index 4921843..28122c5 100644
--- a/pager.c
+++ b/pager.c
@@ -9,7 +9,7 @@
 
 static int spawned_pager;
 
-#ifndef __MINGW32__
+#if !defined(__MINGW32__) && !defined(_MSC_VER)
 static void pager_preexec(void)
 {
 	/*
@@ -70,7 +70,7 @@ void setup_pager(void)
 	pager_argv[2] = pager;
 	pager_process.argv = pager_argv;
 	pager_process.in = -1;
-#ifndef __MINGW32__
+#if !defined(__MINGW32__) && !defined(_MSC_VER)
 	pager_process.preexec_cb = pager_preexec;
 #endif
 	if (start_command(&pager_process))
diff --git a/run-command.c b/run-command.c
index d1df7ab..df139da 100644
--- a/run-command.c
+++ b/run-command.c
@@ -67,7 +67,7 @@ int start_command(struct child_process *cmd)
 
 	trace_argv_printf(cmd->argv, "trace: run_command:");
 
-#ifndef __MINGW32__
+#if !defined(__MINGW32__) && !defined(_MSC_VER)
 	fflush(NULL);
 	cmd->pid = fork();
 	if (!cmd->pid) {
@@ -294,7 +294,7 @@ int run_command_v_opt_cd_env(const char **argv, int opt, const char *dir, const
 	return run_command(&cmd);
 }
 
-#ifdef __MINGW32__
+#if defined(__MINGW32__) || defined(_MSC_VER)
 static __stdcall unsigned run_thread(void *data)
 {
 	struct async *async = data;
@@ -310,7 +310,7 @@ int start_async(struct async *async)
 		return error("cannot create pipe: %s", strerror(errno));
 	async->out = pipe_out[0];
 
-#ifndef __MINGW32__
+#if !defined(__MINGW32__) && !defined(_MSC_VER)
 	/* Flush stdio before fork() to avoid cloning buffers */
 	fflush(NULL);
 
@@ -339,7 +339,7 @@ int start_async(struct async *async)
 
 int finish_async(struct async *async)
 {
-#ifndef __MINGW32__
+#if !defined(__MINGW32__) && !defined(_MSC_VER)
 	int ret = 0;
 
 	if (wait_or_whine(async->pid))
diff --git a/run-command.h b/run-command.h
index e345502..57a707b 100644
--- a/run-command.h
+++ b/run-command.h
@@ -79,7 +79,7 @@ struct async {
 	int (*proc)(int fd, void *data);
 	void *data;
 	int out;	/* caller reads from here and closes it */
-#ifndef __MINGW32__
+#if !defined(__MINGW32__) && !defined(_MSC_VER)
 	pid_t pid;
 #else
 	HANDLE tid;
diff --git a/setup.c b/setup.c
index e3781b6..14e3ca7 100644
--- a/setup.c
+++ b/setup.c
@@ -41,7 +41,7 @@ const char *prefix_path(const char *prefix, int len, const char *path)
 const char *prefix_filename(const char *pfx, int pfx_len, const char *arg)
 {
 	static char path[PATH_MAX];
-#ifndef __MINGW32__
+#if !defined(__MINGW32__) && !defined(_MSC_VER)
 	if (!pfx || !*pfx || is_absolute_path(arg))
 		return arg;
 	memcpy(path, pfx, pfx_len);
-- 
1.6.4.msysgit.0
Johannes Schindelin· Aug 17, 2009, 16:38 UTC · re: Frank Li · lore

Re: [PATCH 04/11] Add _MSC_VER predefine macro to make same behaviors with __MINGW32__ Enable MSVC build. MSVC have the save behaviors with msysgit.

Hi,
On Tue, 18 Aug 2009, Frank Li wrote:
> Signed-off-by: Frank Li <lznuaa@gmail.com>
How about
	Test whether WIN32 is defined rather than __MINGW32__
	The code which is conditional on MinGW32 is actually conditional 
	on Windows.  So test WIN32 rather than __MINGW32__.
	This does not break Cygwin builds, as WIN32 is undefined there.
	Suggested by Dmitry Potapov
?
Of course, you have to edit your patch accordingly, then.
And yes, I just tested, WIN32 is indeed defined on MinGw32.

Ciao, Dscho

Frank Li· Aug 18, 2009, 01:29 UTC · re: Johannes Schindelin · lore

Re: [PATCH 04/11] Add _MSC_VER predefine macro to make same behaviors with __MINGW32__ Enable MSVC build. MSVC have the save behaviors with msysgit.

>
> 	Test whether WIN32 is defined rather than __MINGW32__

I think WIN32 is better, how about 64bit build case? In 64bit environment, VC define WIN64 not WIN32.

tom fogal· Aug 18, 2009, 05:06 UTC · re: Frank Li · lore

Re: [PATCH 04/11] Add _MSC_VER predefine macro to make same behaviors with __MINGW32__ Enable MSVC build. MSVC have the save behaviors with msysgit.

Frank Li <lznuaa@gmail.com> writes:
Show 5 quoted lines
> >
> > 	Test whether WIN32 is defined rather than __MINGW32__
> 
> I think WIN32 is better, how about 64bit build case?
> In 64bit environment, VC define WIN64 not WIN32.

Actually, "_WIN32" is always defined using `cl', even in 64bit mode. 64bit compilation additionally defines "_WIN64", FWIW.

-tom
Johannes Schindelin· Aug 17, 2009, 16:32 UTC · re: Frank Li · lore

Re: [PATCH 03/11] Define SNPRINTF_SIZE_CORR 1 when use MSVC build git

Hi,
On Tue, 18 Aug 2009, Frank Li wrote:
> There are not NUL at vsnprintf verstion of MSVC when rearch max len.
> Define vsnprintf to _vsnprintf. vsnprintf have deprecated.
How about this instead?
	Define SNPRINTF_SIZE_CORR=1 for Microsoft Visual C++
	The Microsoft C runtime's vsnprintf function does not add NUL at 
	the end of the buffer.
	Further, Microsoft deprecated vsnprintf in favor of _vsnprintf, so 
	add a #define to that end.

The patch is good, although I suspect that the definition of vsnprintf is better handled in the precompiler options in .vcproj.

Ciao, Dscho

Frank Li· Aug 18, 2009, 01:19 UTC · re: Johannes Schindelin · lore

Re: [PATCH 03/11] Define SNPRINTF_SIZE_CORR 1 when use MSVC build git

Show 9 quoted lines
> How about this instead?
>
> 	Define SNPRINTF_SIZE_CORR=1 for Microsoft Visual C++
>
> 	The Microsoft C runtime's vsnprintf function does not add NUL at
> 	the end of the buffer.
>
> 	Further, Microsoft deprecated vsnprintf in favor of _vsnprintf, so
> 	add a #define to that end.
Of course,  do you need me change commit comment and resend patch?
>
> The patch is good, although I suspect that the definition of vsnprintf is
> better handled in the precompiler options in .vcproj.
>

If define in .vcproj, it needs copy that to DEBUG\RELEASE and 32bit\64bit (2x2) 4 places. It is easy to miss one.

> Ciao,
> Dscho
>
Johannes Schindelin· Aug 18, 2009, 09:31 UTC · re: Frank Li · lore

Re: [PATCH 03/11] Define SNPRINTF_SIZE_CORR 1 when use MSVC build git

Hi,
On Tue, 18 Aug 2009, Frank Li wrote:
Show 11 quoted lines
> > How about this instead?
> >
> > 	Define SNPRINTF_SIZE_CORR=1 for Microsoft Visual C++
> >
> > 	The Microsoft C runtime's vsnprintf function does not add NUL at
> > 	the end of the buffer.
> >
> > 	Further, Microsoft deprecated vsnprintf in favor of _vsnprintf, so
> > 	add a #define to that end.
> 
> Of course,  do you need me change commit comment and resend patch?

I think it would be best if you could rewrite your vcpatch branch using the new commit message.

Show 5 quoted lines
> > The patch is good, although I suspect that the definition of vsnprintf 
> > is better handled in the precompiler options in .vcproj.
> 
> If define in .vcproj, it needs copy that to DEBUG\RELEASE and 
> 32bit\64bit (2x2) 4 places. It is easy to miss one.
No, there are the common precompiler options, too.

But maybe it is better to leave the #define's in a header file for another reason: better visibility (I always hated it that I had to open the project files in a text editor in order to find the settings with Visual Studio, the GUI seems to be designed by a fan of hide-and-seek).

Ciao, Dscho

Johannes Schindelin· Aug 17, 2009, 16:29 UTC · re: Frank Li · lore

Re: [PATCH 02/11] Fix declare variable at mid of function

Hi,
On Tue, 18 Aug 2009, Frank Li wrote:
> Some compiler such as MSVC can't support declear variable at mid of funtion at c file.
Please wrap your commit messages after 76 characters.
> 
> Signed-off-by: Frank Li <lznuaa@gmail.com>
> ---
How about this instead?
	Avoid declaration after instruction
	Microsoft Visual C++ does not understand this C99 style.
?
The patch itself is good.

Ciao, Dscho

Reece Dunn· Aug 17, 2009, 16:34 UTC · re: Johannes Schindelin · lore

Re: [PATCH 02/11] Fix declare variable at mid of function

2009/8/17 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
Show 21 quoted lines
> Hi,
>
> On Tue, 18 Aug 2009, Frank Li wrote:
>
>> Some compiler such as MSVC can't support declear variable at mid of funtion at c file.
>
> Please wrap your commit messages after 76 characters.
>
>>
>> Signed-off-by: Frank Li <lznuaa@gmail.com>
>> ---
>
> How about this instead?
>
>        Avoid declaration after instruction
>
>        Microsoft Visual C++ does not understand this C99 style.
>
> ?
>
> The patch itself is good.

Shouldn't GCC be changed to use -std=c89 as well to pick up errors for compilers that don't support c99 (like the Microsoft Visual C++ C compiler)?

- Reece
Johannes Schindelin· Aug 17, 2009, 19:36 UTC · re: Reece Dunn · lore

Re: [PATCH 02/11] Fix declare variable at mid of function

Hi,
On Mon, 17 Aug 2009, Reece Dunn wrote:
Show 26 quoted lines
> 2009/8/17 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > On Tue, 18 Aug 2009, Frank Li wrote:
> >
> >> Some compiler such as MSVC can't support declear variable at mid of 
> >> funtion at c file.
> >
> > Please wrap your commit messages after 76 characters.
> >
> >>
> >> Signed-off-by: Frank Li <lznuaa@gmail.com>
> >> ---
> >
> > How about this instead?
> >
> >        Avoid declaration after instruction
> >
> >        Microsoft Visual C++ does not understand this C99 style.
> >
> > ?
> >
> > The patch itself is good.
> 
> Shouldn't GCC be changed to use -std=c89 as well to pick up errors for 
> compilers that don't support c99 (like the Microsoft Visual C++ C 
> compiler)?

Hmm. I played with the thought of adding -Werror -Wno-pointer-to-int-cast -Wold-style-definition -Wdeclaration-after-statement like Junio described in one of his mails for MinGW (as we _know_ what compiler we have there).

Dunno.

Ciao, Dscho

Marius Storm-Olsen· Aug 18, 2009, 05:23 UTC · re: Johannes Schindelin · lore

Re: [msysGit] Re: [PATCH 02/11] Fix declare variable at mid of function

Johannes Schindelin said the following on 17.08.2009 21:36:
Show 32 quoted lines
> Hi,
> 
> On Mon, 17 Aug 2009, Reece Dunn wrote:
> 
>> 2009/8/17 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>
>>> On Tue, 18 Aug 2009, Frank Li wrote:
>>>
>>>> Some compiler such as MSVC can't support declear variable at mid of 
>>>> funtion at c file.
>>> Please wrap your commit messages after 76 characters.
>>>
>>>> Signed-off-by: Frank Li <lznuaa@gmail.com>
>>>> ---
>>> How about this instead?
>>>
>>>        Avoid declaration after instruction
>>>
>>>        Microsoft Visual C++ does not understand this C99 style.
>>>
>>> ?
>>>
>>> The patch itself is good.
>> Shouldn't GCC be changed to use -std=c89 as well to pick up errors for 
>> compilers that don't support c99 (like the Microsoft Visual C++ C 
>> compiler)?
> 
> Hmm.  I played with the thought of adding -Werror -Wno-pointer-to-int-cast 
> -Wold-style-definition -Wdeclaration-after-statement like Junio described 
> in one of his mails for MinGW (as we _know_ what compiler we have there).
> 
> Dunno.
IMO it would be a good change. We should  not have any of those anyways..

-- .marius

Johannes Schindelin· Aug 18, 2009, 09:34 UTC · re: Marius Storm-Olsen · lore

Re: [msysGit] Re: [PATCH 02/11] Fix declare variable at mid of function

Hi,
On Tue, 18 Aug 2009, Marius Storm-Olsen wrote:
Show 34 quoted lines
> Johannes Schindelin said the following on 17.08.2009 21:36:
> 
> > On Mon, 17 Aug 2009, Reece Dunn wrote:
> > 
> > > 2009/8/17 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> > >
> > > > On Tue, 18 Aug 2009, Frank Li wrote:
> > > >
> > > > > Some compiler such as MSVC can't support declear variable at mid of
> > > > > funtion at c file.
> > > > Please wrap your commit messages after 76 characters.
> > > >
> > > > > Signed-off-by: Frank Li <lznuaa@gmail.com>
> > > > > ---
> > > > How about this instead?
> > > >
> > > >        Avoid declaration after instruction
> > > >
> > > >        Microsoft Visual C++ does not understand this C99 style.
> > > >
> > > > ?
> > > >
> > > > The patch itself is good.
> > > Shouldn't GCC be changed to use -std=c89 as well to pick up errors for
> > > compilers that don't support c99 (like the Microsoft Visual C++ C
> > > compiler)?
> > 
> > Hmm.  I played with the thought of adding -Werror -Wno-pointer-to-int-cast
> > -Wold-style-definition -Wdeclaration-after-statement like Junio described in
> > one of his mails for MinGW (as we _know_ what compiler we have there).
> > 
> > Dunno.
> 
> IMO it would be a good change. We should  not have any of those anyways..

Okay, I will wait for Frank's updates (just fetched tgit.git and it still contains the old branch), merge the early part and add the compiler flags.

Ciao, Dscho

Frank Li· Aug 18, 2009, 16:11 UTC · re: Johannes Schindelin · lore

Re: [msysGit] Re: [PATCH 02/11] Fix declare variable at mid of function

> Okay, I will wait for Frank's updates (just fetched tgit.git and it still
> contains the old branch), merge the early part and add the compiler flags.
>

Today, I just update 5 patch according review feedback. Do I need send it again?

I have push my change to tgit git://repo.or.cz/tgit.git branch vcpatch2

How do I know if patch has been applied main line?
Matthieu Moy· Aug 18, 2009, 16:52 UTC · re: Frank Li · lore

Re: [msysGit] Re: [PATCH 02/11] Fix declare variable at mid of function

Frank Li <lznuaa@gmail.com> writes:
Show 5 quoted lines
>> Okay, I will wait for Frank's updates (just fetched tgit.git and it still
>> contains the old branch), merge the early part and add the compiler flags.
>>
> Today, I just update 5 patch according review feedback.
> Do I need send it again?

Yes, this is the use here. Preferably edit the message to replace [PATCH] with [PATCH v2] or so.

> How do I know if patch has been applied main line?

Answering the question with another: shouldn't we add a section like this to SubmittingPatches ?

>From 3ee45ab5992fd084c130460f07454061ce3cf057 Mon Sep 17 00:00:00 2001
From: Matthieu Moy <Matthieu.Moy@imag.fr>
Date: Tue, 18 Aug 2009 18:48:47 +0200
Subject: [PATCH] SubmittingPatches: draft section to know patches status
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
 Documentation/SubmittingPatches |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)
Show changes to Documentation/SubmittingPatches +14 −0
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 76fc84d..c686f86 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -280,6 +280,20 @@ people play with it without having to pick up and apply the patch to
 their trees themselves.
 
 ------------------------------------------------
+Know the status of your patch after submission
+
+* You can use Git itself to find out when your patch is merged in
+  master. 'git pull --rebase' will automatically skip already-applied
+  patches, and will let you know. This works only if you rebase on top
+  of the branch in which your patch has been merged (i.e. it will not
+  tell you if your patch is merged in pu if you rebase on top of
+  master).
+
+* Read the git mailing list, the maintainer regularly posts messages
+  entitled "What's cooking in git.git" and "What's in git.git" giving
+  the status of various proposed changes.
+
+------------------------------------------------
 MUA specific hints
 
 Some of patches I receive or pick up from the list share common
-- 
1.6.4.313.g38b9



-- 
Matthieu
Johannes Schindelin· Aug 19, 2009, 10:15 UTC · re: Frank Li · lore

Re: [msysGit] Re: [PATCH 02/11] Fix declare variable at mid of function

On Wed, 19 Aug 2009, Frank Li wrote:
Show 11 quoted lines
> > Okay, I will wait for Frank's updates (just fetched tgit.git and it still
> > contains the old branch), merge the early part and add the compiler flags.
> >
> Today, I just update 5 patch according review feedback.
> Do I need send it again?
> 
> I have push my change to tgit
> git://repo.or.cz/tgit.git
> branch vcpatch2
> 
> How do I know if patch has been applied main line?

I applied them to 4msysgit.git's devel. Note that I had a strange merge conflict in pager.c: you replaced and #ifndef __MINGW32__ with an #ifndef WIN32, but I don't have that #ifndef at all.

Ciao, Dscho

Johannes Sixt· Aug 19, 2009, 10:55 UTC · re: Johannes Schindelin · lore

Re: [msysGit] Re: [PATCH 02/11] Fix declare variable at mid of function

Johannes Schindelin schrieb:
Show 10 quoted lines
> On Wed, 19 Aug 2009, Frank Li wrote:
>> I have push my change to tgit
>> git://repo.or.cz/tgit.git
>> branch vcpatch2
>>
>> How do I know if patch has been applied main line?
> 
> I applied them to 4msysgit.git's devel.  Note that I had a strange merge 
> conflict in pager.c: you replaced and #ifndef __MINGW32__ with an #ifndef 
> WIN32, but I don't have that #ifndef at all.

4msysgit has my "Windows: Better support PAGER settings with spaces in the path", which removes the #ifndefs, Frank's version doesn't have it. Therefore, you should not rebase Frank's patches on top of 4msysgit's master or devel before they are merged into git.git.

-- Hannes
Johannes Schindelin· Aug 19, 2009, 13:15 UTC · re: Johannes Sixt · lore

Re: [PATCH 02/11] Fix declare variable at mid of function

Hi,
On Wed, 19 Aug 2009, Johannes Sixt wrote:
Show 16 quoted lines
> Johannes Schindelin schrieb:
> > On Wed, 19 Aug 2009, Frank Li wrote:
> >> I have push my change to tgit
> >> git://repo.or.cz/tgit.git
> >> branch vcpatch2
> >>
> >> How do I know if patch has been applied main line?
> > 
> > I applied them to 4msysgit.git's devel.  Note that I had a strange 
> > merge conflict in pager.c: you replaced and #ifndef __MINGW32__ with 
> > an #ifndef WIN32, but I don't have that #ifndef at all.
> 
> 4msysgit has my "Windows: Better support PAGER settings with spaces in 
> the path", which removes the #ifndefs, Frank's version doesn't have it. 
> Therefore, you should not rebase Frank's patches on top of 4msysgit's 
> master or devel before they are merged into git.git.

Well, I wanted to give them a little bit more visibility by putting them into 4msysgit.git, as I think the best way to get Microsoft Visual C++ support into git.git _is_ via 4msysgit.git.

Ciao, Dscho

Johannes Sixt· Aug 19, 2009, 15:21 UTC · re: Johannes Schindelin · lore

Re: [msysGit] Re: [PATCH 02/11] Fix declare variable at mid of function

Johannes Schindelin schrieb:
Show 19 quoted lines
> On Wed, 19 Aug 2009, Johannes Sixt wrote:
>> Johannes Schindelin schrieb:
>>> On Wed, 19 Aug 2009, Frank Li wrote:
>>>> I have push my change to tgit
>>>> git://repo.or.cz/tgit.git
>>>> branch vcpatch2
>>>>
>>>> How do I know if patch has been applied main line?
>>> I applied them to 4msysgit.git's devel.  Note that I had a strange 
>>> merge conflict in pager.c: you replaced and #ifndef __MINGW32__ with 
>>> an #ifndef WIN32, but I don't have that #ifndef at all.
>> 4msysgit has my "Windows: Better support PAGER settings with spaces in 
>> the path", which removes the #ifndefs, Frank's version doesn't have it. 
>> Therefore, you should not rebase Frank's patches on top of 4msysgit's 
>> master or devel before they are merged into git.git.
> 
> Well, I wanted to give them a little bit more visibility by putting them 
> into 4msysgit.git, as I think the best way to get Microsoft Visual C++ 
> support into git.git _is_ via 4msysgit.git.

Even more so should you keep the original patches (in this case at least), not rebased ones. It is unlikely that "Windows: Better support PAGER..." will be in git.git _before_ Frank's MINGW32->WIN32 conversion patch.

-- Hannes
Junio C Hamano· Aug 17, 2009, 19:28 UTC · re: Johannes Schindelin · lore

Re: [PATCH 02/11] Fix declare variable at mid of function

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> How about this instead?
>
> 	Avoid declaration after instruction
It's called declaration-after-statement.

I always compile with "-Wall -Wdeclaration-after-statement -Werror" (among other things; if you are interested, see "Make" script in 'todo' branch for details) but this being in compat/mingw.c, obviously it is outside of my coverage.

Johannes Schindelin· Aug 17, 2009, 21:00 UTC · re: Junio C Hamano · lore

Re: [msysGit] Re: [PATCH 02/11] Fix declare variable at mid of function

Hi,
On Mon, 17 Aug 2009, Junio C Hamano wrote:
Show 7 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > How about this instead?
> >
> > 	Avoid declaration after instruction
> 
> It's called declaration-after-statement.
Of course.  Thank you.
> I always compile with "-Wall -Wdeclaration-after-statement -Werror" 
> (among other things; if you are interested, see "Make" script in 'todo' 
> branch for details) but this being in compat/mingw.c, obviously it is 
> outside of my coverage.

I have this in my own tree since long ago, back when you sent a mail whose reference I did not record, unfortunately.

Of course, msysGit was not there yet to allow me to compile my tree (and more importantly, pass the test suite), so I did not realize the violations in compat/.

Hence my intention to set the compiler flags just after merging the early commits of Frank's work.

Ciao, Dscho

Junio C Hamano· Aug 17, 2009, 21:38 UTC · re: Johannes Schindelin · lore

Re: [msysGit] Re: [PATCH 02/11] Fix declare variable at mid of function

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 6 quoted lines
> Of course, msysGit was not there yet to allow me to compile my tree (and 
> more importantly, pass the test suite), so I did not realize the 
> violations in compat/.
>
> Hence my intention to set the compiler flags just after merging the early 
> commits of Frank's work.
Sounds very sensible.
Johannes Schindelin· Aug 17, 2009, 16:26 UTC · re: Frank Li · lore

Re: [PATCH 01/11] Fix build failure at VC because function declare use old style at regex.c

Hi,

reading "X-Mailer: git-send-email 1.6.4.msysgit.0" gave me a buzz... well done, Erik!

On Tue, 18 Aug 2009, Frank Li wrote:
> regerror declare function argument type after function define.
> 
> Signed-off-by: Frank Li <lznuaa@gmail.com>
How about
	Avoid a K&R style function definition in regex.c
	Microsoft Visual C++ does not understand K&R notation; use C89 
	style instead.
?
Show 14 quoted lines
> diff --git a/compat/regex/regex.c b/compat/regex/regex.c
> index 5ea0075..5728de1 100644
> --- a/compat/regex/regex.c
> +++ b/compat/regex/regex.c
> @@ -4852,11 +4852,7 @@ regexec (preg, string, nmatch, pmatch, eflags)
>     from either regcomp or regexec.   We don't use PREG here.  */
>  
>  size_t
> -regerror (errcode, preg, errbuf, errbuf_size)
> -    int errcode;
> -    const regex_t *preg;
> -    char *errbuf;
> -    size_t errbuf_size;
> +regerror (int errcode, const regex_t * preg, char * errbuf,size_t errbuf_size)
A cursory look over regex.c gives me the impression that
- it tries to stick to maximally 80 characters per line,
- there is no space after a * indicating a pointer,
- there are spaces after all commas,
- there are a lot more functions with K&R style function definitions than 
  just regerror().

Ciao, Dscho

Frank Li· Aug 18, 2009, 15:03 UTC · re: Johannes Schindelin · lore

Re: [PATCH 01/11] Fix build failure at VC because function declare use old style at regex.c

 - there are a lot more functions with K&R style function definitions than
>  just regerror().
>
I double check it. VC can compile K&R style function. This patch is redundancy

← back to recent threads