* Re: [PATCH 3/5] autoconf: Preliminary check for working mmap
From: Shawn Pearce @ 2006-09-05 6:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu03mkiei.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > I'm maybe only 1/3 of the way through the sliding window mmap
> > implementation. I've got a good chunk of sha1_file.c converted but I
> > still have to deal with the copying in pack-objects.c and the verify
> > code in verify-pack.c. I'm hoping I can send a preliminary patch
> > series tomorrow as I'm going to work on it more tonight and tomorrow.
>
> Thanks -- I was tempted to do this myself after finishing the
> index_64 change in "pu" branch, but have resisted the temptation
> myself so far. Being lazy, the less I have to code the better,
> naturally ;-).
I thought that might be the case. I should be able to finish it
up tomorrow. :-)
I don't know if I've made this more complex than I really need to
but I've permitted multiple windows per pack. There is just one
LRU of all windows across all packs and a maximum amount of address
space to use for pack mappings. Least recently used window gets
tossed when we need a different window. This permits us to keep
say a window active on the front of a pack (near the commits) and
another different active window closer to the back (near the blobs).
That multiple window feature made it a slightly non-trivial copy
and paste from fast-import but I think its worth it for tree walking
type applications.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 3/5] autoconf: Preliminary check for working mmap
From: Shawn Pearce @ 2006-09-05 3:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <edidlp$d3d$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Junio C Hamano wrote:
>
> > Jakub Narebski <jnareb@gmail.com> writes:
> >
> >> This patch sent earlier in other patch series and dropped,
> >> as git uses private mapping, not private fixed. I think
> >> that this check is better than no check at all...
> >
> > I think the next major change that is needed fairly soon is to
> > be able to mmap parts of a large pack file (even with 32-bit
> > offset). I haven't loooked into it deeply enough but it may or
> > may not turn out to be beneficial if we map at fixed location so
> > the requirements of "working mmap()" might change. I'd be
> > happier if you held onto this part of the patch before that
> > happens.
>
> Well, this patch perhaps not always would set NO_MMAP when it should
> (some broken mmap that does private+fixed but not private), but I guess that
> if it would set NO_MMAP then mmap is broken (or doesn't exist at all).
>
> I have noticed AC_FUNC_MMAP test, and thought why not to use it?
> The simplest check if mmap exist would be to check libc for mmap function.
Are there really mmap implementations that will only do
private+fixed? Sick.
I'm maybe only 1/3 of the way through the sliding window mmap
implementation. I've got a good chunk of sha1_file.c converted but I
still have to deal with the copying in pack-objects.c and the verify
code in verify-pack.c. I'm hoping I can send a preliminary patch
series tomorrow as I'm going to work on it more tonight and tomorrow.
--
Shawn.
^ permalink raw reply
* [PATCH] Fix memory leak in prepend_to_path (git.c).
From: Christian Couder @ 2006-09-05 6:22 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Some memory was allocated for a new path but not freed
after the path was used.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/git.c b/git.c
index 1d00111..335f405 100644
--- a/git.c
+++ b/git.c
@@ -36,6 +36,8 @@ static void prepend_to_path(const char *
memcpy(path + len + 1, old_path, path_len - len);
setenv("PATH", path, 1);
+
+ free(path);
}
static int handle_options(const char*** argv, int* argc)
--
1.4.2.g269a-dirty
^ permalink raw reply related
* Re: [PATCH 3/5] autoconf: Preliminary check for working mmap
From: Junio C Hamano @ 2006-09-05 5:10 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060905030929.GA29865@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> I'm maybe only 1/3 of the way through the sliding window mmap
> implementation. I've got a good chunk of sha1_file.c converted but I
> still have to deal with the copying in pack-objects.c and the verify
> code in verify-pack.c. I'm hoping I can send a preliminary patch
> series tomorrow as I'm going to work on it more tonight and tomorrow.
Thanks -- I was tempted to do this myself after finishing the
index_64 change in "pu" branch, but have resisted the temptation
myself so far. Being lazy, the less I have to code the better,
naturally ;-).
^ permalink raw reply
* Test names
From: Jakub Narebski @ 2006-09-05 0:10 UTC (permalink / raw)
To: git
In t/README it is written:
> The test files are named as:
>
> tNNNN-commandname-details.sh
>
> where N is a decimal digit.
>
> First digit tells the family:
>
> 0 - the absolute basics and global stuff
> [...]
> 7 - the porcelainish commands concerning the working tree
There are now some test which have 8 or 9 as first digit (e.g.
t8002-blame.sh, t9001-send-email.sh). What is the family for them?
What number for example gitweb test should have?
> Second digit tells the particular command we are testing.
Is there any naming rule, or just increment it by one when adding new test
in the same family?
> Third digit (optionally) tells the particular switch or group of switches
> we are testing.
What tells the fourth digit?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 0/4] gitweb: Some improvements
From: Jakub Narebski @ 2006-09-04 23:53 UTC (permalink / raw)
To: git
In-Reply-To: <7v8xkzkyie.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> This is small series of patches, applicable both to 'master' and 'next',
>> which adds simple improvements, or in the case of last patch
>> fix bug/typo.
>>
>> First two patches were sent earlier, I don't know if they were dropped
>> or forgotten.
>
> I think you were just expecting too quick turnaround ;-).
>
> If I recall correctly it used to be that we could not use png
> for favicon but it seems that things have improved.
>
> It is a while since I tried gitweb on my machine the last time
> but was it always this slow I wonder... We probably would need
> a good benchmark and automated test before going too much
> further.
The problem is that before commit 5d043a3d856bd40d8b34b8836a561e438d23573b
gitweb: fill in gitweb configuration by Makefile
by Martin Waitz one had to modify gitweb script to change the configuration
from default.
But benchmarking is good. Simple time to run script from command line, with
environment variables GATEWAY_INTERFACE="CGI/1.1", HTTP_ACCEPT="*/*",
REQUEST_METHOD="GET" and of course QUERY_STRING set, and perhaps using
ApacheBench.
>From my experience with gitweb, the longest it take to show summary and tags
views (for a large number of tags, which grows linearly with history), and
to show history (and of course blame).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 3/5] autoconf: Preliminary check for working mmap
From: Jakub Narebski @ 2006-09-04 23:43 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7szjjal.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> This patch sent earlier in other patch series and dropped,
>> as git uses private mapping, not private fixed. I think
>> that this check is better than no check at all...
>
> I think the next major change that is needed fairly soon is to
> be able to mmap parts of a large pack file (even with 32-bit
> offset). I haven't loooked into it deeply enough but it may or
> may not turn out to be beneficial if we map at fixed location so
> the requirements of "working mmap()" might change. I'd be
> happier if you held onto this part of the patch before that
> happens.
Well, this patch perhaps not always would set NO_MMAP when it should
(some broken mmap that does private+fixed but not private), but I guess that
if it would set NO_MMAP then mmap is broken (or doesn't exist at all).
I have noticed AC_FUNC_MMAP test, and thought why not to use it?
The simplest check if mmap exist would be to check libc for mmap function.
BTW the patch was reworked from previous version to reflect changes
in the compilation variables management (ability to unset variable).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What does "properly support iconv" in git Makefile (NO_ICONV) mean?
From: Fernando J. Pereda @ 2006-09-04 23:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200609050126.56423.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1611 bytes --]
On Tue, Sep 05, 2006 at 01:26:56AM +0200, Jakub Narebski wrote:
> On Tue, Sep 05 2006 at 01:16, Fernando J. Pereda wrote:
> > On Tue, Sep 05, 2006 at 01:08:57AM +0200, Jakub Narebski wrote:
> >> To add autoconf support for checking if NO_ICONV has to be defined
> >> (Define NO_ICONV if your libc does not properly support iconv.)
> >> one needs to know what does "properly support iconv" mean.
> >>
> >> The commit message of a commit which introduced this compilation
> >> variable (commit b6e56eca8a4eb74a86e9f2d99aa480c665458aa7) tells:
> >>
> >> Systems using some uClibc versions do not properly support
> >> iconv stuff.
> >>
> >> At what exactly iconv fail? What should the test to put in
> >> configure.ac check?
> >
> > As far as I know, iconv stuff is not supported on uClibc. Thats the
> > reason I sent the patch. Gentoo bug #115826 [1].
> >
> > You should probably set it if you are building for uClibc. Not sure
> > how you'd test that in configure.ac though.
> >
> > [1] https://bugs.gentoo.org/show_bug.cgi?id=115826
>
> Gaah, I have some problems accessing the Gentoo bug database.
> Is the problem that iconv does not exist in libc, or it exist but
> misbehaves?
Quoting Mike Frysinger:
iconv is part of uClibc itself but is disabled by default since it isnt
quite stable yet ... so yes, trying to use the iconv package wont work
That was on 2005-12-17 so I don't know what's the status now.
- ferdy
--
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH 3/5] autoconf: Preliminary check for working mmap
From: Junio C Hamano @ 2006-09-04 23:36 UTC (permalink / raw)
To: git
In-Reply-To: <200609050056.52590.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> This patch sent earlier in other patch series and dropped,
> as git uses private mapping, not private fixed. I think
> that this check is better than no check at all...
I think the next major change that is needed fairly soon is to
be able to mmap parts of a large pack file (even with 32-bit
offset). I haven't loooked into it deeply enough but it may or
may not turn out to be beneficial if we map at fixed location so
the requirements of "working mmap()" might change. I'd be
happier if you held onto this part of the patch before that
happens.
^ permalink raw reply
* Re: What does "properly support iconv" in git Makefile (NO_ICONV) mean?
From: Junio C Hamano @ 2006-09-04 23:31 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200609050126.56423.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Gaah, I have some problems accessing the Gentoo bug database.
> Is the problem that iconv does not exist in libc, or it exist but
> misbehaves?
In small configurations that do not care about i18n, it is often
done to give iconv routines that is noop/ident in order to make
the programs compile and run.
^ permalink raw reply
* Re: What does "properly support iconv" in git Makefile (NO_ICONV) mean?
From: Jakub Narebski @ 2006-09-04 23:26 UTC (permalink / raw)
To: Fernando J. Pereda, git
In-Reply-To: <20060904231609.GA6855@ferdyx.org>
On Tue, Sep 05 2006 at 01:16, Fernando J. Pereda wrote:
> On Tue, Sep 05, 2006 at 01:08:57AM +0200, Jakub Narebski wrote:
>> To add autoconf support for checking if NO_ICONV has to be defined
>> (Define NO_ICONV if your libc does not properly support iconv.)
>> one needs to know what does "properly support iconv" mean.
>>
>> The commit message of a commit which introduced this compilation
>> variable (commit b6e56eca8a4eb74a86e9f2d99aa480c665458aa7) tells:
>>
>> Systems using some uClibc versions do not properly support
>> iconv stuff.
>>
>> At what exactly iconv fail? What should the test to put in
>> configure.ac check?
>
> As far as I know, iconv stuff is not supported on uClibc. Thats the
> reason I sent the patch. Gentoo bug #115826 [1].
>
> You should probably set it if you are building for uClibc. Not sure
> how you'd test that in configure.ac though.
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=115826
Gaah, I have some problems accessing the Gentoo bug database.
Is the problem that iconv does not exist in libc, or it exist but
misbehaves?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 0/4] gitweb: Some improvements
From: Junio C Hamano @ 2006-09-04 23:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200609041810.09838.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> This is small series of patches, applicable both to 'master' and 'next',
> which adds simple improvements, or in the case of last patch
> fix bug/typo.
>
> First two patches were sent earlier, I don't know if they were dropped
> or forgotten.
I think you were just expecting too quick turnaround ;-).
If I recall correctly it used to be that we could not use png
for favicon but it seems that things have improved.
It is a while since I tried gitweb on my machine the last time
but was it always this slow I wonder... We probably would need
a good benchmark and automated test before going too much
further.
^ permalink raw reply
* Re: [PATCH 1/4] gitweb: Add GIT favicon, assuming image/png type
From: Junio C Hamano @ 2006-09-04 23:17 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <edib58$61k$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>>> Jakub Narebski wrote:
>>>
>>>> index 199fbe87384cd3f4686916277dd124cefc751e8a..f3b762de92e579300eba3f53ee26b2a80b4e76c7 100644
>>>
>>> Hmmm... I do wonder why --binary implies --full-index option.
>>
>> Patch safety. Yours happened to be a creation patch so it might
>> not matter in this particular case, but we would want to be
>> reasonably sure there is no ambiguity in the preimage when you
>> are doing a modification patch.
>
> Couldn't we do this (show full sha1) only for the binary part of patch?
Personally I would say why bother, but patches welcome if
cleanly done.
^ permalink raw reply
* Re: What does "properly support iconv" in git Makefile (NO_ICONV) mean?
From: Fernando J. Pereda @ 2006-09-04 23:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200609050108.57695.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]
On Tue, Sep 05, 2006 at 01:08:57AM +0200, Jakub Narebski wrote:
> To add autoconf support for checking if NO_ICONV has to be defined
> (Define NO_ICONV if your libc does not properly support iconv.)
> one needs to know what does "properly support iconv" mean.
>
> The commit message of a commit which introduced this compilation
> variable (commit b6e56eca8a4eb74a86e9f2d99aa480c665458aa7) tells:
>
> Systems using some uClibc versions do not properly support
> iconv stuff.
>
> At what exactly iconv fail? What should the test to put in configure.ac
> check?
As far as I know, iconv stuff is not supported on uClibc. Thats the
reason I sent the patch. Gentoo bug #115826 [1].
You should probably set it if you are building for uClibc. Not sure how
you'd test that in configure.ac though.
- ferdy
[1] https://bugs.gentoo.org/show_bug.cgi?id=115826
--
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] gitweb: Add GIT favicon, assuming image/png type
From: Jakub Narebski @ 2006-09-04 23:00 UTC (permalink / raw)
To: git
In-Reply-To: <7virk3l07a.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Jakub Narebski wrote:
>>
>>> index 199fbe87384cd3f4686916277dd124cefc751e8a..f3b762de92e579300eba3f53ee26b2a80b4e76c7 100644
>>
>> Hmmm... I do wonder why --binary implies --full-index option.
>
> Patch safety. Yours happened to be a creation patch so it might
> not matter in this particular case, but we would want to be
> reasonably sure there is no ambiguity in the preimage when you
> are doing a modification patch.
Couldn't we do this (show full sha1) only for the binary part of patch?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH 3/5] autoconf: Preliminary check for working mmap
From: Jakub Narebski @ 2006-09-04 22:56 UTC (permalink / raw)
To: git
In-Reply-To: <200609050054.24279.jnareb@gmail.com>
Use AC_FUNC_MMAP check to check if the `mmap' function exists and
works correctly. (It only checks private fixed mapping of
already-mapped memory.)
Still it is better than having no mmap check at all.
Attention: uses implementation detail of AC_FUNC_MMAP!
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This patch sent earlier in other patch series and dropped,
as git uses private mapping, not private fixed. I think
that this check is better than no check at all...
config.mak.in | 2 +-
configure.ac | 7 +++++++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/config.mak.in b/config.mak.in
index 2947560..2c8fd2c 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -37,6 +37,6 @@ NO_C99_FORMAT=@NO_C99_FORMAT@
NO_STRCASESTR=@NO_STRCASESTR@
NO_STRLCPY=@NO_STRLCPY@
NO_SETENV=@NO_SETENV@
-#NO_MMAP=@NO_MMAP@
+NO_MMAP=@NO_MMAP@
#NO_ICONV=@NO_ICONV@
diff --git a/configure.ac b/configure.ac
index fc5b813..799321e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -249,6 +249,13 @@ AC_CHECK_FUNC(setenv,
AC_SUBST(NO_SETENV)
#
# Define NO_MMAP if you want to avoid mmap.
+AC_FUNC_MMAP
+if test $ac_cv_func_mmap_fixed_mapped != yes; then
+ NO_MMAP=YesPlease
+else
+ NO_MMAP=
+fi
+AC_SUBST(NO_MMAP)
#
# Define NO_ICONV if your libc does not properly support iconv.
--
1.4.1.1
^ permalink raw reply related
* [PATCH 5/5] autoconf: Quote AC_CACHE_CHECK arguments
From: Jakub Narebski @ 2006-09-04 22:58 UTC (permalink / raw)
To: git
In-Reply-To: <200609050054.24279.jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Just in case.
configure.ac | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac
index 67a7aa9..85317a3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -205,8 +205,8 @@ # Define NO_C99_FORMAT if your formatted
# do not support the 'size specifiers' introduced by C99, namely ll, hh,
# j, z, t. (representing long long int, char, intmax_t, size_t, ptrdiff_t).
# some C compilers supported these specifiers prior to C99 as an extension.
-AC_CACHE_CHECK(whether formatted IO functions support C99 size specifiers,
- ac_cv_c_c99_format,
+AC_CACHE_CHECK([whether formatted IO functions support C99 size specifiers],
+ [ac_cv_c_c99_format],
[# Actually git uses only %z (%zu) in alloc.c, and %t (%td) in mktag.c
AC_RUN_IFELSE(
[AC_LANG_PROGRAM([AC_INCLUDES_DEFAULT],
@@ -268,8 +268,8 @@ # Define NO_SYMLINK_HEAD if you never wa
# Enable it on Windows. By default, symrefs are still used.
#
# Define WITH_OWN_SUBPROCESS_PY if you want to use with python 2.3.
-AC_CACHE_CHECK(for subprocess.py,
- ac_cv_python_has_subprocess_py,
+AC_CACHE_CHECK([for subprocess.py],
+ [ac_cv_python_has_subprocess_py],
[if $PYTHON_PATH -c 'import subprocess' 2>/dev/null; then
ac_cv_python_has_subprocess_py=yes
else
--
1.4.1.1
^ permalink raw reply related
* [PATCH 4/5] autoconf: Check for subprocess.py
From: Jakub Narebski @ 2006-09-04 22:57 UTC (permalink / raw)
To: git
In-Reply-To: <200609050054.24279.jnareb@gmail.com>
Add custom test for checking if Python comes with subprocess.py, or
should we use our own subprocess.py by defining WITH_OWN_SUBPROCESS_PY.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Taken from Makefile.
Perhaps we would get rid of Python dependency soon.
configure.ac | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 799321e..67a7aa9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -268,6 +268,16 @@ # Define NO_SYMLINK_HEAD if you never wa
# Enable it on Windows. By default, symrefs are still used.
#
# Define WITH_OWN_SUBPROCESS_PY if you want to use with python 2.3.
+AC_CACHE_CHECK(for subprocess.py,
+ ac_cv_python_has_subprocess_py,
+[if $PYTHON_PATH -c 'import subprocess' 2>/dev/null; then
+ ac_cv_python_has_subprocess_py=yes
+else
+ ac_cv_python_has_subprocess_py=no
+fi])
+if test $ac_cv_python_has_subprocess_py != yes; then
+ GIT_CONF_APPEND_LINE([WITH_OWN_SUBPROCESS_PY=YesPlease])
+fi
#
# Define NO_ACCURATE_DIFF if your diff program at least sometimes misses
# a missing newline at the end of the file.
--
1.4.1.1
^ permalink raw reply related
* [PATCH 2/5] autoconf: Add -liconv to LIBS when NEEDS_LIBICONV
From: Jakub Narebski @ 2006-09-04 22:55 UTC (permalink / raw)
To: git
In-Reply-To: <200609050054.24279.jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Just in case; it could matter for testing if iconv is properly
supported (NO_ICONV test).
configure.ac | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 36f9cd9..fc5b813 100644
--- a/configure.ac
+++ b/configure.ac
@@ -147,6 +147,7 @@ AC_CHECK_LIB([c], [iconv],
[NEEDS_LIBICONV=],
[NEEDS_LIBICONV=YesPlease])
AC_SUBST(NEEDS_LIBICONV)
+test -n "$NEEDS_SOCKET" && LIBS="$LIBS -liconv"
#
# Define NEEDS_SOCKET if linking with libc is not enough (SunOS,
# Patrick Mauritz).
--
1.4.1.1
^ permalink raw reply related
* [PATCH 1/5] autoconf: Add some commented out variables to config.mak.in
From: Jakub Narebski @ 2006-09-04 22:55 UTC (permalink / raw)
To: git
In-Reply-To: <200609050054.24279.jnareb@gmail.com>
Add commented out variables for the features which can be detected by
autoconf, but are not implemented yet, to config.mak.in file.
This way we can easily see which tests are not implemented yet.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
config.mak.in | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/config.mak.in b/config.mak.in
index 369e611..2947560 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -37,4 +37,6 @@ NO_C99_FORMAT=@NO_C99_FORMAT@
NO_STRCASESTR=@NO_STRCASESTR@
NO_STRLCPY=@NO_STRLCPY@
NO_SETENV=@NO_SETENV@
+#NO_MMAP=@NO_MMAP@
+#NO_ICONV=@NO_ICONV@
--
1.4.1.1
^ permalink raw reply related
* [PATCH 0/5] Some autoconf patches
From: Jakub Narebski @ 2006-09-04 22:54 UTC (permalink / raw)
To: git
This is set of a few autoconf patches, based on 'master'
(commit 6b4fd65cce00d4adb5dd3ed2960ba355057c5a97)
What is left is check if "libc/libiconv properly support iconv.",
i.e. NO_ICONV check.
Summary:
---
config.mak.in | 2 ++
configure.ac | 22 ++++++++++++++++++++--
2 files changed, 22 insertions(+), 2 deletions(-)
Shortlog:
* [PATCH 1/5] autoconf: Add some commented out variables to config.mak.in
* [PATCH 2/5] autoconf: Add -liconv to LIBS when NEEDS_LIBICONV
* [PATCH 3/5] autoconf: Preliminary check for working mmap
* [PATCH 4/5] autoconf: Check for subprocess.py
* [PATCH 5/5] autoconf: Quote AC_CACHE_CHECK arguments
--
Jakub Narebski
ShadeHawk on #git
Poland
^ permalink raw reply
* Re: [PATCH 1/4] gitweb: Add GIT favicon, assuming image/png type
From: Junio C Hamano @ 2006-09-04 22:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <edhrij$l9j$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Jakub Narebski wrote:
>
>> index 199fbe87384cd3f4686916277dd124cefc751e8a..f3b762de92e579300eba3f53ee26b2a80b4e76c7 100644
>
> Hmmm... I do wonder why --binary implies --full-index option.
Patch safety. Yours happened to be a creation patch so it might
not matter in this particular case, but we would want to be
reasonably sure there is no ambiguity in the preimage when you
are doing a modification patch.
^ permalink raw reply
* Re: [PATCH] Do 3-way diff between HEAD, index and working directory
From: Junio C Hamano @ 2006-09-04 22:23 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17660.4160.642852.177249@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> This implements a 3-way diff between the HEAD commit, the state in the
> index, and the working directory. This is like the n-way diff for a
> merge, and uses much of the same code. It is invoked with the -c flag
> to git-diff-index, which it already accepted and did nothing with.
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
> Junio, does this look right?
Seems correct from a cursory look. This also seems to change
the behaviour for an unmerged entry case slightly but I think
it is for the better (depending on the definition of "better" --
some people may feel combined diff to be weird and confusing).
^ permalink raw reply
* Re: [PATCH][RFC] Add git-archive-tree
From: Junio C Hamano @ 2006-09-04 22:20 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git
In-Reply-To: <44FCA272.7040907@lsrfire.ath.cx>
Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Junio C Hamano schrieb:
>...
> Well, this is just _one_ of the positions I've taken on this topic, I
> have to admit. Franck then convinced me that merging downloader and
> archiver into one command is nice for users (less commands to remember,
> keeps existing --remote option) even if it doesn't make sense
> technically, because their implementations have nothing in common.
Ah, I was not following the thread closely and I agree with you
and Franck now in that smaller number of commands the better.
(IOW, download-archive in my 3-item list is not needed in the
end user UI and can be implemented as "git-archive-tree
--remote=<repo>).
Thanks for clarification.
^ permalink raw reply
* Re: [PATCH][RFC] Add git-archive-tree
From: Rene Scharfe @ 2006-09-04 22:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Franck Bui-Huu, Git Mailing List
In-Reply-To: <7vy7szmm1u.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano schrieb:
> So to recap:
>
> - "git-archive-tree --format <foo> <foo specific options> <tree>"
> would know how to create <foo> format archive and send the result to
> stdout.
>
> - "git-download-archive <repo> <git-archive-tree-command-line>" would
> talk with "git-upload-archive" in the remote repository, give
> archive-tree command line to it and receives the result.
>
> - "git-upload-archive <repo>" is not used by the end user. Underlying
> git-archive-tree command line options are sent over the protocol from
> download-archive, just like upload-tar does.
>
> If this is what you mean, I think three of us are in agreement here.
Well, this is just _one_ of the positions I've taken on this topic, I
have to admit. Franck then convinced me that merging downloader and
archiver into one command is nice for users (less commands to remember,
keeps existing --remote option) even if it doesn't make sense
technically, because their implementations have nothing in common.
This is a bikeshed colour discussion, and I'm bad at it. I'll shut up
on this and simply follow the directions above.
>> My next steps will be to make traverse_tree() support path specs,
>> in order to achieve feature parity with read_tree_recursive(). I
>> hope that the former keeps being significantly faster than the
>> latter even after that.
>
> A thing that have been bothering me for some time in pathspec area is
> that we have two (eh perhaps three) quite different pathspec
> semantics.
>
> - diff-tree family (and anything based on revision.c including
> git-log) is a strict prefix directory match (e.g. no wildcards, and
> "Documentation/howto" matches the directory but not
> "Documentation/howto-index.sh")
>
> - ls-files family (ls-files used to be an one odd man out, but
> git-grep mimics it, and "git-commit <paths>" uses ls-files internally
> so they form a family) is prefix match with fnmatch match upon
> wildcard (e.g. "Documentation/howto" still matches the directory but
> not "Documentation/howto-index.sh", but you can say
> "Documentation/howto*" to match both, and you can even say
> "Document*").
>
> The former semantics is very friendly with "struct tree_desc" based
> traversal. Allowing pathspecs with ls-files style matching would
> probably more useful but more work. And there are at least four
> implementations of pathspec matcher with slightly different
> interfaces (ugh, sorry) if I am not mistaken: builtin-ls-files.c has
> one (match), tree-diff.c has another (interesting), builtin-grep.c
> has one (pathspec_matches), dir.c has another (match_pathspec).
>
> We might be able to share code with para-walk.c in "pu" (it is
> designed to walk zero or more trees optionally with index and working
> tree in parallel and we would be using it to walk only single tree
> without index nor working tree). That would give me an incentive to
> clean up the code ;-) Currently it is a ten "WIP" patch series.
>
> One thing it attempts to do on the side is to consolidate the
> diff-tree style ones into one by introducing another in read-cache.c
> (pathname_included) but it does not convert existing users of other
> matchers to use it yet.
Interesting. OK, I'll check out the existing implementations with an
eye on consolidation and also take a look around that scary place named
'pu'. ;-)
So far I have failed in creating a traverse_tree() function with path
spec match support which also is faster than read_tree_recursive().
Maybe the speed difference between 'git-tar-tree' and 'git-archive-tree
-ftar' is caused by something else. I keep on trying.
René
^ permalink raw reply
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