* Re: HOWTO set up a repository which can be pushed into over HTTP
From: Johannes Schindelin @ 2006-08-08 23:11 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, git
In-Reply-To: <20060808190220.GA6001@nospam.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 7646 bytes --]
Hi,
On Tue, 8 Aug 2006, Rutger Nijlunsing wrote:
> On Mon, Aug 07, 2006 at 12:55:43AM -0700, Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > Do people find it useful? Or would you like to wait until I implement an
> > > option in git-http-push to actually init an HTTP repo remotely?
> >
> > I do not have need for push over http-dav at the moment myself,
> > but I would imagine I would certainly look for it when I would
> > need to later.
> >
> > Do people find it useful? More importantly, has somebody else
> > independently tried to follow the documentation and found the
> > description accurate and helpful?
>
> Today I did try to follow it, and it made an otherwise impossible job
> for me doable, although still taking too much hours and a patch. The
> 'impossible job' for me had to do with my zero-apache experience and
> (probably) a bug in WebDAV.
Thank you for doing that valuable work! I think the patch is fine (take
that as an Acked-by:); next time you might want to send it as a proper
patch mail ;-)
> -This text assumes that you
> -
> -- have an Apache webserver,
> -- can edit the configuration of it,
> -- can restart it, and
> +
> +What's needed:
> +
> +- Have an Apache webserver
> +
> + On Debian:
> + $ apt-get install apache2
> + To get apache2 by default started,
> + edit /etc/default/apache2 and set NO_START=0
> +
> +- can edit the configuration of it
> +
> + On Debian: this means being able to edit files under /etc/apache2
On some other setups, it is /etc/httpd/. Since it is not specific to
Debian, we might want to give some common options, but refer the user to
the Apache manual if she cannot find it.
> +
> +- can restart it.
> + 'apachectl --graceful' might do.
It is Ã'apachectl graceful' here (without'--').
> + On Debian:
> + $ /etc/init.d/apache2 restart
This should work everywhere, except it might be called apache or httpd
instead. However, please warn users that this interrupts (however briefly)
a running webserver, and if you do that on a production machine, users
just downloading an iso file might be rightfully upset.
> - have permissions to chown a directory
>
> +In effect, this probably means you're going to be root.
Right.
> - $ cd /usr/local/apache/htdocs
> - $ mkdir my-new-repo.git
> + $ cd /usr/local/apache/htdocs
> + $ mkdir my-new-repo.git
> +
> + On Debian:
> +
> + $ cd /var/www
> + $ mkdir my-new-repo.git
Again, it might be cooler to be a bit more portable: if the user found
httpd.config, he could just "grep DocumentRoot /where/ever/httpd.conf".
> Change the ownership to your webserver's credentials
> +
> + $ chown -R www.www .
> +
> + On Debian:
> +
> + $ chown -R www-data.www-data .
Again, a better way would be to direct the user to "grep ^User httpd.conf"
and "grep ^Group httpd.conf".
> +Restart apache2, and check whether http://server/my-new-repo.git gives
> +a directory listing. If not, check whether apache started up
> +succesfully.
A useful addition.
> Step 2: enable DAV on this repository
> -------------------------------------
>
> -In your httpd.conf, make sure that this line exists:
> +In your httpd.conf, make sure that this line exists which is the file
> +used for locking DAV operations:
> +
> + DAVLockDB "/usr/local/apache2/temp/DAV.lock"
> +
> + On Debian:
>
> - DAVLockDB "/usr/local/apache2/temp/DAV.lock"
> + Enable the dav and dav_fs modules of apache:
> + $ a2enmod dav_fs
> + $ a2enmod dav
> + The DAV lock is located in /etc/apache2/mods-available/dav_fs.conf:
> + DAVLockDB /var/lock/apache2/DAVLock
I did not find a2enmod on my only Debian setup, so a more portable way
would be to tell the user to insert the following lines in httpd.conf:
LoadModule dav_module libexec/httpd/libdav.so
AddModule mod_dav.c
(I do not know if there are setups where you have to load dav_fs
explicitely...)
> Then, add something like this to your httpd.conf
>
> - <Location /my-new-repo.git>
> - DAV on
> - AuthType Basic
> - AuthName "Git"
> - AuthUserFile /usr/local/apache2/conf/passwd.git
> - Require valid-user
> - </Location>
> + <Location /my-new-repo.git>
> + DAV on
> + AuthType Basic
> + AuthName "Git"
> + AuthUserFile /usr/local/apache2/conf/passwd.git
> + Require valid-user
> + </Location>
> +
> + On Debian:
> + Create (or add to) /etc/apache2/conf.d/git.conf :
Is this picked up automatically?
> + <Location /my-new-repo.git>
> + DAV on
> + AuthType Basic
> + AuthName "Git"
> + AuthUserFile /etc/apache2/passwd.git
> + Require valid-user
> + </Location>
We should not violate the DRY principle ("Don´'Repeat Yourself").
> +
> +The password file can be somewhere else, but it has to be readable by
> +Apache and preferably not readable by the world.
>
> -The password file can be somewhere else, but it has to be readable by
> -Apache.
> +Create this file by
> + $ htpasswd -c /usr/local/apache2/conf/passwd.git <user>
>
> -You can create this file by
> + On Debian:
> + $ htpasswd -c /etc/apache2/passwd.git <user>
>
> - $ htpasswd -c /usr/local/apache2/conf/passwd.git <user>
> -
> -you will be asked a password, and the file is created. Subsequent calls
> +You will be asked a password, and the file is created. Subsequent calls
> to htpasswd should omit the '-c' option, since you want to append to the
> existing file.
>
> -You need to restart Apache; 'apachectl --graceful' is sufficient.
So, it was my fault to begin with: the '--' is wrong.
> +Now go to http://<username>@<servername>/my-new-repo.git in your
> +browser to check whether it asks for a password and accepts the right
> +password.
Helpful.
> +On Debian:
> +
> + To test the WebDAV part, do:
> +
> + $ apt-get install litmus
> + $ litmus http://<servername>/my-new-repo.git <username> <password>
There has to be a more portable way to test WebDAV, like an URL to type
into a webbrowser. DAV wizards, anyone?
> -Then, add the following to your .netrc (you can do without, but will be
> +Then, add the following to your ~/.netrc (you can do without, but will be
Okay, I thought it was common knowledge where this resides. Although I
would say $HOME/.netrc instead.
> +...and set permissions:
> + chmod 600 ~/.netrc
Yeah, right. I always forget about this.
> + On Windows, use %HOMEDRIVE%%HOMEPATH%.netrc instead.
Huh? You want to access it with something else than cygwin?
> +To check whether all is OK, do:
> +
> + curl --netrc --location -v http://<username>@<servername>/my-new-repo.git/
> +
> +...this should give a directory listing in HTML of /var/www/my-new-repo.git .
Does everybody who has libcurl installed, have curl installed also?
> >From your client repository, do
>
> - $ git-http-push upload master
> + $ git push upload master
> +
> +This pushes branch 'master' (which is assumed to be the branch you
> +want to export) to repository called 'upload', which we previously
> +defined with git-repo-config.
>
> -(This assumes that the branch you want to export is called 'master' in your
> -client setup...)
Your wording is much clearer.
> request; This can happen when you start Apache, but then disable the
> network interface. A simple restart of Apache helps.
>
> -In other cases, reading /usr/local/apache2/logs/error_log is often helpful.
> -
> +Errors like (22/502) are of format (curl error code/http error
> +code). So (22/404) means something like 'not found' at the server.
I think the error log is more useful than the http error codes.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Racy git: avoid having to be always too careful
From: Junio C Hamano @ 2006-08-08 23:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.63.0608090030080.1800@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Okay, how about 100 paths? And make _this_ a config variable?
Actually, I have a better patch I'll be pushing out in "next"
this evening.
Hint: ce_write() batches and buffers things, so "now" obtained
in the current code is unreliable.
^ permalink raw reply
* Re: Trouble building newer git with older
From: Nishanth Aravamudan @ 2006-08-08 22:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j1jvvh7.fsf@assigned-by-dhcp.cox.net>
On 08.08.2006 [13:11:16 -0700], Junio C Hamano wrote:
> Nishanth Aravamudan <nacc@us.ibm.com> writes:
>
> > This is because GIT-VERSION-GEN attempts to invoke `git describe` but
> > describe is not a valid parameter to the current version of git. This is
> > not treated as a failure case, though, as output is stored in VN.
> > Perhaps the return code of `git describe` should also be checked? Or am
> > I just not supposed to upgrade from this old of a version of git via
> > git?
>
> No, it was broken when this patch was applied.
>
> commit 1100ac81a90b03e0c037a286569a340decf7489b
> Author: Sean <seanlkml@sympatico.ca>
> Date: Mon May 22 00:39:52 2006 -0400
>
> Luckily, my copy of GNU interactive tools, when invoked like this:
>
> git describe --abbrev=4 HEAD 2>/dev/null
>
> exits with an error code 1, so the existing code already catches it.
>
> How about this patch?
>
> -- >8 --
> GIT-VERSION-GEN: adjust for ancient git
>
> When an ancient "git" that does not understand "describe"
> command is on the $PATH, "git describe" emitted a Usage message
> without exiting non-zero status (which is a mistake we cannot
> fix retroactively). Catch this case to make sure we do not try
> using phoney multi-line string as a version number.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
Looks good to me and I can confirm this fixes the problem here.
Acked-by: Nishanth Aravamudan <nacc@us.ibm.com>
Thanks,
Nish
^ permalink raw reply
* Re: fast-import and unique objects.
From: Shawn Pearce @ 2006-08-08 22:45 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910608080511t5aa96865p41d6bc1b85e236fa@mail.gmail.com>
Jon Smirl <jonsmirl@gmail.com> wrote:
> We're designing a dumpfile format for git like the one SVN has.
I'm not sure I'd call it a dumpfile format. More like an importfile
format. Reading a GIT pack is really pretty trivial; if someone was
going to write a parser/reader to pull apart a GIT repository and
use that information in another way they would just do it against
the pack files. Its really not that much code. But generating a
pack efficiently for a large volume of data is slightly less trivial;
the attempt here is to produce some tool that can take a relatively
trivial data stream and produce a reasonable (but not necessarily
absolute smallest) pack from it in the least amount of CPU and
disk time necessary to do the job. I would hope that nobody would
seriously consider dumping a GIT repository back INTO this format!
[snip]
> AFAIK the svn code doesn't do merge commits. We probably need a post
> processing pass in the git repo that finds the merges and closes off
> the branches. gitk won't be pretty with 1,500 open branches. This may
> need some manual clues.
*wince* 1500 open branches. Youch. OK, that answers a lot of
questions for me with regards to memory handling in fast-import.
Which you provide excellent suggestions for below. I guess I didn't
think you had nearly that many...
[snip]
> The file names are used over and over. Alloc a giant chunk of memory
> and keep appending the file name strings to it. Then build a little
> tree so that you can look up existing names. i.e. turn the files names
> into atoms. Never delete anything.
Agreed. For 1500 branches its worth doing.
[snip]
> About 100,000 files in the initial change set that builds the repo.
> FInal repo has 120,000 files.
>
> There are 1,500 branches. I haven't looked at the svn dump file format
> for branches, but I suspect that it sends everything on a branch out
> at once and doesn't intersperse it with the trunk commits.
If you can tell fast-import your are completely done processing a
branch I can recycle the memory I have tied up for that branch; but
if that's going to be difficult then... hmm.
Right now I'm looking at around 5 MB/branch, based on implementing
the memory handling optimizations you suggested. That's still *huge*
for 1500 branches. I clearly can't hang onto every branch in memory
for the entire life of the import like I was planning on doing.
I'll kick that around for a couple of hours and see what I come
up with.
--
Shawn.
^ permalink raw reply
* [PATCH] mv: strcat -> strcpy to account for uninitialized memory
From: Johannes Schindelin @ 2006-08-08 22:36 UTC (permalink / raw)
To: Juergen Ruehle; +Cc: Jon Smirl, git, junkio, Josef Weidendorfer
In-Reply-To: <17624.55600.423000.61479@lapjr.intranet.kiel.bmiag.de>
At one stage, the code assumed erroneously that the memory was initialized
to zero.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
On Tue, 8 Aug 2006, Juergen Ruehle wrote:
> This might have been fixed already (my tree is a couple of days old),
> but the strcat fails for me, because the alloced memory is not
> cleared.
>
> Johannes Schindelin writes:
> > +static const char *add_slash(const char *path)
> > +{
> > + int len = strlen(path);
> > + if (path[len - 1] != '/') {
> > + char *with_slash = xmalloc(len + 2);
> > + memcpy(with_slash, path, len);
> > + strcat(with_slash + len, "/");
Oops. That strcat should be a strcpy, obviously.
builtin-mv.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-mv.c b/builtin-mv.c
index e47942c..5f57870 100644
--- a/builtin-mv.c
+++ b/builtin-mv.c
@@ -48,7 +48,7 @@ static const char *add_slash(const char
if (path[len - 1] != '/') {
char *with_slash = xmalloc(len + 2);
memcpy(with_slash, path, len);
- strcat(with_slash + len, "/");
+ strcpy(with_slash + len, "/");
return with_slash;
}
return path;
--
1.4.2.rc3.g6b27-dirty
^ permalink raw reply related
* Re: [PATCH/RFC] gitweb: Great subroutines renaming
From: Jakub Narebski @ 2006-08-08 22:33 UTC (permalink / raw)
To: git
In-Reply-To: <7vu04mucaq.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> - git_blob_plain_mimetype => blob_plain_mimetype
>
> Does it matter that the function is used in blob-plain? In
> other words, how would this function, blob-plain-mimetype, be
> different if we were to have another function called blob-mimetype?
>
> How about calling it "guess-mimetype"?
There are two functions, mimetype_guess_file and mimetype_guess, of which
first one gets mimetype of file based on specified mime.types like file,
second tries $mimetypes_file then '/etc/mime.types', while currently named
git_blob_plain_mimetype subroutine first tries mimetype_guess, then checks
if the file is text file (-T $fd) and if not uses some built in mime.types
rules. Perhaps current mimetype_guess could be embedded into current
git_blob_plain_mimetype.
All those subroutines need better names I think.
>> - git_page_nav => git_print_page_nav
>> - git_header_div => git_print_header_div
>
> Both sounds sane (I would have said "git-show-blah" if I were
> doing this myself, though).
They are called among print statements. I'm not sure if some of them
wouldn't be better converted to format_* types subroutines.
>> - read_info_ref => git_read_info_refs => git_get_references
>> (this one depend too much on implementation, which might be changed to
>> parsing 'git ls-remotes .' output instead of relying on info/refs being
>> up to date thanks to git-update-server-info in post-update hook,
>> and on its format).
>
> I am not worried too much about the format (because clone/fetch
> over http depends on it), but reading from ls-remote self would
> make it unnecessary to run update-server-info if a repo is not
> served over http but is shown over gitweb.
Do the git_get_references for this subroutine, which returns hashref which
keys are ids, and values are refs pointing to the key id, sounds good?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Racy git: avoid having to be always too careful
From: Johannes Schindelin @ 2006-08-08 22:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vr6zrw352.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 8 Aug 2006, Junio C Hamano wrote:
> Another possibility is to tweak the heuristics -- currently we
> say 20 paths or 1/4 of whole paths is too many and would cause
> too much runtime hit but that was done without any measurement.
> We could raise the threashold which would solve the case for the
> testsuite whose trees are all small.
Okay, how about 100 paths? And make _this_ a config variable?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: Great subroutines renaming
From: Junio C Hamano @ 2006-08-08 21:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ebauq1$kcb$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Summary of discussion: using *_read_* to distinguish between git calling
> commands, and file reading commands is not a good idea. So now the
> guideline is to be more fluid with *_get_* vs *_read_* subroutine naming:
> it would depend on the noun after _get_ or _read_.
I suspect it is summary of discussion between you and yourself ;-).
I still do not think get_* vs read_* mean anything. You get
information somehow, and maybe reading from a pre-existing file
might be one way to do so, or reading from a pipe to a command
might be another way to do so, but it does not change an iota
that you are retrieving information.
> Proposed renames:
> 1. Renames I think everybody would agree on
> - git_get_referencing => format_mark_referencing
>
> - date_str => parse_date
> - git_read_tag => parse_tag
> - git_read_commit => parse_commit
>
> - git_blob_plain_mimetype => blob_plain_mimetype
Does it matter that the function is used in blob-plain? In
other words, how would this function, blob-plain-mimetype, be
different if we were to have another function called blob-mimetype?
How about calling it "guess-mimetype"?
> - git_page_nav => git_print_page_nav
> - git_header_div => git_print_header_div
Both sounds sane (I would have said "git-show-blah" if I were
doing this myself, though).
> - git_read_head => git_get_head_hash
> - git_read_hash => git_get_hash_by_ref
Both sounds sane.
> - git_read_description => git_project_description
No verbs in the renamed one feels awkward.
git-get-project-description, perhaps.
> - git_read_projects => git_get_projects_list or git_list_projects
list-projects is probably the most natural name for something
that gives a list to the end user. If you are getting the list
in-core for further processing, the name is misleading.
Perhaps git-get-projects-list is more appropriate.
> - read_info_ref => git_read_info_refs => git_get_references
> (this one depend too much on implementation, which might be changed to
> parsing 'git ls-remotes .' output instead of relying on info/refs being
> up to date thanks to git-update-server-info in post-update hook,
> and on its format).
I am not worried too much about the format (because clone/fetch
over http depends on it), but reading from ls-remote self would
make it unnecessary to run update-server-info if a repo is not
served over http but is shown over gitweb.
> - age_string => ????
Good name as is, but if you want consistent, it formats the
timestamp into age, so it would fall into format-blah family.
^ permalink raw reply
* Re: [PATCH] autoconf: clean temporary file mak.append
From: Junio C Hamano @ 2006-08-08 21:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ebatsd$f1g$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> diff --git a/Makefile b/Makefile
>> index d8cc835..d4297c2 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -793,7 +793,7 @@ clean:
>> rm -f $(ALL_PROGRAMS) $(BUILT_INS) git$X
>> rm -f *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags
>> rm -rf autom4te.cache
>> - rm -f config.log config.mak.autogen configure config.status config.cache
>> + rm -f configure config.log config.mak.autogen config.mak.append config.status config.cache
>> 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
>
> I didn't add configure to make clean, because there was hand-crafted
> configure script in git.git.
Did anybody ask who added 'configure'?
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: Great subroutines renaming
From: Jakub Narebski @ 2006-08-08 21:13 UTC (permalink / raw)
To: git
In-Reply-To: <200608071626.52655.jnareb@gmail.com>
Jakub Narebski wrote:
> Renames:
> - git_get_referencing => format_mark_referencing
> - git_read_head => git_get_head
> - read_info_ref => git_read_info_refs
> - date_str => parse_date
> - git_read_tag => parse_tag
> - git_read_commit => parse_commit
> - git_blob_plain_mimetype => blob_plain_mimetype
> - git_page_nav => git_print_page_nav
> - git_header_div => git_print_header_div
Summary of discussion: using *_read_* to distinguish between git calling
commands, and file reading commands is not a good idea. So now the
guideline is to be more fluid with *_get_* vs *_read_* subroutine naming:
it would depend on the noun after _get_ or _read_.
Proposed renames:
1. Renames I think everybody would agree on
- git_get_referencing => format_mark_referencing
- date_str => parse_date
- git_read_tag => parse_tag
- git_read_commit => parse_commit
- git_blob_plain_mimetype => blob_plain_mimetype
- git_page_nav => git_print_page_nav
- git_header_div => git_print_header_div
2. Renames about which I'm less sure
- git_read_head => git_get_head_hash
- git_read_hash => git_get_hash_by_ref
- git_read_description => git_project_description
- git_read_projects => git_get_projects_list or git_list_projects
- read_info_ref => git_read_info_refs => git_get_references
(this one depend too much on implementation, which might be changed to
parsing 'git ls-remotes .' output instead of relying on info/refs being
up to date thanks to git-update-server-info in post-update hook,
and on its format).
- age_string => ????
(it returns 'nn ago' string)
Thoughts? Comments? I'm especially interested in answer of other people
working on gitweb (Luben Tuikov, Matthias Lederhofer, Jeff King,
Sham Chukoury, and others).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] autoconf: clean temporary file mak.append
From: Jakub Narebski @ 2006-08-08 20:58 UTC (permalink / raw)
To: git
In-Reply-To: <7vk65juff7.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> diff --git a/Makefile b/Makefile
> index d8cc835..d4297c2 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -793,7 +793,7 @@ clean:
> rm -f $(ALL_PROGRAMS) $(BUILT_INS) git$X
> rm -f *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags
> rm -rf autom4te.cache
> - rm -f config.log config.mak.autogen configure config.status config.cache
> + rm -f configure config.log config.mak.autogen config.mak.append config.status config.cache
> 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
I didn't add configure to make clean, because there was hand-crafted
configure script in git.git.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] autoconf: clean temporary file mak.append
From: Junio C Hamano @ 2006-08-08 20:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200608081834.09271.jnareb@gmail.com>
When configure is interrupted in the middle it leaves
config.mak.append behind. Add it to .gitignore and make sure
$(MAKE) clean removes it.
Also earlier .gitignore listed config.mak.in which is a tracked
file. Fix it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* on top of today's 5 series from you.
.gitignore | 2 +-
Makefile | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/.gitignore b/.gitignore
index fb0fa3f..6e973b3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -140,7 +140,7 @@ config.mak
autom4te.cache
config.log
config.status
-config.mak.in
config.mak.autogen
+config.mak.append
configure
git-blame
diff --git a/Makefile b/Makefile
index d8cc835..d4297c2 100644
--- a/Makefile
+++ b/Makefile
@@ -793,7 +793,7 @@ clean:
rm -f $(ALL_PROGRAMS) $(BUILT_INS) git$X
rm -f *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags
rm -rf autom4te.cache
- rm -f config.log config.mak.autogen configure config.status config.cache
+ rm -f configure config.log config.mak.autogen config.mak.append config.status config.cache
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.2.rc3.g45c5
^ permalink raw reply related
* Re: [PATCH/RFC] gitweb: Great subroutines renaming
From: Jakub Narebski @ 2006-08-08 20:24 UTC (permalink / raw)
To: git
In-Reply-To: <7voduvugl9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Wouldn't it be better to (re)use notation of rpm's --query-format,
>> i.e. use %{name}, or %30{name}, or %-30{name} for single scalar values,
>> use :typetag output formats,...
>
> I did not do them because these enhancements are not needed to
> unblock you from optimizing git_get_* calls in gitweb. These
> enhancement can come later as long as the initial syntax is
> simple, clean and extensible enough, which I think it is.
Yes, that's true. I'm wondering if %(fieldname) of %{fieldname} would be
better.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: Great subroutines renaming
From: Junio C Hamano @ 2006-08-08 20:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eb9m30$3ef$2@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> `git-ls-remotes .` is suspiciously missing from the examples.
Because the point of show-refs was not to replace it only for
the local case.
> Format needs to somewhat incorporate line for referencing object for that,
> if it exists.
Also I do not think you would want "ref^{}" style dereferencing
ls-remotes does for gitweb anyway.
What gitweb might want is "what type of object is this tag
pointing at" and "what is the object pointed at by this tag"
(both used on "Tags" list). I think show-refs specification
allows you to do that inexpensively.
> Wouldn't it be better to (re)use notation of rpm's --query-format,
> i.e. use %{name}, or %30{name}, or %-30{name} for single scalar values,
> use :typetag output formats,...
I did not do them because these enhancements are not needed to
unblock you from optimizing git_get_* calls in gitweb. These
enhancement can come later as long as the initial syntax is
simple, clean and extensible enough, which I think it is.
^ permalink raw reply
* Re: Trouble building newer git with older
From: Junio C Hamano @ 2006-08-08 20:11 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: git
In-Reply-To: <20060808184716.GC4546@us.ibm.com>
Nishanth Aravamudan <nacc@us.ibm.com> writes:
> This is because GIT-VERSION-GEN attempts to invoke `git describe` but
> describe is not a valid parameter to the current version of git. This is
> not treated as a failure case, though, as output is stored in VN.
> Perhaps the return code of `git describe` should also be checked? Or am
> I just not supposed to upgrade from this old of a version of git via
> git?
No, it was broken when this patch was applied.
commit 1100ac81a90b03e0c037a286569a340decf7489b
Author: Sean <seanlkml@sympatico.ca>
Date: Mon May 22 00:39:52 2006 -0400
Luckily, my copy of GNU interactive tools, when invoked like this:
git describe --abbrev=4 HEAD 2>/dev/null
exits with an error code 1, so the existing code already catches it.
How about this patch?
-- >8 --
GIT-VERSION-GEN: adjust for ancient git
When an ancient "git" that does not understand "describe"
command is on the $PATH, "git describe" emitted a Usage message
without exiting non-zero status (which is a mistake we cannot
fix retroactively). Catch this case to make sure we do not try
using phoney multi-line string as a version number.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 1ce217d..14923c9 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -3,9 +3,17 @@ #!/bin/sh
GVF=GIT-VERSION-FILE
DEF_VER=v1.4.2.GIT
+LF='
+'
+
# First try git-describe, then see if there is a version file
# (included in release tarballs), then default
-if VN=$(git describe --abbrev=4 HEAD 2>/dev/null); then
+if VN=$(git describe --abbrev=4 HEAD 2>/dev/null) &&
+ case "$VN" in
+ *$LF*) (exit 1) ;;
+ v[0-9]*) : happy ;;
+ esac
+then
VN=$(echo "$VN" | sed -e 's/-/./g');
elif test -f version
then
^ permalink raw reply related
* [PATCH] git-push: allow pushing from subdirectories
From: Jeff King @ 2006-08-08 20:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The semantics are equivalent to pushing from the root; we just try harder to
find the .git directory.
Signed-off-by: Jeff King <peff@peff.net>
---
git.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git.c b/git.c
index 6e72a89..18ba14a 100644
--- a/git.c
+++ b/git.c
@@ -229,7 +229,7 @@ static void handle_internal_command(int
{ "log", cmd_log, NEEDS_PREFIX | USE_PAGER },
{ "whatchanged", cmd_whatchanged, NEEDS_PREFIX | USE_PAGER },
{ "show", cmd_show, NEEDS_PREFIX | USE_PAGER },
- { "push", cmd_push },
+ { "push", cmd_push, NEEDS_PREFIX },
{ "format-patch", cmd_format_patch, NEEDS_PREFIX },
{ "count-objects", cmd_count_objects },
{ "diff", cmd_diff, NEEDS_PREFIX },
--
1.4.2.rc3.g07ef-dirty
^ permalink raw reply related
* Re: [PATCH 2/2] builtin git-mv: support moving directories
From: Junio C Hamano @ 2006-08-08 19:52 UTC (permalink / raw)
To: Juergen Ruehle; +Cc: Johannes Schindelin, Jon Smirl, git, Josef Weidendorfer
In-Reply-To: <17624.55600.423000.61479@lapjr.intranet.kiel.bmiag.de>
Juergen Ruehle <j.ruehle@bmiag.de> writes:
> This might have been fixed already (my tree is a couple of days old),
> but the strcat fails for me, because the alloced memory is not
> cleared.
>
> Johannes Schindelin writes:
> > +static const char *add_slash(const char *path)
> > +{
> > + int len = strlen(path);
> > + if (path[len - 1] != '/') {
> > + char *with_slash = xmalloc(len + 2);
> > + memcpy(with_slash, path, len);
> > + strcat(with_slash + len, "/");
> > + return with_slash;
> > + }
> > + return path;
> > +}
>
> perhaps morph the strcat into a memcopy or append the slash and the
> NUL manually?
Thanks, well spotted. A textually minimum change would be to
do:
- memcpy(with_slash, path, len);
+ memcpy(with_slash, path, len + 1);
but that would touch the end of the string twice, so manually
terminating the string with '/' NUL would be appropriate.
I will apply a patch I've been privately using from time to time
to catch something like this to "master".
-- >8 --
[PATCH] debugging: XMALLOC_POISON
Compile with -DXMALLOC_POISON=1 to catch errors from using uninitialized
memory returned by xmalloc.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-compat-util.h | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 93f5580..3bcf5b1 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -91,6 +91,9 @@ static inline void *xmalloc(size_t size)
ret = malloc(1);
if (!ret)
die("Out of memory, malloc failed");
+#ifdef XMALLOC_POISON
+ memset(ret, 0xA5, size);
+#endif
return ret;
}
--
1.4.2.rc3.g45c5
^ permalink raw reply related
* Re: HOWTO set up a repository which can be pushed into over HTTP
From: Rutger Nijlunsing @ 2006-08-08 19:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vd5bd6ku8.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1204 bytes --]
On Mon, Aug 07, 2006 at 12:55:43AM -0700, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Do people find it useful? Or would you like to wait until I implement an
> > option in git-http-push to actually init an HTTP repo remotely?
>
> I do not have need for push over http-dav at the moment myself,
> but I would imagine I would certainly look for it when I would
> need to later.
>
> Do people find it useful? More importantly, has somebody else
> independently tried to follow the documentation and found the
> description accurate and helpful?
Today I did try to follow it, and it made an otherwise impossible job
for me doable, although still taking too much hours and a patch. The
'impossible job' for me had to do with my zero-apache experience and
(probably) a bug in WebDAV.
Find attached updated HOWTO with specific information for Debian
users, and a patch to git to git-http-push since initially WebDAV gave
me MOVE 22/404 errors.
--
Rutger Nijlunsing ---------------------------------- eludias ed dse.nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------
[-- Attachment #2: howto --]
[-- Type: text/plain, Size: 5546 bytes --]
HOWTO: Setting up a git repository which can be pushed into and pulled
from over HTTP.
What's needed:
- Have an Apache webserver
On Debian:
$ apt-get install apache2
To get apache2 by default started,
edit /etc/default/apache2 and set NO_START=0
- can edit the configuration of it
On Debian: this means being able to edit files under /etc/apache2
- can restart it.
'apachectl --graceful' might do.
On Debian:
$ /etc/init.d/apache2 restart
- have permissions to chown a directory
In effect, this probably means you're going to be root.
Step 1: setup a bare GIT repository
-----------------------------------
Create the directory (this assumes you have your Apache installed in
/usr/local/apache2):
$ cd /usr/local/apache/htdocs
$ mkdir my-new-repo.git
On Debian:
$ cd /var/www
$ mkdir my-new-repo.git
Initialize a bare repository
$ cd my-new-repo.git
$ git --bare init-db
Change the ownership to your webserver's credentials
$ chown -R www.www .
On Debian:
$ chown -R www-data.www-data .
If you do not know which user Apache runs as, you can alternatively do
a "chmod -R a+w .", inspect the files which are created later on, and
set the permissions appropriately.
Restart apache2, and check whether http://server/my-new-repo.git gives
a directory listing. If not, check whether apache started up
succesfully.
Step 2: enable DAV on this repository
-------------------------------------
In your httpd.conf, make sure that this line exists which is the file
used for locking DAV operations:
DAVLockDB "/usr/local/apache2/temp/DAV.lock"
On Debian:
Enable the dav and dav_fs modules of apache:
$ a2enmod dav_fs
$ a2enmod dav
The DAV lock is located in /etc/apache2/mods-available/dav_fs.conf:
DAVLockDB /var/lock/apache2/DAVLock
Of course, it can point somewhere else, but the string is actually just a
prefix in some Apache configurations, and therefore the _directory_ has to
be writable by the user Apache runs as.
Then, add something like this to your httpd.conf
<Location /my-new-repo.git>
DAV on
AuthType Basic
AuthName "Git"
AuthUserFile /usr/local/apache2/conf/passwd.git
Require valid-user
</Location>
On Debian:
Create (or add to) /etc/apache2/conf.d/git.conf :
<Location /my-new-repo.git>
DAV on
AuthType Basic
AuthName "Git"
AuthUserFile /etc/apache2/passwd.git
Require valid-user
</Location>
The password file can be somewhere else, but it has to be readable by
Apache and preferably not readable by the world.
Create this file by
$ htpasswd -c /usr/local/apache2/conf/passwd.git <user>
On Debian:
$ htpasswd -c /etc/apache2/passwd.git <user>
You will be asked a password, and the file is created. Subsequent calls
to htpasswd should omit the '-c' option, since you want to append to the
existing file.
You need to restart Apache.
Now go to http://<username>@<servername>/my-new-repo.git in your
browser to check whether it asks for a password and accepts the right
password.
On Debian:
To test the WebDAV part, do:
$ apt-get install litmus
$ litmus http://<servername>/my-new-repo.git <username> <password>
Mosts tests should pass.
Step 3: setup the client
------------------------
Make sure that you have HTTP support, i.e. your git was built with curl.
The easiest way to check is to look for the executable 'git-http-push'.
Then, add the following to your ~/.netrc (you can do without, but will be
asked to input your password a _lot_ of times):
machine <servername>
login <username>
password <password>
...and set permissions:
chmod 600 ~/.netrc
On Windows, use %HOMEDRIVE%%HOMEPATH%.netrc instead.
If you want to access the webserver by its IP, you have to type that in,
instead of the server name.
To check whether all is OK, do:
curl --netrc --location -v http://<username>@<servername>/my-new-repo.git/
...this should give a directory listing in HTML of /var/www/my-new-repo.git .
Now, add the remote in your existing repository which contains the project
you want to export:
$ git-repo-config remote.upload.url \
http://<username>@<servername>/my-new-repo.git/
It is important to put the last '/'; Without it, the server will send
a redirect which git-http-push does not (yet) understand, and git-http-push
will repeat the request inifinitely.
Step 4: make the initial push
-----------------------------
>From your client repository, do
$ git push upload master
This pushes branch 'master' (which is assumed to be the branch you
want to export) to repository called 'upload', which we previously
defined with git-repo-config.
Troubleshooting:
----------------
If git-http-push says
Error: no DAV locking support on remote repo http://...
then it means the webserver did not accept your authentication. Make sure
that the user name and password matches in httpd.conf, .netrc and the URL
you are uploading to.
If git-http-push shows you an error (22/502) when trying to MOVE a blob,
it means that your webserver somehow does not recognize its name in the
request; This can happen when you start Apache, but then disable the
network interface. A simple restart of Apache helps.
Errors like (22/502) are of format (curl error code/http error
code). So (22/404) means something like 'not found' at the server.
Reading /usr/local/apache2/logs/error_log is often helpful.
On Debian: Read /var/log/apache2/error.log instead.
[-- Attachment #3: commit-bd1ba73 --]
[-- Type: text/plain, Size: 980 bytes --]
commit bd1ba734176277034c6e4b33eb68fde170286538
Author: Rutger Nijlunsing <git@tux.tmfweb.nl>
Date: Tue Aug 8 14:17:38 2006 +0200
http-push: Use '_token' instead of '.token' as temporary file before renaming.
WebDAV on Debian unstable cannot handle renames on WebDAV from
file.ext to newfile (without ext) when newfile* already
exists. Normally, git creates a file like 'objects/xx/sha1.token',
which is renamed to 'objects/xx/sha1' when transferred completely.
Just use '_' instead of '.' so WebDAV doesn't see it as an extension
change.
diff --git a/http-push.c b/http-push.c
index 4021e7d..d45733e 100644
--- a/http-push.c
+++ b/http-push.c
@@ -530,7 +530,7 @@ static void start_put(struct transfer_re
request->dest = xmalloc(strlen(request->url) + 14);
sprintf(request->dest, "Destination: %s", request->url);
posn += 38;
- *(posn++) = '.';
+ *(posn++) = '_';
strcpy(posn, request->lock->token);
slot = get_active_slot();
^ permalink raw reply related
* Trouble building newer git with older
From: Nishanth Aravamudan @ 2006-08-08 18:47 UTC (permalink / raw)
To: git
Hi all,
I am in the process of updating one of our system's set of git binaries
and noticed the following. When executing
git clone rsync://rsync.kernel.org/pub/scm/git/git.git git
cd git
git checkout
make
I get this error:
kernel:/home/nacc/download/git# make
GIT_VERSION = Usage: git COMMAND [OPTIONS] [TARGET]
git command 'describe' not found: commands are:
add apply archimport bisect branch checkout cherry clone
commit count.objects cvsimport diff fetch format.patch
fsck.cache get.tar.commit.id init.db log ls.remote octopus
pack.objects parse.remote patch.id prune pull push rebase
relink rename repack request.pull reset resolve revert
send.email shortlog show.branch status tag verify.tag
whatchanged-dirty
GIT-VERSION-FILE:2: *** multiple target patterns. Stop.
This is because GIT-VERSION-GEN attempts to invoke `git describe` but
describe is not a valid parameter to the current version of git. This is
not treated as a failure case, though, as output is stored in VN.
Perhaps the return code of `git describe` should also be checked? Or am
I just not supposed to upgrade from this old of a version of git via
git?
Thanks,
Nish
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 2/2] builtin git-mv: support moving directories
From: Juergen Ruehle @ 2006-08-08 18:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jon Smirl, git, junkio, Josef Weidendorfer
In-Reply-To: <Pine.LNX.4.63.0607261941210.29667@wbgn013.biozentrum.uni-wuerzburg.de>
This might have been fixed already (my tree is a couple of days old),
but the strcat fails for me, because the alloced memory is not
cleared.
Johannes Schindelin writes:
> +static const char *add_slash(const char *path)
> +{
> + int len = strlen(path);
> + if (path[len - 1] != '/') {
> + char *with_slash = xmalloc(len + 2);
> + memcpy(with_slash, path, len);
> + strcat(with_slash + len, "/");
> + return with_slash;
> + }
> + return path;
> +}
perhaps morph the strcat into a memcopy or append the slash and the
NUL manually?
jr
^ permalink raw reply
* Re: git-show-refs (was: [PATCH/RFC] gitweb: Great subroutines renaming)
From: Jakub Narebski @ 2006-08-08 18:12 UTC (permalink / raw)
To: git
In-Reply-To: <7vejvsyum8.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> +<format>::
> + A string that interpolates `%(field name)` from the
> + object pointed at by a ref being shown. When
> + unspecified, `%(name)` is used.
Wouldn't it be better to (re)use notation of rpm's --query-format,
i.e. use %{name}, or %30{name}, or %-30{name} for single scalar values,
use :typetag output formats, like ':date' (Use strftime(3) "%c" format.) and
':day' (Use strftime(3) "%a %b %d %Y" format.) for epoch/timestamp field,
use square brackets for iterating over multivalue output, e.g.
"[parent: %{parent}]" for writing out all parents, etc.
Perhaps we could even borrow some code...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Racy git: avoid having to be always too careful
From: Junio C Hamano @ 2006-08-08 17:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.63.0608081659320.1800@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This makes "make test" dog slow. How about making this overrideable?
> (It is just a guess, but I _think_ that the sleeping is worse than having
> to check the files with the same time stamp again and again -- a "git
> status" will help that).
>
>
> -- 8< --
> [PATCH] read-cache: optionally disable being cautious with racy caches
>
> By setting the environment variable GIT_RISK_RACY_CACHE or the config
> variable core.riskRacyCache, the sleeping (to avoid a racy cache) is
> disabled.
"RISK" is a misnomer here -- the original code without patch is
being cautious and taking a runtime hit but not risky. The
"delay while writing the cache out for the first time" is trying
to avoid the runtime hit by taking a hit at cache generation
time. In either case you never risk racy cache.
Perhaps throwing away the whole "delay" thing might be simpler
and more worthwhile.
Another possibility is to tweak the heuristics -- currently we
say 20 paths or 1/4 of whole paths is too many and would cause
too much runtime hit but that was done without any measurement.
We could raise the threashold which would solve the case for the
testsuite whose trees are all small.
^ permalink raw reply
* [PATCH 5/4] autoconf: Mention "make configure" instead of "autoconf" in INSTALL
From: Jakub Narebski @ 2006-08-08 16:48 UTC (permalink / raw)
To: git
In-Reply-To: <200608081835.23448.jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Should be part of [PATCH 1/4] in this series (replied-to patch)
INSTALL | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/INSTALL b/INSTALL
index f8dfa19..0d432d7 100644
--- a/INSTALL
+++ b/INSTALL
@@ -16,7 +16,7 @@ install" would not work.
Alternatively you can use autoconf generated ./configure script to
set up install paths (via config.mak.autogen), so you can write instead
- $ autoconf ;# as yourself if ./configure doesn't exist yet
+ $ make configure ;# as yourself
$ ./configure --prefix=/usr ;# as yourself
$ make all doc ;# as yourself
# make install install-doc ;# as root
--
1.4.1.1
^ permalink raw reply related
* [PATCH 4/4] autoconf: Move variables which we always set to config.mak.in
From: Jakub Narebski @ 2006-08-08 16:39 UTC (permalink / raw)
To: git
In-Reply-To: <200608081834.09271.jnareb@gmail.com>
Move detected NO_STH and NEED_STH variables, which we always output,
either setting or unsetting (setting to empty string) to config.mak.in
and use setting appropriately named variables and doing AC_SUBST
instead of adding them via GIT_CONF_APPEND_LINE macro and
config.mak.append temporary file.
Variables which might and might not be set are still added via
config.mak.append; this include all STH_PATH variables.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This makes our configure.ac more typical.
config.mak.in | 15 +++++++++++
configure.ac | 75 +++++++++++++++++++++++++++++++++------------------------
2 files changed, 59 insertions(+), 31 deletions(-)
diff --git a/config.mak.in b/config.mak.in
index 04f508a..99b13a7 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -22,3 +22,18 @@ VPATH = @srcdir@
export exec_prefix mandir
export srcdir VPATH
+NO_PYTHON=@NO_PYTHON@
+NEEDS_SSL_WITH_CRYPTO=@NEEDS_SSL_WITH_CRYPTO@
+NO_CURL=@NO_CURL@
+NO_EXPAT=@NO_EXPAT@
+NEEDS_LIBICONV=@NEEDS_LIBICONV@
+NEEDS_SOCKET=@NEEDS_SOCKET@
+NO_D_INO_IN_DIRENT=@NO_D_INO_IN_DIRENT@
+NO_D_TYPE_IN_DIRENT=@NO_D_TYPE_IN_DIRENT@
+NO_SOCKADDR_STORAGE=@NO_SOCKADDR_STORAGE@
+NO_IPV6=@NO_IPV6@
+NO_C99_FORMAT=@NO_C99_FORMAT@
+NO_STRCASESTR=@NO_STRCASESTR@
+NO_STRLCPY=@NO_STRLCPY@
+NO_SETENV=@NO_SETENV@
+
diff --git a/configure.ac b/configure.ac
index c27a994..bc2824b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -149,7 +149,6 @@ if test -z "$NO_PYTHON"; then
NO_PYTHON=""
fi
fi
-GIT_CONF_APPEND_LINE([NO_PYTHON=@NO_PYTHON@])
## Checks for libraries.
@@ -158,35 +157,41 @@ #
# 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([crypto], [SHA1_Init],
-[GIT_CONF_APPEND_LINE(NEEDS_SSL_WITH_CRYPTO=)],
+[NEEDS_SSL_WITH_CRYPTO=],
[AC_CHECK_LIB([ssl], [SHA1_Init],
- [GIT_CONF_APPEND_LINE(NEEDS_SSL_WITH_CRYPTO=YesPlease)
- GIT_CONF_APPEND_LINE(NEEDS_SSL_WITH_CRYPTO=)],
- [GIT_CONF_APPEND_LINE(NO_OPENSSL=YesPlease)])])
+ [NEEDS_SSL_WITH_CRYPTO=YesPlease
+ NEEDS_SSL_WITH_CRYPTO=],
+ [NO_OPENSSL=YesPlease])])
+AC_SUBST(NEEDS_SSL_WITH_CRYPTO)
+AC_SUBST(NO_OPENSSL)
#
# 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=)],
-[GIT_CONF_APPEND_LINE(NO_CURL=YesPlease)])
+[NO_CURL=],
+[NO_CURL=YesPlease])
+AC_SUBST(NO_CURL)
#
# 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=)],
-[GIT_CONF_APPEND_LINE(NO_EXPAT=YesPlease)])
+[NO_EXPAT=],
+[NO_EXPAT=YesPlease])
+AC_SUBST(NO_EXPAT)
#
# Define NEEDS_LIBICONV if linking with libc is not enough (Darwin).
AC_CHECK_LIB([c], [iconv],
-[GIT_CONF_APPEND_LINE(NEEDS_LIBICONV=)],
-[GIT_CONF_APPEND_LINE(NEEDS_LIBICONV=YesPlease)])
+[NEEDS_LIBICONV=],
+[NEEDS_LIBICONV=YesPlease])
+AC_SUBST(NEEDS_LIBICONV)
#
# Define NEEDS_SOCKET if linking with libc is not enough (SunOS,
# Patrick Mauritz).
AC_CHECK_LIB([c], [socket],
-[GIT_CONF_APPEND_LINE(NEEDS_SOCKET=)],
-[GIT_CONF_APPEND_LINE(NEEDS_SOCKET=YesPlease)])
+[NEEDS_SOCKET=],
+[NEEDS_SOCKET=YesPlease])
+AC_SUBST(NEEDS_SOCKET)
## Checks for header files.
@@ -197,33 +202,38 @@ AC_MSG_NOTICE([CHECKS for typedefs, stru
#
# 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=)],
-[GIT_CONF_APPEND_LINE(NO_D_INO_IN_DIRENT=YesPlease)],
+[NO_D_INO_IN_DIRENT=],
+[NO_D_INO_IN_DIRENT=YesPlease],
[#include <dirent.h>])
+AC_SUBST(NO_D_INO_IN_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).
AC_CHECK_MEMBER(struct dirent.d_type,
-[GIT_CONF_APPEND_LINE(NO_D_TYPE_IN_DIRENT=)],
-[GIT_CONF_APPEND_LINE(NO_D_TYPE_IN_DIRENT=YesPlease)],
+[NO_D_TYPE_IN_DIRENT=],
+[NO_D_TYPE_IN_DIRENT=YesPlease],
[#include <dirent.h>])
+AC_SUBST(NO_D_TYPE_IN_DIRENT)
#
# 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=)],
-[GIT_CONF_APPEND_LINE(NO_SOCKADDR_STORAGE=YesPlease)],
+[NO_SOCKADDR_STORAGE=],
+[NO_SOCKADDR_STORAGE=YesPlease],
[#include <netinet/in.h>])
+AC_SUBST(NO_SOCKADDR_STORAGE)
+#
# Define NO_IPV6 if you lack IPv6 support and getaddrinfo().
AC_CHECK_TYPE([struct addrinfo],[
AC_CHECK_FUNC([getaddrinfo],
- [GIT_CONF_APPEND_LINE(NO_IPV6=)],
- [GIT_CONF_APPEND_LINE(NO_IPV6=YesPlease)])
-],[GIT_CONF_APPEND_LINE(NO_IPV6=YesPlease)],[
+ [NO_IPV6=],
+ [NO_IPV6=YesPlease])
+],[NO_IPV6=YesPlease],[
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>
])
+AC_SUBST(NO_IPV6)
#
# Define NO_C99_FORMAT if your formatted IO functions (printf/scanf et.al.)
# do not support the 'size specifiers' introduced by C99, namely ll, hh,
@@ -243,11 +253,11 @@ AC_RUN_IFELSE(
[ac_cv_c_c99_format=no])
])
if test $ac_cv_c_c99_format = no; then
- GIT_CONF_APPEND_LINE(NO_C99_FORMAT=YesPlease)
+ NO_C99_FORMAT=YesPlease
else
- GIT_CONF_APPEND_LINE(NO_C99_FORMAT=)
+ NO_C99_FORMAT=
fi
-
+AC_SUBST(NO_C99_FORMAT)
## Checks for library functions.
## (in default C library and libraries checked by AC_CHECK_LIB)
@@ -255,18 +265,21 @@ AC_MSG_NOTICE([CHECKS for library functi
#
# Define NO_STRCASESTR if you don't have strcasestr.
AC_CHECK_FUNC(strcasestr,
-[GIT_CONF_APPEND_LINE(NO_STRCASESTR=)],
-[GIT_CONF_APPEND_LINE(NO_STRCASESTR=YesPlease)])
+[NO_STRCASESTR=],
+[NO_STRCASESTR=YesPlease])
+AC_SUBST(NO_STRCASESTR)
#
# Define NO_STRLCPY if you don't have strlcpy.
AC_CHECK_FUNC(strlcpy,
-[GIT_CONF_APPEND_LINE(NO_STRLCPY=)],
-[GIT_CONF_APPEND_LINE(NO_STRLCPY=YesPlease)])
+[NO_STRLCPY=],
+[NO_STRLCPY=YesPlease])
+AC_SUBST(NO_STRLCPY)
#
# Define NO_SETENV if you don't have setenv in the C library.
AC_CHECK_FUNC(setenv,
-[GIT_CONF_APPEND_LINE(NO_SETENV=)],
-[GIT_CONF_APPEND_LINE(NO_SETENV=YesPlease)])
+[NO_SETENV=],
+[NO_SETENV=YesPlease])
+AC_SUBST(NO_SETENV)
#
# Define NO_MMAP if you want to avoid mmap.
#
--
1.4.1.1
^ permalink raw reply related
* [PATCH 3/4] autoconf: Improvements in NO_PYTHON/PYTHON_PATH handling
From: Jakub Narebski @ 2006-08-08 16:38 UTC (permalink / raw)
To: git
In-Reply-To: <200608081834.09271.jnareb@gmail.com>
Unset NO_PYTHON for --with-python without arguments, and when
PYTHON_PATH is set. Do not check for PYTHON_PATH if it is set
via --with-python=PYTHON_PATH. Prefer python to python2.4 etc.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
What might be unexpected is the fact that even for --with-python
(but only without setting PYTHON_PATH) autodetection might set NO_PYTHON
configure.ac | 15 +++++++++------
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/configure.ac b/configure.ac
index c2ddd9b..c27a994 100644
--- a/configure.ac
+++ b/configure.ac
@@ -105,7 +105,10 @@ AC_ARG_WITH(python,[AS_HELP_STRING([--wi
AS_HELP_STRING([--no-python], [don't use python scripts])],
[if test "$withval" = "no"; then \
NO_PYTHON=YesPlease; \
- elif test "$withval" != "yes"; then \
+ elif test "$withval" = "yes"; then \
+ NO_PYTHON=; \
+ else \
+ NO_PYTHON=; \
PYTHON_PATH=$withval; \
fi; \
])
@@ -138,15 +141,15 @@ #
# Define NO_PYTHON if you want to lose all benefits of the recursive merge.
# Define PYTHON_PATH to provide path to Python.
if test -z "$NO_PYTHON"; then
- AC_PATH_PROGS(PYTHON_PATH, [python2.4 python2.3 python2 python])
+ if test -z "$PYTHON_PATH"; then
+ AC_PATH_PROGS(PYTHON_PATH, [python python2.4 python2.3 python2])
+ fi
if test -n "$PYTHON_PATH"; then
GIT_CONF_APPEND_LINE([PYTHON_PATH=@PYTHON_PATH@])
- else
- GIT_CONF_APPEND_LINE([NO_PYTHON=@NO_PYTHON@])
+ NO_PYTHON=""
fi
-else
- GIT_CONF_APPEND_LINE([NO_PYTHON=@NO_PYTHON@])
fi
+GIT_CONF_APPEND_LINE([NO_PYTHON=@NO_PYTHON@])
## Checks for libraries.
--
1.4.1.1
^ 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