Gary V. Vaughan wrote: > On Tue, Apr 27, 2010 at 06:08:58PM +0200, Tor Arntsen wrote: >> On Tue, Apr 27, 2010 at 15:57, Gary V. Vaughan <git@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote: >>> enum style is inconsistent already, with some enums declared on one >>> line, some over 3 lines with the enum values all on the middle line, >>> sometimes with 1 enum value per line... and independently of that the >>> trailing comma is sometimes present and other times absent, often >>> mixing with/without trailing comma styles in a single file, and >>> sometimes in consecutive enum declarations. >>> >>> Clearly, omitting the comma is the more portable style, and this patch >>> changes all enum declarations to use the portable omitted dangling >>> comma style consistently. >> The patch is against master. Are we supposed to make patches against >> master or maint? (I thought I saw the latter somewhere. I'm pretty >> new in here though..) > > No, the patch is against the latest 7.1.1 stable release (not yet shown > on the website last time I checked, however): > > http://www.kernel.org/pub/software/scm/git/git-1.7.1.tar.bz2 Ok. That would correspond to master from git anyway. I make my patches against a git checkout, and I was just throwing out the question to the general audience, for my own knowledge. [..] with -pthread, which won't work for this system. > > Did you apply the whole series of patches? If so, then it is a bug in > my pthread.patch if --enable-pthreads=-lpthreads is necessary. This > configure line builds successfully on all the architectures I have > access to (note, pthread support is probed automatically by configure): No, I only applied and tested the enum patch. I looked through those patches I mentioned though. Looks fine to me. [..] >> 2: The compiler cannot build on AIX 5.1 without the following >> additional patch (against master. maint has similar problems but >> files have been moved): > > I maintained a similar patch for our packaging of older git releases > too, but noticed that it wasn't necessary on our machines anymore... > perhaps recent compiler patches on our hosts have relaxed the > requirement for non-C++ comment syntax? That could be. I have this exact version (5.0.2) because of software we build for some customers. We need to have exactly the same compilers (as we provide source as well). There are always certain bugs and issues with different versions of compilers, so we and the customers figure out the issues with them and then rigidly stick to a specific version fromthen on (until we may have to evaluate another version, for different reasons). > However, I do confirm that this is a problem I have encountered in the > past. If you check the Git log for the git repo you'll see that there have been similar patches in the past, it looks like the C99 comments fixed in my patch has just managed to sneak by since then. -Tor >> From a8989213b4c8baa53c14c1f227b916910265c517 Mon Sep 17 00:00:00 2001 >> From: Tor Arntsen <tor@xxxxxxxxxxx> >> Date: Tue, 27 Apr 2010 16:05:12 +0000 >> Subject: [PATCH 2/2] C99 comments changed to old-style C comments >> >> Signed-off-by: Tor Arntsen <tor@xxxxxxxxxxx> >> --- >> builtin/blame.c | 2 +- >> builtin/for-each-ref.c | 4 ++-- >> remote.c | 2 +- >> 3 files changed, 4 insertions(+), 4 deletions(-) > > Cheers, -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html