* Re: [PATCH] Remove more gcc extension usage.
From: Shawn Pearce @ 2006-07-08 19:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7v4orpt.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > Removing these last remaining extension uses allows GIT to compile
> > with the Sun C compiler rather then gcc. This can be handy when
> > you are trying to compile GIT on a Solaris system that seems to
> > have a total lack of GNU utilities.
>
> Two points.
>
> - Aren't the constructs you ripped out not GCC extension,
> rather proper ISO C99?
Hmm. I'm not sure actually. I don't do much C hacking these days
so I haven't kept current with what C99 has and doesn't. I just
know that these small changes made the core plumbing build and run
fine on Solaris with only GNU make being present. I didn't even
attempt to use the higher level Poreclainish shell script commands.
Monday I'll look to see if there's an option that can be given to
the Solaris compiler to make it accept these constructs. Maybe a
simple CFLAGS change in my config.mak would resolve what this patch
was trying to do.
> - Our Makefile is pretty GNU already. I think people have
> pointed out and ripped out bashisms from our shell scripts,
> but I would not be surprised if the default Sun /bin/sh does
> not understand POSIXy features some of them use.
I realize that. Asking someone to compile GNU make in their home
directory before they build GIT to their home directory isn't a
big deal (took me all of 30 seconds to download the latest and
./configure&&make install it). Asking someone to download and
compile binutils and gcc because their local site manager won't
install them for you is another matter entirely...
--
Shawn.
^ permalink raw reply
* Re: gitweb/test/Marchen always untracked?
From: Johannes Schindelin @ 2006-07-08 19:36 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607082058340.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
On Sat, 8 Jul 2006, Johannes Schindelin wrote:
> On Sat, 8 Jul 2006, Shawn Pearce wrote:
>
> > I'm not sure what is going on here but on my Mac OS X system
> > the file `gitweb/test/Marchen` is always untracked:
>
> Will investigate,
And so I did. It seems the problem is not reading, but _writing_.
> touch $(echo -e 'M\xc3\xa4rchen')
> ls *en|hexdump -C
00000000 4d 61 cc 88 72 63 68 65 6e 0a |Ma..rchen.|
0000000a
So, instead of writing "4d c3 a4 72 63 68 65 6e" it actually writes "4d 61
cc 88 72 63 68 65 6e". It might be possible that this is some
"intelligent" encoding mapping, but ...
> echo $LC_ALL
de-DE.utf-8
... so I think Mac OS X is wrong.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Replace sed with perl when setting up perl scripts.
From: Shawn Pearce @ 2006-07-08 19:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
next appears to be broken on MacOS X:
INSTLIBDIR=`make -C perl -s --no-print-directory instlibdir` && \
sed -e '1s|#!.*perl|#!/usr/bin/perl|1' \
-e '2i\
use lib (split(/:/, $ENV{GITPERLLIB} || '\'"$INSTLIBDIR"\''));' \
-e 's|@@INSTLIBDIR@@|'"$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/1.4.1.g659a/g' \
git-archimport.perl >git-archimport+
sed: 1: "2i use lib (split(/:/, ...": command i expects \ followed by text
make: *** [git-archimport] Error 1
I just spent half an hour messing around with the relevant Makefile
rule to try and get sed to be happy with this and I can't find the
magic necessary. So I ported the sed to perl. :-)
-->>-
Replace sed with perl when setting up perl scripts.
The sed magic to insert 'use lib' at the start of all
GIT Perl scripts wasn't working correctly on Mac OS X.
Replacing the sed invocations with perl invocations is
much more portable.
The replacement also has no negative impact on the build
as GIT cannot be compiled without the Git perl module,
which implies that perl is available and works.
---
Makefile | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index 8d429a0..e83d298 100644
--- a/Makefile
+++ b/Makefile
@@ -557,11 +557,12 @@ common-cmds.h: Documentation/git-*.txt
$(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
rm -f $@ $@+
INSTLIBDIR=`$(MAKE) -C perl -s --no-print-directory instlibdir` && \
- sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|1' \
- -e '2i\
- use lib (split(/:/, $$ENV{GITPERLLIB} || '\'"$$INSTLIBDIR"\''));' \
- -e 's|@@INSTLIBDIR@@|'"$$INSTLIBDIR"'|g' \
- -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
+ $(PERL_PATH) -e '$$_=<>;print q{#!$(PERL_PATH_SQ)},qq{\n};' \
+ -e 'print q{use lib (split(/:/, $$ENV{GITPERLLIB} || '\'"$$INSTLIBDIR"\''));},qq{\n};' \
+ -e 'while(<>){' \
+ -e 's|@@INSTLIBDIR@@|'"$$INSTLIBDIR"'|g;' \
+ -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g;' \
+ -e 'print;}' \
$@.perl >$@+
chmod +x $@+
mv $@+ $@
--
1.4.1.gc48f
^ permalink raw reply related
* [PATCH 2] Teach make clean about configure and autoconf
From: Jakub Narebski @ 2006-07-08 21:07 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <200607030156.50455.jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Part of this patch is needed also for handcrafted ./configure script
(if not already przesent in some patch of those series)
Makefile | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 3c2c257..200e58a 100644
--- a/Makefile
+++ b/Makefile
@@ -749,6 +749,8 @@ clean:
$(LIB_FILE) $(XDIFF_LIB)
rm -f $(ALL_PROGRAMS) $(BUILT_INS) git$X
rm -f *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags
+ rm -rf autom4te.cache configure config.status config.cache
+ rm -f config.log config.mak.autogen
rm -rf $(GIT_TARNAME) .doc-tmp-dir
rm -f $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz
rm -f $(htmldocs).tar.gz $(manpages).tar.gz
--
1.4.0
^ permalink raw reply related
* [RFC/PATCH 3] Copy description of build configuration variables to configure.ac
From: Jakub Narebski @ 2006-07-08 21:07 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1152392835436-git-send-email-jnareb@gmail.com>
Copy description of build configuration variables from the commentary
in the top Makefile (from 'next' branch) to configure.ac, splitting
them into "autoconf" sections.
This is to be able to easily check which build/install configuration
variables are covered by current configure.ac
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Please correct this if you feel that some variable was put in wrong
section in configure.ac
configure.ac | 114 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 113 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index cecdbe5..6fe5013 100644
--- a/configure.ac
+++ b/configure.ac
@@ -9,6 +9,118 @@ AC_CONFIG_SRCDIR([git.c])
config_file=config.mak.autogen
config_in=config.mak.in
-# Output files
+
+## Checks for programs.
+# Define NO_PYTHON if you want to loose all benefits of the recursive merge.
+
+
+## Checks for libraries.
+# Define NO_OPENSSL environment variable if you do not have OpenSSL.
+# This also implies MOZILLA_SHA1.
+#
+# Define NO_CURL if you do not have curl installed. git-http-pull and
+# git-http-push are not built, and you cannot use http:// and https://
+# transports.
+#
+# Define NO_EXPAT if you do not have expat installed. git-http-push is
+# not built, and you cannot push using http:// and https:// transports.
+#
+# Define NEEDS_SSL_WITH_CRYPTO if you need -lcrypto with -lssl (Darwin).
+#
+# Define NEEDS_LIBICONV if linking with libc is not enough (Darwin).
+#
+# Define NEEDS_SOCKET if linking with libc is not enough (SunOS,
+# Patrick Mauritz).
+
+
+## Checks for header files.
+
+
+## Checks for typedefs, structures, and compiler characteristics.
+# Define NO_D_INO_IN_DIRENT if you don't have d_ino in your struct dirent.
+#
+# Define NO_D_TYPE_IN_DIRENT if your platform defines DT_UNKNOWN but lacks
+# d_type in struct dirent (latest Cygwin -- will be fixed soonish).
+#
+# Define NO_SOCKADDR_STORAGE if your platform does not have struct
+# sockaddr_storage.
+
+
+## Checks for library functions.
+# Define NO_STRCASESTR if you don't have strcasestr.
+#
+# Define NO_STRLCPY if you don't have strlcpy.
+#
+# Define NO_SETENV if you don't have setenv in the C library.
+#
+# Define NO_MMAP if you want to avoid mmap.
+#
+# Define NO_IPV6 if you lack IPv6 support and getaddrinfo().
+#
+# Define NO_ICONV if your libc does not properly support iconv.
+
+
+## Other checks.
+# Define USE_PIC if you need the main git objects to be built with -fPIC
+# in order to build and link perl/Git.so. x86-64 seems to need this.
+#
+# Define NO_SYMLINK_HEAD if you never want .git/HEAD to be a symbolic link.
+# Enable it on Windows. By default, symrefs are still used.
+#
+# Define WITH_OWN_SUBPROCESS_PY if you want to use with python 2.3.
+#
+# Define NO_ACCURATE_DIFF if your diff program at least sometimes misses
+# a missing newline at the end of the file.
+
+
+## Site configuration
+## --with-PACKAGE[=ARG] and --without-PACKAGE
+# Define NO_SVN_TESTS if you want to skip time-consuming SVN interopability
+# tests. These tests take up a significant amount of the total test time
+# but are not needed unless you plan to talk to SVN repos.
+#
+# Define MOZILLA_SHA1 environment variable when running make to make use of
+# a bundled SHA1 routine coming from Mozilla. It is GPL'd and should be fast
+# on non-x86 architectures (e.g. PowerPC), while the OpenSSL version (default
+# choice) has very fast version optimized for i586.
+#
+# Define PPC_SHA1 environment variable when running make to make use of
+# a bundled SHA1 routine optimized for PowerPC.
+#
+# Define ARM_SHA1 environment variable when running make to make use of
+# a bundled SHA1 routine optimized for ARM.
+#
+# Define NO_OPENSSL environment variable if you do not have OpenSSL.
+# This also implies MOZILLA_SHA1.
+#
+# Define NO_CURL if you do not have curl installed. git-http-pull and
+# git-http-push are not built, and you cannot use http:// and https://
+# transports.
+#
+# Define CURLDIR=/foo/bar if your curl header and library files are in
+# /foo/bar/include and /foo/bar/lib directories.
+#
+# Define NO_EXPAT if you do not have expat installed. git-http-push is
+# not built, and you cannot push using http:// and https:// transports.
+#
+# Define NO_MMAP if you want to avoid mmap.
+#
+# Define NO_PYTHON if you want to loose all benefits of the recursive merge.
+#
+## --enable-FEATURE[=ARG] and --disable-FEATURE
+# Define COLLISION_CHECK below if you believe that SHA1's
+# 1461501637330902918203684832716283019655932542976 hashes do not give you
+# sufficient guarantee that no collisions between objects will ever happen.
+#
+# Define USE_NSEC below if you want git to care about sub-second file mtimes
+# and ctimes. Note that you need recent glibc (at least 2.2.4) for this, and
+# it will BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely
+# randomly break unless your underlying filesystem supports those sub-second
+# times (my ext3 doesn't).
+#
+# Define USE_STDEV below if you want git to care about the underlying device
+# change being considered an inode change from the update-cache perspective.
+
+## Output files
AC_CONFIG_FILES(["${config_file}":"${config_in}"])
AC_OUTPUT
--
1.4.0
^ permalink raw reply related
* [PATCH 5] autoconf: Checks for typedefs, structures, and compiler characteristics.
From: Jakub Narebski @ 2006-07-08 21:07 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1152392836910-git-send-email-jnareb@gmail.com>
./configure script checks now for existence of the following types,
structures, and structure members:
* dirent.d_ino in <dirent.h> (NO_D_INO_IN_DIRENT)
* dirent.d_type in <dirent.h> (NO_D_TYPE_IN_DIRENT)
* 'struct sockaddr_storage' in <netinet/in.h> (NO_SOCKADDR_STORAGE)
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
If on some systems other headers than written above are needed for specified
types definitions, then it should be added to those tests.
configure.ac | 15 +++++++++++++--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index e68d416..cb81258 100644
--- a/configure.ac
+++ b/configure.ac
@@ -48,13 +48,24 @@ ## Checks for header files.
## Checks for typedefs, structures, and compiler characteristics.
+AC_MSG_NOTICE([CHECKS for typedefs, structures, and compiler characteristics])
+
# Define NO_D_INO_IN_DIRENT if you don't have d_ino in your struct dirent.
-#
+AC_CHECK_MEMBER(struct dirent.d_ino,[],
+GIT_CONF_APPEND_LINE(NO_D_INO_IN_DIRENT=YesPlease),
+[#include <dirent.h>])
+
# Define NO_D_TYPE_IN_DIRENT if your platform defines DT_UNKNOWN but lacks
# d_type in struct dirent (latest Cygwin -- will be fixed soonish).
-#
+AC_CHECK_MEMBER(struct dirent.d_type,[],
+GIT_CONF_APPEND_LINE(NO_D_TYPE_IN_DIRENT=YesPlease),
+[#include <dirent.h>])
+
# Define NO_SOCKADDR_STORAGE if your platform does not have struct
# sockaddr_storage.
+AC_CHECK_TYPE(struct sockaddr_storage,[],
+GIT_CONF_APPEND_LINE(NO_SOCKADDR_STORAGE=YesPlease),
+[#include <netinet/in.h>])
## Checks for library functions.
--
1.4.0
^ permalink raw reply related
* [RFC/PATCH 4] autoconf: Preparing the way for autodetection
From: Jakub Narebski @ 2006-07-08 21:07 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11523928361444-git-send-email-jnareb@gmail.com>
Prepares configure.ac to output autodetected and selected (by using
--with/--without and --enable/disable parameters to generated
./configure script) building configuration in "git style", i.e. by
appending appropriate variables to output file config.mak.autogen
(via temporary file config.mak.append).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This series of patches tries to build _optional_ automatic build
and install configuration, using existing build configuration
variables, and not making changes to Makefile.
Series of patches 4-8 adds automatic detection of compilation
configuration (those which I could write easily).
configure.ac | 19 +++++++++++++++++--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 6fe5013..e68d416 100644
--- a/configure.ac
+++ b/configure.ac
@@ -7,8 +7,19 @@ AC_INIT([git], [1.4.1], [git@vger.kernel
AC_CONFIG_SRCDIR([git.c])
config_file=config.mak.autogen
+config_append=config.mak.append
config_in=config.mak.in
+echo "# ${config_append}. Generated by configure." > "${config_append}"
+
+
+## Definitions of macros
+# GIT_CONF_APPEND_LINE(LINE)
+# --------------------------
+# Append LINE to file ${config_append}
+AC_DEFUN([GIT_CONF_APPEND_LINE],
+[echo "$1" >> "${config_append}"])# GIT_CONF_APPEND_LINE
+
## Checks for programs.
# Define NO_PYTHON if you want to loose all benefits of the recursive merge.
@@ -73,7 +84,7 @@ # Define NO_ACCURATE_DIFF if your diff p
# a missing newline at the end of the file.
-## Site configuration
+## Site configuration
## --with-PACKAGE[=ARG] and --without-PACKAGE
# Define NO_SVN_TESTS if you want to skip time-consuming SVN interopability
# tests. These tests take up a significant amount of the total test time
@@ -121,6 +132,10 @@ #
# Define USE_STDEV below if you want git to care about the underlying device
# change being considered an inode change from the update-cache perspective.
+
## Output files
-AC_CONFIG_FILES(["${config_file}":"${config_in}"])
+AC_CONFIG_FILES(["${config_file}":"${config_in}":"${config_append}"])
AC_OUTPUT
+
+## Cleanup
+rm -f "${config_append}"
--
1.4.0
^ permalink raw reply related
* [RFC/PATCH 8] autoconf: Checks for some programs
From: Jakub Narebski @ 2006-07-08 21:07 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11523928373299-git-send-email-jnareb@gmail.com>
./configure script checks now for the following programs:
* CC - using AC_PROG_CC
* AR - using AC_CHECK_TOOL among ar
* TAR - among gtar, tar
Checks not implemented:
* INSTALL - needs install-sh or install.sh in sources
* RPMBUILD - not known alternatives for rpmbuild
* PYTHON - no PYTHON variable in Makefile,
has to set NO_PYTHON if not present
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
If I remember correctly there was patch adding some very minimal
install script for building git on some architecture. If it were
added, the lines with INSTALL in configure.ac and config.mak.in
should be uncommented in.
Currently it is commented out to ./configure not fail.
config.mak.in | 5 +++++
configure.ac | 7 +++++++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/config.mak.in b/config.mak.in
index 82c9781..89520eb 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -1,6 +1,11 @@
# git Makefile configuration, included in main Makefile
# @configure_input@
+CC = @CC@
+AR = @AR@
+TAR = @TAR@
+#INSTALL = @INSTALL@ # needs install-sh or install.sh in sources
+
prefix = @prefix@
exec_prefix = @exec_prefix@
bindir = @bindir@
diff --git a/configure.ac b/configure.ac
index d938546..56e765f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -22,6 +22,13 @@ AC_DEFUN([GIT_CONF_APPEND_LINE],
## Checks for programs.
+AC_MSG_NOTICE([CHECKS for programs])
+
+AC_PROG_CC
+#AC_PROG_INSTALL # needs install-sh or install.sh in sources
+AC_CHECK_TOOL(AR, ar, :)
+AC_CHECK_PROGS(TAR, [gtar tar])
+
# Define NO_PYTHON if you want to loose all benefits of the recursive merge.
--
1.4.0
^ permalink raw reply related
* [RFC/PATCH 6] autoconf: Checks for some library functions.
From: Jakub Narebski @ 2006-07-08 21:07 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1152392837823-git-send-email-jnareb@gmail.com>
./configure script checks now for the following library functions:
* strcasestr (NO_STRCASESTR)
* strlcpy (NO_STRLCPY)
* setenv (NO_SETENV)
in default C library and in libraries which have AC_CHECK_LIB done for
them.
Checks not implemented:
* NO_MMAP - probably only via optional features configuration
* NO_IPV6 - what does "lack IPv6 support" mean?
* NO_ICONV - what does "properly support iconv" mean?
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Added only those checks I was sure how to do in autoconf.
Probably other, marked as not implemented checks either need custom
test, or are more suited to site configuration section.
configure.ac | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index cb81258..ab6a77a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -69,12 +69,21 @@ GIT_CONF_APPEND_LINE(NO_SOCKADDR_STORAGE
## Checks for library functions.
+## (in default C library and libraries checked by AC_CHECK_LIB)
+AC_MSG_NOTICE([CHECKS for library functions])
+
# Define NO_STRCASESTR if you don't have strcasestr.
-#
+AC_CHECK_FUNC(strcasestr,[],
+GIT_CONF_APPEND_LINE(NO_STRCASESTR=YesPlease))
+
# Define NO_STRLCPY if you don't have strlcpy.
-#
+AC_CHECK_FUNC(strlcpy,[],
+GIT_CONF_APPEND_LINE(NO_STRLCPY=YesPlease))
+
# Define NO_SETENV if you don't have setenv in the C library.
-#
+AC_CHECK_FUNC(setenv,[],
+GIT_CONF_APPEND_LINE(NO_SETENV=YesPlease))
+
# Define NO_MMAP if you want to avoid mmap.
#
# Define NO_IPV6 if you lack IPv6 support and getaddrinfo().
--
1.4.0
^ permalink raw reply related
* [RFC/PATCH 7] autoconf: Checks for libraries
From: Jakub Narebski @ 2006-07-08 21:07 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11523928373026-git-send-email-jnareb@gmail.com>
./configure script checks now if the following libraries are present:
* -lssl for SHA1_Init (NO_OPENSSL)
* -lcurl for curl_easy_setopt (NO_CURL)
* -lexpat for XML_ParserCreate (NO_EXPAT)
It also checks if adding the following libraries are needed:
* -lcrypto for SHA1_Init (NEEDS_SSL_WITH_CRYPTO)
* -liconv for iconv (NEEDS_LIBICONV)
* -lsocket for socket (NEEDS_SOCKET)
Policy: we check also if NEEDS_LIBRARY libraries are present, even if
there is no NO_LIBRARY variable.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Needs checking if correct functions are used for checks.
Policy might need to be changed, too.
configure.ac | 28 +++++++++++++++++++++-------
1 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/configure.ac b/configure.ac
index ab6a77a..d938546 100644
--- a/configure.ac
+++ b/configure.ac
@@ -26,22 +26,36 @@ # Define NO_PYTHON if you want to loose
## Checks for libraries.
+AC_MSG_NOTICE([CHECKS for libraries])
+
# Define NO_OPENSSL environment variable if you do not have OpenSSL.
-# This also implies MOZILLA_SHA1.
-#
+# Define NEEDS_SSL_WITH_CRYPTO if you need -lcrypto with -lssl (Darwin).
+AC_CHECK_LIB([ssl], [SHA1_Init],[],
+[AC_CHECK_LIB([crypto], [SHA1_INIT],
+ GIT_CONF_APPEND_LINE(NEEDS_SSL_WITH_CRYPTO=YesPlease),
+ GIT_CONF_APPEND_LINE(NO_OPENSSL=YesPlease))])
+
# Define NO_CURL if you do not have curl installed. git-http-pull and
# git-http-push are not built, and you cannot use http:// and https://
# transports.
-#
+AC_CHECK_LIB([curl], [curl_global_init],[],
+GIT_CONF_APPEND_LINE(NO_CURL=YesPlease))
+
# Define NO_EXPAT if you do not have expat installed. git-http-push is
# not built, and you cannot push using http:// and https:// transports.
-#
-# Define NEEDS_SSL_WITH_CRYPTO if you need -lcrypto with -lssl (Darwin).
-#
+AC_CHECK_LIB([expat], [XML_ParserCreate],[],
+GIT_CONF_APPEND_LINE(NO_EXPAT=YesPlease))
+
# Define NEEDS_LIBICONV if linking with libc is not enough (Darwin).
-#
+AC_CHECK_LIB([c], [iconv],[],
+[AC_CHECK_LIB([iconv],[iconv],
+ GIT_CONF_APPEND_LINE(NEEDS_LIBICONV=YesPlease),[])])
+
# Define NEEDS_SOCKET if linking with libc is not enough (SunOS,
# Patrick Mauritz).
+AC_CHECK_LIB([c], [socket],[],
+[AC_CHECK_LIB([socket],[socket],
+ GIT_CONF_APPEND_LINE(NEEDS_SOCKET=YesPlease),[])])
## Checks for header files.
--
1.4.0
^ permalink raw reply related
* Comment on this series of patches (PATCH 2-9)
From: Jakub Narebski @ 2006-07-08 21:07 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11523928383518-git-send-email-jnareb@gmail.com>
This concludes easiest part of autodetecting compile configuration
using autoconf generated configure script. Patches needs revision by
somebody better versed in autoconf than me.
Autodetection TODO:
* check for Python (NO_PYTHON) and it's version (WITH_OWN_SUBPROCESS_PY)
or just "own subprocess.py"
* check for "IPv6 support" and getaddrinfo() (NO_IPV6), latter can be
easily done in autoconf
* check for "proper iconv support" (NO_ICONV), probably custom check.
* check for USE_PIC, NO_SYMLINK_HEAD and NO_ACCURATE_DIFF, all
needing custom tests.
* use XXX_SHA1 when NO_OPENSSL, with XXX according to the architecture
git is compiled for.
Next planned are series of patches allowing to select optional
build features and packages from configure script... if somebody else
wouldn't do it (hint, hint).
About needing autoconf to build git:
1. Currently using autoconf is totally optional, so one can compile
git as one used to earlier. This results in non-autoconf conventions
in configure.ac
2. configure script generated by autoconf can be treated exactly the
same like html and man documentation generated by asciidoc: use
separate 'configure' branch to store current version of configure
script, and add autogeneration of configure script to the same hook
like generating html and man documentation.
--
Jakub Narebski
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Replace sed with perl when setting up perl scripts.
From: Junio C Hamano @ 2006-07-08 21:11 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060708193717.GA17905@spearce.org>
Please try the replacement patch I sent to the list earlier in
response to Johannes's patch to the same problem.
^ permalink raw reply
* Re: Comment on this series of patches (PATCH 2-9)
From: Junio C Hamano @ 2006-07-08 21:20 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <11523928383501-git-send-email-jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> This concludes easiest part of autodetecting compile configuration
> using autoconf generated configure script. Patches needs revision by
> somebody better versed in autoconf than me.
Thanks. Will take a look.
> About needing autoconf to build git:
>
> 1. Currently using autoconf is totally optional, so one can compile
> git as one used to earlier.
This should stay this way, at least for now and probably even
after merging this into "master" someday (we need to get this in
"next" first).
> 2. configure script generated by autoconf can be treated exactly the
> same like html and man documentation generated by asciidoc: use
> separate 'configure' branch to store current version of configure
> script, and add autogeneration of configure script to the same hook
> like generating html and man documentation.
Actually my gut feeling on this is eventually (read: when the
autoconfiguration is stable enough) we would want to do this the
other way around --- keep only the generated configure script
for public consumption, and interested parties can check out
autoconf branch to hack on configure.ac and friends when needed.
But we haven't reached that point yet, so we will see.
^ permalink raw reply
* [PATCH 9] configure.ac vertical whitespace usage cleanup
From: Jakub Narebski @ 2006-07-08 21:07 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11523928372070-git-send-email-jnareb@gmail.com>
configure.ac | 29 +++++++++++++++--------------
1 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/configure.ac b/configure.ac
index 56e765f..acea6ce 100644
--- a/configure.ac
+++ b/configure.ac
@@ -23,41 +23,41 @@ AC_DEFUN([GIT_CONF_APPEND_LINE],
## Checks for programs.
AC_MSG_NOTICE([CHECKS for programs])
-
+#
AC_PROG_CC
#AC_PROG_INSTALL # needs install-sh or install.sh in sources
AC_CHECK_TOOL(AR, ar, :)
AC_CHECK_PROGS(TAR, [gtar tar])
-
+#
# Define NO_PYTHON if you want to loose all benefits of the recursive merge.
## Checks for libraries.
AC_MSG_NOTICE([CHECKS for libraries])
-
+#
# Define NO_OPENSSL environment variable if you do not have OpenSSL.
# Define NEEDS_SSL_WITH_CRYPTO if you need -lcrypto with -lssl (Darwin).
AC_CHECK_LIB([ssl], [SHA1_Init],[],
[AC_CHECK_LIB([crypto], [SHA1_INIT],
GIT_CONF_APPEND_LINE(NEEDS_SSL_WITH_CRYPTO=YesPlease),
GIT_CONF_APPEND_LINE(NO_OPENSSL=YesPlease))])
-
+#
# Define NO_CURL if you do not have curl installed. git-http-pull and
# git-http-push are not built, and you cannot use http:// and https://
# transports.
AC_CHECK_LIB([curl], [curl_global_init],[],
GIT_CONF_APPEND_LINE(NO_CURL=YesPlease))
-
+#
# Define NO_EXPAT if you do not have expat installed. git-http-push is
# not built, and you cannot push using http:// and https:// transports.
AC_CHECK_LIB([expat], [XML_ParserCreate],[],
GIT_CONF_APPEND_LINE(NO_EXPAT=YesPlease))
-
+#
# Define NEEDS_LIBICONV if linking with libc is not enough (Darwin).
AC_CHECK_LIB([c], [iconv],[],
[AC_CHECK_LIB([iconv],[iconv],
GIT_CONF_APPEND_LINE(NEEDS_LIBICONV=YesPlease),[])])
-
+#
# Define NEEDS_SOCKET if linking with libc is not enough (SunOS,
# Patrick Mauritz).
AC_CHECK_LIB([c], [socket],[],
@@ -70,18 +70,18 @@ ## Checks for header files.
## Checks for typedefs, structures, and compiler characteristics.
AC_MSG_NOTICE([CHECKS for typedefs, structures, and compiler characteristics])
-
+#
# Define NO_D_INO_IN_DIRENT if you don't have d_ino in your struct dirent.
AC_CHECK_MEMBER(struct dirent.d_ino,[],
GIT_CONF_APPEND_LINE(NO_D_INO_IN_DIRENT=YesPlease),
[#include <dirent.h>])
-
+#
# Define NO_D_TYPE_IN_DIRENT if your platform defines DT_UNKNOWN but lacks
# d_type in struct dirent (latest Cygwin -- will be fixed soonish).
AC_CHECK_MEMBER(struct dirent.d_type,[],
GIT_CONF_APPEND_LINE(NO_D_TYPE_IN_DIRENT=YesPlease),
[#include <dirent.h>])
-
+#
# Define NO_SOCKADDR_STORAGE if your platform does not have struct
# sockaddr_storage.
AC_CHECK_TYPE(struct sockaddr_storage,[],
@@ -92,19 +92,19 @@ GIT_CONF_APPEND_LINE(NO_SOCKADDR_STORAGE
## Checks for library functions.
## (in default C library and libraries checked by AC_CHECK_LIB)
AC_MSG_NOTICE([CHECKS for library functions])
-
+#
# Define NO_STRCASESTR if you don't have strcasestr.
AC_CHECK_FUNC(strcasestr,[],
GIT_CONF_APPEND_LINE(NO_STRCASESTR=YesPlease))
-
+#
# Define NO_STRLCPY if you don't have strlcpy.
AC_CHECK_FUNC(strlcpy,[],
GIT_CONF_APPEND_LINE(NO_STRLCPY=YesPlease))
-
+#
# Define NO_SETENV if you don't have setenv in the C library.
AC_CHECK_FUNC(setenv,[],
GIT_CONF_APPEND_LINE(NO_SETENV=YesPlease))
-
+#
# Define NO_MMAP if you want to avoid mmap.
#
# Define NO_IPV6 if you lack IPv6 support and getaddrinfo().
@@ -178,5 +178,6 @@ ## Output files
AC_CONFIG_FILES(["${config_file}":"${config_in}":"${config_append}"])
AC_OUTPUT
+
## Cleanup
rm -f "${config_append}"
--
1.4.0
^ permalink raw reply related
* Re: What's in git.git
From: Jakub Narebski @ 2006-07-08 21:28 UTC (permalink / raw)
To: git
In-Reply-To: <7vlkr5szi2.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I hope further patches to this series will be added soon to
> autodetect the following in our Makefile (from "pu"):
I have just (re)sent series of patches adding autodetection
of building options via autoconf generated configure.
> NO_D_INO_IN_DIRENT
> NO_D_TYPE_IN_DIRENT
> NO_STRCASESTR
> NO_STRLCPY
> NO_SETENV
> NO_SOCKADDR_STORAGE
Done.
> USE_PIC
To be written by somebody better versed in autoconf.
> NEEDS_SSL_WITH_CRYPTO
> NEEDS_LIBICONV
> NEEDS_SOCKET
Needs checking.
> WITH_OWN_SUBPROCESS_PY
> NO_IPV6
> NO_ICONV
Needs explanation, and probably custom test.
> These are not something you can change without replacing libc
> (or installed Python) wholesale, so autodetection would be
> always correct.
>
> Also the following would be nice if autodetection worked for
> most of the users with ./configure command line override:
>
> CC
> AR
> TAR
Done, I think
> INSTALL
Needs lightweight install-sh script. If I remember correctly someone
provided such script because of lack of install on some exotic
architecture. Easily provided.
> SHELL_PATH
> PERL_PATH
> PYTHON_PATH
To be done using --with-shell=PATH, --with-perl=PATH,
--with-python=PATH, easily.
> BASIC_CFLAGS mostly for -I include paths
> BASIC_LDFLAGS mostly for -L library paths
> ALL_LDFLAGS
I don't know how to do this (for now), probably quite easy.
> NO_OPENSSL
> MOZILLA_SHA1
> PPC_SHA1
> ARM_SHA1
> NO_CURL
> NO_EXPAT
> CURLDIR
> OPENSSLDIR
> ICONVDIR
> EXPATDIR (we do not have one, but I think it should be there
> to allow -lexpat installed elsewhere just like
> we have CURLDIR and OPENSSLDIR)
Should be done in next series of patches... provided I'd have enough
free time for this...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] just an (stupid) idea when creating a new branch
From: Jakub Narebski @ 2006-07-08 21:41 UTC (permalink / raw)
To: git
In-Reply-To: <20060708155547.73054.qmail@web25814.mail.ukl.yahoo.com>
moreau francis wrote:
> Hi GIT folks.
>
> I'm a complete newbie on git development so excuse me if
> this idea is completely stupid.
>
> Would it be possible to let the user stick a short explanation
> on what a branch is supposed to implement during its creation.
It would be possible when/if branch and remotes config would migrate
to .git/config. Currently too many I think relies on refs/heads being
simple sha1 of "top" commit.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] just an (stupid) idea when creating a new branch
From: Johannes Schindelin @ 2006-07-08 22:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e8p8pj$jk3$2@sea.gmane.org>
Hi,
On Sat, 8 Jul 2006, Jakub Narebski wrote:
> moreau francis wrote:
>
> > Hi GIT folks.
> >
> > I'm a complete newbie on git development so excuse me if
> > this idea is completely stupid.
> >
> > Would it be possible to let the user stick a short explanation
> > on what a branch is supposed to implement during its creation.
>
> It would be possible when/if branch and remotes config would migrate
> to .git/config. Currently too many I think relies on refs/heads being
> simple sha1 of "top" commit.
But it does not need a change of existing practice at all! Just add the
information provided by --topic as branch."pathname".description to the
config. And make format-patch aware of that.
Ciao,
Dscho
^ permalink raw reply
* RFH: refactor read-tree
From: Johannes Schindelin @ 2006-07-08 22:28 UTC (permalink / raw)
To: git
Hi,
the last thing to do with merge-recursive to speed it up, would be to
avoid reading/writing the cache all the time.
Unfortunately, builtin-read-tree.c grew into a pretty big monster, with so
many different options which completely change behaviour.
So, how should I go about it? Should I make a struct a la diff_options to
hold the options to unpack_trees? Where should it go?
I also played a little with git-merge-tree, because it seems so much
simpler and easier to refactor. But there is a problem: Either I call it
the wrong way, or it does not yet work correctly: I tried
git-merge-tree $(git-merge-base branch1 branch2) branch1 branch2
with what is in 'next'. But it only showed the _new_ files, not the
modified ones.
Help, please?
Ciao,
Dscho
^ permalink raw reply
* What *have* I done?
From: Nix @ 2006-07-08 22:48 UTC (permalink / raw)
To: git
I am just a git newbie, still reliant on cogito 0.17.3 for most things
(cogito has a couple of cherry-picked patches from the head for
faster cg-seek and for support of lightweight tags.)
I tried my first conflicted cherry-pick a while back; resolved the
conflict, committed, ran git-update-index over the conflicted file as
git-cherry-pick requested, yet now the branch the cherry-pick was done
to seems to be oddly `half-stuck'.
Here's an example:
loki 590 /usr/packages/linux/linux% cg-status -g
Heads:
R 2.6.17-stable 4f9619cdd90ac846fa0ca6e9e8a9d87a0d6b4f57
esperi-guest 764415bf7dc0388d9974218fb71b3c63f19f3828
master 578997683c8d788f80f7a11fc27fcdf66ac8fd9f
R origin 120bda20c6f64b32e8bfbdd7b34feafaa5f5332e
v2.6.17 e519ad6612b8ab69cbf45b59dda45f88cada41f2
>x86-host e2a9e65e9d5f7e76dbe0a8fdd0f1356266146c22
loki 591 /usr/packages/linux/linux% cg-diff
loki 592 /usr/packages/linux/linux% cg-switch v2.6.17
Switching to branch v2.6.17...
Now one would expect that after switching, I'd have no uncommitted
changes, right, since I had none before switching and they shouldn't
appear out of thin air? You'd be wrong:
loki 593 /usr/packages/linux/linux% cg-diff | diffstat
b/Makefile | 4 +-
b/arch/sparc64/Makefile | 15 +++----
b/arch/sparc64/kernel/Makefile | 2 -
b/arch/um/kernel/dyn.lds.S | 1
b/kernel/pid.c | 2 -
b/scripts/kconfig/Makefile | 7 ++-
b/usr/gen_init_cpio.c | 2 -
usr/init | 79 -----------------------------------------
usr/initramfs | 45 -----------------------
9 files changed, 15 insertions(+), 142 deletions(-)
Those miraculously materialized uncommitted changes are the *reverse* of
every commit I made after that failed cherry-pick! (If I switch branches
back, or run `cg-seek', it tries to take these `uncommitted local
changes' with me, with amusing results.)
So, has it forgotten what the branch head is? No: cg-log reports correct
data, cg-reset works fine:
loki 594 /usr/packages/linux/linux% cg-reset
loki 595 /usr/packages/linux/linux% cg-diff
loki 596 /usr/packages/linux/linux%
So, um, what on earth has gone wrong and how do I fix it? (If you need
more info, just ask!)
^ permalink raw reply
* Re: [PATCH] gitweb.cgi: Use File::MMagic; "a=blob" action knows the blob/file type
From: Luben Tuikov @ 2006-07-09 1:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmfksjpe.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > Use File::MMagic to determine the MIME type of a blob/file.
> > The variable magic_mime_file holds the location of the
> > "magic.mime" file, usually "/usr/share/file/magic.mime".
> > If not defined, the magic numbers internally stored in the
> > File::MMagic module are used.
>
> I am sorry to ask you this, but would you mind redoing this
> patch without File::MMagic bits?
Yeah, no problem, will do.
> I think giving "a=blob" an
> ability to automatically switch to git_blob_plain is a good
> addition (as is your earlier patch to give a direct link to
> reach blob_plain from the list), so let's have that part in
> first.
Ok.
> I haven't applied your earlier one but it will appear in
> "next" shortly.
Ok.
> Existing filename based mimetypes_guess should be a lot cheaper
> than exploding a blob and feeding it to File::MMagic. I was
> hoping File::MMagic to be used when we cannot guess the content
> type that way (i.e. when mimetypes_guess returns undef or
> application/octet-stream).
The MIME guessing is used in git_blob_plain(), where the blob
is already exploded, since a file descriptor is passed to the MIME
guessing routines.
Initially I tried using the already opened file descriptor to
the blob, but File::MMagic v1.27 always returns "text/plain"
on that. I was astounded by this and a 5 line perl script
using that same module confirmed my suspicion that the module
or "seek" is broken in perl or in FileHandle. I.e.
checktype_filename() succeeds, but checktype_filehandle()
always returns "text/plain".
Had simply reading the file descriptor succeeded, then we'd not
need to explode blobs in $git_temp.
The other reason I decided to completely go with File::MMagic is
that if I'm going to use it to decide the mime type after
the default method didn't succeed, why not forget the default
method and just use File::MMagic in general -- seemed like a logical
simplification.
> Since the repository owner can correct misidentification by the
> standard /etc/mime.types by supplying a custom per-repository
> $mimetypes_file (modulo that the current implementation of
> mimetype_guess_file does not allow it if the file does not have
> an extension that is specific enough), File::MMagic might be an
> overkill, especially if used in the way this patch does. To
> allow finer grained differentiation that cannot be done with
> file extensions alone (e.g. some files may have .dat extension
> but one can be VCD mpeg wrapped in RIFF, and another can be a
> Z-machine story file), it might be simpler to allow the
> repository owner to specify full $file_name for such an ambiguous
> file in their custom $mimetypes_file, and try to match it in
> mimetype_guess_file sub. That way we may not even need to use
> File::MMagic.
This is true, but I wonder how many people are going to go and
create their own mime.type files. Most of the time people would
do minimal gitweb.cgi changes not even specifying $mimetypes_file
nor even $magic_mime_file.
> Are there cases where only $hash is given without $file_name?
> If so we may need to fall back on File::MMagic in such a case
> after all, but get_blob_mimetype sub copies the whole blob to a
> temporary file to work around a problem with version 1.27 you
> state in the comment -- this is way too much (and nobody seems
> to clean up the tempfile). Looking at magic.mime, I suspect we
> might be able to get away with the first 4k bytes or so at most
> (the largest offset except iso9660 image is "Biff5" appearing at
> 2114 to signal an Excel spreadsheet).
I was hoping that tmpwatch(8) would clean up the blobs in Linux/UNIX.
But we can also delete them after the lookup. Anothing thing is that
getting a blob isn't that often and when it happens, after the MIME
lookup it is already in the pagecache.
Luben
^ permalink raw reply
* Re: RFH: refactor read-tree
From: Linus Torvalds @ 2006-07-09 3:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607090015250.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Sun, 9 Jul 2006, Johannes Schindelin wrote:
>
> I also played a little with git-merge-tree, because it seems so much
> simpler and easier to refactor. But there is a problem: Either I call it
> the wrong way, or it does not yet work correctly: I tried
>
> git-merge-tree $(git-merge-base branch1 branch2) branch1 branch2
>
> with what is in 'next'. But it only showed the _new_ files, not the
> modified ones.
What git-merge-tree does is to show the _difference_ to "branch1".
So if the result of the merge would be totally identical to "branch1",
then git-merge-tree should be totally silent.
The basic idea is that "branch1" should be your current branch, and it
obviously is also expected to match (more or less) the current index. So
you can do a merge by
- reading in "branch1" into the index:
GIT_INDEX_FILE=.git/tmp-index git-read-tree -m branch1
- doing a "git-merge-tree $base $branch1 $branch2"
- using the _result_ of "git-merge-tree" to modify the index you just
read in.
- write out the end result as the result of the merge.
And yes, I agree 100% that "git-read-tree" has become an unholy mess. I
looked at it, and I think it's unfixable. I considered re-writing it from
scratch, at least for some specific cases, but I couldn't bring myself to
do it.
Linus
^ permalink raw reply
* Re: [RFC] just an (stupid) idea when creating a new branch
From: Pavel Roskin @ 2006-07-09 3:27 UTC (permalink / raw)
To: moreau francis; +Cc: git
In-Reply-To: <20060708155547.73054.qmail@web25814.mail.ukl.yahoo.com>
Hello!
On Sat, 2006-07-08 at 15:55 +0000, moreau francis wrote:
> Hi GIT folks.
>
> I'm a complete newbie on git development so excuse me if
> this idea is completely stupid.
>
> Would it be possible to let the user stick a short explanation
> on what a branch is supposed to implement during its creation.
Just for your information, this is already implemented by StGIT. For
instance, .git/patches/master/description contains the description of
the "master" branch.
If you run "stg branch --list", the branch descriptions will be listed.
I'm not aware of any commands to change the description.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [WIP] Status update on merge-recursive in C
From: Pavel Roskin @ 2006-07-09 5:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607081840280.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hello, Dscho!
On Sat, 2006-07-08 at 18:42 +0200, Johannes Schindelin wrote:
> This is just an update for people being interested. Alex and me were
> busy with that project for a few days now. While it has progressed nicely,
> there are quite a couple TODOs in merge-recursive.c, just search for "TODO".
That's great. Just a few notes regarding the patch.
Why do you list "recur" twice in all_strategies in the git-merge.sh?
The second "recur" should probably be "recursive".
Test for Python in the git-rebase.sh is probably wrong. "recur" doesn't
need Python - that's the whole point. In fact, if I build git with
NO_PYTHON, TEST fails in t3401-rebase-partial.sh
Apart from that, the tests pass on i386, x86_64 and PowerPC, all running
Fedora Core 5.
I tries to run sparse of the C files, and it complains about two things
- variable declarations in the middle of the code (allowed by c99 but
not by ANSI C) and incomplete function declarations (no "void"). It's
not C++, let's stick to the C standards.
I'm attaching a patch that fixes everything except variable
declarations. There are so many of them that it could be done once the
code stabilizes a bit.
It would be great to have a patch that actually removes the old
"recursive" and makes the new strategy "recursive". I understand it's
the plan, right?
---
git-merge.sh | 2 +-
git-rebase.sh | 2 +-
merge-recursive.c | 9 +++++----
read-cache.c | 2 +-
4 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/git-merge.sh b/git-merge.sh
index b26ca14..240e5ee 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -9,7 +9,7 @@ USAGE='[-n] [--no-commit] [--squash] [-s
LF='
'
-all_strategies='recur recur octopus resolve stupid ours'
+all_strategies='recur recursive octopus resolve stupid ours'
default_twohead_strategies='recur'
default_octopus_strategies='octopus'
no_trivial_merge_strategies='ours'
diff --git a/git-rebase.sh b/git-rebase.sh
index 5d4c7d2..6472970 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -292,7 +292,7 @@ then
exit $?
fi
-if test "@@NO_PYTHON@@" && test "$strategy" = "recur"
+if test "@@NO_PYTHON@@" && test "$strategy" = "recursive"
then
die 'The recursive merge strategy currently relies on Python,
which this installation of git was not configured with. Please
consider
diff --git a/merge-recursive.c b/merge-recursive.c
index 07a2b38..1cae804 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -61,7 +61,8 @@ static void show_ce_entry(const char *ta
fputc('\n', stderr);
}
-static void ls_files() {
+static void ls_files(void)
+{
int i;
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce = active_cache[i];
@@ -207,7 +208,7 @@ static const char *original_index_file;
static const char *temporary_index_file;
static int cache_dirty = 0;
-static int flush_cache()
+static int flush_cache(void)
{
/* flush temporary index */
struct lock_file *lock = xcalloc(1, sizeof(struct lock_file));
@@ -331,7 +332,7 @@ #endif
/*
* TODO: this can be streamlined by refactoring builtin-write-tree.c
*/
-static struct tree *git_write_tree()
+static struct tree *git_write_tree(void)
{
#if 0
fprintf(stderr, "GIT_INDEX_FILE='%s' git-write-tree\n",
@@ -467,7 +468,7 @@ static void free_index_entries(struct pa
* Create a dictionary mapping file names to CacheEntry objects. The
* dictionary contains one entry for every path with a non-zero stage
entry.
*/
-static struct path_list *get_unmerged()
+static struct path_list *get_unmerged(void)
{
struct path_list *unmerged = xcalloc(1, sizeof(struct path_list));
int i;
diff --git a/read-cache.c b/read-cache.c
index f6e1b70..0ef89a9 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -797,7 +797,7 @@ unmap:
die("index file corrupt");
}
-int discard_cache()
+int discard_cache(void)
{
int ret;
--
Regards,
Pavel Roskin
^ permalink raw reply related
* [RFC+PATCH 1/1] Move SCM interoperability tools into scm/
From: Ryan Anderson @ 2006-07-09 6:17 UTC (permalink / raw)
To: git; +Cc: Ryan Anderson
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
This is the first in a series to categorize the source tree a little bit more
than it is currently.
I figured I'd start with something innocuous, like the SCM interoperability
tools.
One thing I don't really like is that I had to duplicate the Perl build rule
in the subdirectory Makefile, effectively, to restructure it and leave the
built files in the root. If we can deprecate "run from the source tree",
this can go away. (That requires fixing up a lot of tests, but it's
straightforward, at least.)
So, flame away!
Makefile | 10 ++++++----
scm/Makefile | 20 ++++++++++++++++++++
git-archimport.perl => scm/git-archimport.perl | 0
.../git-cvsexportcommit.perl | 0
git-cvsimport.perl => scm/git-cvsimport.perl | 0
git-cvsserver.perl => scm/git-cvsserver.perl | 0
git-p4import.py => scm/git-p4import.py | 0
git-send-email.perl => scm/git-send-email.perl | 0
git-svnimport.perl => scm/git-svnimport.perl | 0
9 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index 202f261..e7f5b48 100644
--- a/Makefile
+++ b/Makefile
@@ -130,11 +130,10 @@ SCRIPT_SH = \
git-lost-found.sh git-quiltimport.sh
SCRIPT_PERL = \
- git-archimport.perl git-cvsimport.perl git-relink.perl \
+ git-relink.perl \
git-shortlog.perl git-rerere.perl \
- git-annotate.perl git-cvsserver.perl \
- git-svnimport.perl git-mv.perl git-cvsexportcommit.perl \
- git-send-email.perl
+ git-annotate.perl \
+ git-mv.perl
SCRIPT_PYTHON = \
git-merge-recursive.py
@@ -176,6 +175,9 @@ BUILT_INS = git-log$X git-whatchanged$X
git-diff-index$X git-diff-stages$X git-diff-tree$X git-cat-file$X \
git-fmt-merge-msg$X
+
+include scm/Makefile
+
# what 'all' will build and 'install' will install, in gitexecdir
ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
diff --git a/scm/Makefile b/scm/Makefile
new file mode 100644
index 0000000..0ce205b
--- /dev/null
+++ b/scm/Makefile
@@ -0,0 +1,20 @@
+
+SCM_PERL_BASE = \
+ git-archimport.perl \
+ git-cvsimport.perl \
+ git-cvsexportcommit.perl \
+ git-cvsserver.perl \
+ git-svnimport.perl \
+ git-send-email.perl
+
+SCRIPTS+=$(patsubst %.perl,%,$(SCM_PERL_BASE))
+
+$(patsubst %.perl,%,$(SCM_PERL_BASE)) : % : scm/%.perl
+ rm -f $@ $@+
+ sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \
+ -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
+ $^ >$@+
+ chmod +x $@+
+ mv $@+ $@
+
+
diff --git a/git-archimport.perl b/scm/git-archimport.perl
similarity index 100%
rename from git-archimport.perl
rename to scm/git-archimport.perl
diff --git a/git-cvsexportcommit.perl b/scm/git-cvsexportcommit.perl
similarity index 100%
rename from git-cvsexportcommit.perl
rename to scm/git-cvsexportcommit.perl
diff --git a/git-cvsimport.perl b/scm/git-cvsimport.perl
similarity index 100%
rename from git-cvsimport.perl
rename to scm/git-cvsimport.perl
diff --git a/git-cvsserver.perl b/scm/git-cvsserver.perl
similarity index 100%
rename from git-cvsserver.perl
rename to scm/git-cvsserver.perl
diff --git a/git-p4import.py b/scm/git-p4import.py
similarity index 100%
rename from git-p4import.py
rename to scm/git-p4import.py
diff --git a/git-send-email.perl b/scm/git-send-email.perl
similarity index 100%
rename from git-send-email.perl
rename to scm/git-send-email.perl
diff --git a/git-svnimport.perl b/scm/git-svnimport.perl
similarity index 100%
rename from git-svnimport.perl
rename to scm/git-svnimport.perl
--
1.4.1.gc473b-dirty
^ permalink raw reply related
* [PATCH 1/1] Disable color detection during format-patch
From: Ryan Anderson @ 2006-07-09 6:28 UTC (permalink / raw)
To: junkio; +Cc: git, Ryan Anderson
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
builtin-log.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 698b71e..0aeeaa4 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -105,6 +105,9 @@ static int git_format_config(const char
strcat(extra_headers, value);
return 0;
}
+ if (!strcmp(var, "diff.color")) {
+ return 0;
+ }
return git_diff_config(var, value);
}
--
1.4.1.gc473b-dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox