* Re: [PATCH 3/3] git --help COMMAND brings up the git-COMMAND man-page., take two
From: H. Peter Anvin @ 2005-11-16 3:45 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <20051116002318.A46C55BF97@nox.op5.se>
Andreas Ericsson wrote:
>
> +static void show_man_page(char *git_cmd)
> +{
> + char *page;
> +
> + if (!strncmp(git_cmd, "git", 3))
> + page = git_cmd;
> + else {
> + int page_len = strlen(git_cmd) + 4;
> +
> + page = malloc(page_len + 1);
> + strcpy(page, "git-");
> + strcpy(page + 4, git_cmd);
> + page[page_len] = 0;
> + }
> +
> + execlp("man", "man", page, NULL);
> +}
> +
The way this made it into the actual tree was to call /usr/bin/man, but
still using execlp(). This is clearly bogus. There *ARE* good reasons
to use PATH resolutions for this, since man is one of the interactive
commands the user may want to wrapper.
So please drop PATH_TO_MAN that made it into the repository and revert
to the original patch.
-hpa
^ permalink raw reply
* Re: latest stg/git commandline completions code
From: Ben Clifford @ 2005-11-16 3:35 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List, Blaisorblade, Nikolai Weibull
In-Reply-To: <20051110094013.GM30496@pasky.or.cz>
>> There are a few small common functions that are used by all the git
>> completions, though.
> Then could you please separate those from the git completion to some
> kind of 'library'?
that's done now.
> When you do
>
> cat > <tab><tab>
>
> bash happily autocompletes as well. I don't think this is a problem,
> besides it can be useful when you want to use some existing branch
> name,
> just slightly modified.
ok, convinced - I changed 'branch' and 'checkout' to complete on new
branch name.
http://www.hawaga.org.uk/gitcompletion/git-compl-lib
http://www.hawaga.org.uk/gitcompletion/cg-compl
are the two latest versions of the code (source the -lib then the cg-
file)
There is no autogeneration - I'm still playing round. Its just good-
old-fashioned manually hard coded.
The git repo that I'm keeping this and the other completion code
(stg, git and gitk) in is at http://www.hawaga.org.uk/gitcompletion.git
--
Ben ベン Бэн
http://www.hawaga.org.uk/ben/
My email is high latency but best way to contact me. Alternatively,
SMS number(s) at above URL.
^ permalink raw reply
* Re: pushing patches to an imap folder
From: Mike McCormack @ 2005-11-16 3:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Langhoff
In-Reply-To: <7vek5hcmh4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Hmph. Kinda surprised. You guys do not do icons?
We do, but we have a tool called bin2res that converts them to text and
stores them in a comment in the .rc file that they're associated with:
http://cvs.winehq.org/cvsweb/~checkout~/wine/dlls/shell32/shres.rc?rev=1.42&content-type=text/plain
This was done because of trouble with binary files in CVS.
^ permalink raw reply
* [PATCH] Add missing '--summary' to cg-log usage.
From: Ben Clifford @ 2005-11-16 3:13 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 826 bytes --]
Cannot get my mailer (Apple Mail on OS X) to insert this pretty
trivial patch in a nice way -- included it as an attachment as well.
----- cut ------
Add missing '--summary' to cg-log usage.
Signed-off-by: Ben Clifford
---
cg-log | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cg-log b/cg-log
index 710ce7b..49c3cc0 100755
--- a/cg-log
+++ b/cg-log
@@ -98,7 +98,7 @@
# things more comfortable to SVN users). See cogito(7) for more details
# about revision specification.
-USAGE="cg-log [-c] [-f] [-m] [-M] [-s] [-uUSERNAME] [-d DATE] [-r
FROM_ID[..TO_ID]] FILE..."
+USAGE="cg-log [-c] [-f] [-m] [-M] [-s] [-uUSERNAME] [-d DATE] [-r
FROM_ID[..TO_ID]] [--summary] FILE..."
. ${COGITO_LIB}cg-Xlib || exit 1
# Try to fix the annoying "Broken pipe" output. May not help, but
apparently
[-- Attachment #2: cogito-log-summary.patch --]
[-- Type: application/octet-stream, Size: 966 bytes --]
Add missing '--summary' to cg-log usage.
Signed-off-by: Ben Clifford
---
commit a21b69e87d13a210df78a7eb952ed400109c0438
tree 0ab82b9a97ffaa71e0342e3aa153196ef8e0ac77
parent c51a232e8115ade2f5d61f4ea9dd1246bd7f7db0
author Ben Clifford <benc@hawaga.org.uk> Wed, 16 Nov 2005 09:29:57 +1000
committer Ben Clifford <benc@piva.hawaga.org.uk> Wed, 16 Nov 2005 09:29:57 +1000
cg-log | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cg-log b/cg-log
index 710ce7b..49c3cc0 100755
--- a/cg-log
+++ b/cg-log
@@ -98,7 +98,7 @@
# things more comfortable to SVN users). See cogito(7) for more details
# about revision specification.
-USAGE="cg-log [-c] [-f] [-m] [-M] [-s] [-uUSERNAME] [-d DATE] [-r FROM_ID[..TO_ID]] FILE..."
+USAGE="cg-log [-c] [-f] [-m] [-M] [-s] [-uUSERNAME] [-d DATE] [-r FROM_ID[..TO_ID]] [--summary] FILE..."
. ${COGITO_LIB}cg-Xlib || exit 1
# Try to fix the annoying "Broken pipe" output. May not help, but apparently
[-- Attachment #3: Type: text/plain, Size: 2 bytes --]
^ permalink raw reply related
* Re: pushing patches to an imap folder
From: Junio C Hamano @ 2005-11-16 3:15 UTC (permalink / raw)
To: Mike McCormack; +Cc: git, Martin Langhoff
In-Reply-To: <437A9109.6010101@codeweavers.com>
Mike McCormack <mike@codeweavers.com> writes:
> No, there's no binary files in the Wine CVS (or symlinks ;).
Hmph. Kinda surprised. You guys do not do icons?
^ permalink raw reply
* Re: [PATCH] Disable USE_SYMLINK_HEAD by default
From: Junio C Hamano @ 2005-11-16 3:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Petr Baudis, Pavel Roskin, git
In-Reply-To: <1132106171.18941.2.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
>> I am in favor of that. Something like this, perhaps:
>>
>> core.filemode = 1 # trustworthy
>> core.usesymlink = 0 # new style
>
> Thanks for implemented this.
Thank from me, too, Johannes.
^ permalink raw reply
* Re: [PATCH] Add option USE_INPLACE to Makefile
From: Junio C Hamano @ 2005-11-16 3:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511160333460.15130@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> and you no longer need to worry about setting variables like
> GIT_EXEC_PATH and GIT_PYTHON_PATH.
I think you can already do this in the config.mak mechanism
added by, ... (goes and asks git-whatchanged about it),...
*you*, no?
You know you are not installing things anyway if you do that, so
I do not see much point hiding the install target and friends
either.
^ permalink raw reply
* Re: [PATCH] Give python a chance to find "backported" modules
From: Junio C Hamano @ 2005-11-16 3:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0511160331150.15130@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> python 2.2.1 is perfectly capable of executing git-merge-recursive,
> provided that it finds heapq and sets. All you have to do is to steal
> heapq.py and sets.py from python 2.3 or newer, and drop them in your
> GIT_PYTHON_PATH.
Fair enough. But I do not think we would want to go further
than this. Especially, shipping a copy of heapq and sets like
we did for subprocess.
Thanks anyway.
^ permalink raw reply
* Re: [PATCH] Fix tests with new git in C
From: Junio C Hamano @ 2005-11-16 3:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0511160244240.14176@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> GIT_EXEC_PATH *has* to be set.
Thanks.
^ permalink raw reply
* Re: [PATCH] Fix compilation of git.c
From: Junio C Hamano @ 2005-11-16 3:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0511160243360.14176@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Some systems do not define GLOB_ABORTED and GLOB_NOMATCH.
That's true, but the glob does not distinguish executables and
others anyway, do wouldn't it be more portable and easier to do
readdir, stat and list in the loop?
^ permalink raw reply
* [PATCH] Add option USE_INPLACE to Makefile
From: Johannes Schindelin @ 2005-11-16 2:35 UTC (permalink / raw)
To: git, junkio
If you plan on adding your current working directory to your PATH, you
can do
USE_INPLACE=1 make
and you no longer need to worry about setting variables like
GIT_EXEC_PATH and GIT_PYTHON_PATH.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Makefile | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
applies-to: 66be81f4755380a7c9da56aa5fbc600565ff78a8
07f60591a5e881b2a46885ac9b6ba61a4931ac86
diff --git a/Makefile b/Makefile
index 55f4c6b..63c524d 100644
--- a/Makefile
+++ b/Makefile
@@ -50,6 +50,9 @@
# 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.
+# Define USE_INPLACE if you do not plan to install git anywhere, but rather
+# want to add the working directory to your PATH.
+
GIT_VERSION = 0.99.9.GIT
# CFLAGS and LDFLAGS are for the users to override from the command line.
@@ -60,10 +63,16 @@ ALL_CFLAGS = $(CFLAGS)
ALL_LDFLAGS = $(LDFLAGS)
prefix = $(HOME)
+ifdef USE_INPLACE
+bindir = `pwd`
+template_dir = `pwd`/templates
+GIT_PYTHON_DIR = `pwd`/compat
+else
bindir = $(prefix)/bin
template_dir = $(prefix)/share/git-core/templates/
GIT_PYTHON_DIR = $(prefix)/share/git-core/python
# DESTDIR=
+endif
CC = gcc
AR = ar
@@ -432,6 +441,8 @@ check:
### Installation rules
+ifndef USE_INPLACE
+
install: $(PROGRAMS) $(SCRIPTS) git
$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(bindir))
$(INSTALL) git $(PROGRAMS) $(SCRIPTS) $(call shellquote,$(DESTDIR)$(bindir))
@@ -468,6 +479,8 @@ deb: dist
dpkg-source -b $(GIT_TARNAME)
cd $(GIT_TARNAME) && fakeroot debian/rules binary
+endif
+
### Cleaning rules
clean:
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH] Give python a chance to find "backported" modules
From: Johannes Schindelin @ 2005-11-16 2:33 UTC (permalink / raw)
To: git, junkio
python 2.2.1 is perfectly capable of executing git-merge-recursive,
provided that it finds heapq and sets. All you have to do is to steal
heapq.py and sets.py from python 2.3 or newer, and drop them in your
GIT_PYTHON_PATH.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
I noted that the python modules are installed uncompiled,
i.e. *.py but not *.pyc. Is this intended?
git-merge-recursive.py | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
applies-to: 2a67ad9e41fc614c7848ceff43f4b60b99cf932d
dfd75a554e84139ddce7b62ec82ef94254da1573
diff --git a/git-merge-recursive.py b/git-merge-recursive.py
index 1bf73f3..d7d36aa 100755
--- a/git-merge-recursive.py
+++ b/git-merge-recursive.py
@@ -3,11 +3,13 @@
# Copyright (C) 2005 Fredrik Kuivinen
#
-import sys, math, random, os, re, signal, tempfile, stat, errno, traceback
+import sys
+sys.path.append('''@@GIT_PYTHON_PATH@@''')
+
+import math, random, os, re, signal, tempfile, stat, errno, traceback
from heapq import heappush, heappop
from sets import Set
-sys.path.append('''@@GIT_PYTHON_PATH@@''')
from gitMergeCommon import *
outputIndent = 0
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH 1/3] C implementation of the 'git' program, take two.
From: Johannes Schindelin @ 2005-11-16 2:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andreas Ericsson, git
In-Reply-To: <Pine.LNX.4.64.0511151751520.13959@g5.osdl.org>
Hi,
On Tue, 15 Nov 2005, Linus Torvalds wrote:
> Then, you just prepend it to the PATH, with a : in between (and if the
> pathname has a ":" in it, tough, there's nothing we can do about it).
You mean like "c:/cygwin/git"? Yes, I know, the default is
"/cygdrive/c/cygwin/git", but there are people out there with ":" in their
pathname.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/3] C implementation of the 'git' program, take two.
From: Linus Torvalds @ 2005-11-16 2:02 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <437A8067.9050308@op5.se>
On Wed, 16 Nov 2005, Andreas Ericsson wrote:
>
> It was your idea to begin with, actually, in the thread on how to do proper
> path validation in the git-daemon. :)
But that was because the important part wasn't to get an absolute path,
but because the important part was to get the _canonical_ path.
That was for security.
Besides, I don't think we ever switched back. We just did a chdir() + a
getcwd().
> > Why don't you just do
> >
> > if (exec_path[0] != '/') {
> > .. prepend "cwd/" to exec_path ..
> >
>
> You mean
> setenv("PATH", concat3(cwd, exec_path, old_path), 1);
No.
I mean exactly what I said.
I mean testing whether the exec_path[] is already absolute, and not
touching it at all if it is.
It's really as simple as something like
const char *absolute_path(const char *input)
{
int a, b;
char *buf;
char cwd[PATH_MAX];
if (*input == '/')
return input;
if (!getcwd(cwd, sizeof(cwd))
return NULL;
/* Do some trivial cleanup */
while (!strncmp(input, "./", 2)) {
input += 2;
while (*input == '/')
input++;
}
a = strlen(cwd);
b = strlen(input);
buf = malloc(a + b + 2);
if (!buf)
return NULL;
memcpy(buf, cwd, a);
buf[a] = '/';
memcpy(buf + a + 1, input, b);
buf[a + 1 + b] = 0;
return buf;
}
and there it is.
The magic rule being:
- if the path is already absolute, it's _good_. Don't play games with it.
- just append the dang thing with cwd. Don't play games (the above does
trivial simplification, which is unnecessary, but it's so simple that
hey, who cares? And it makes one common case a bit prettier)
Then, you just prepend it to the PATH, with a : in between (and if the
pathname has a ":" in it, tough, there's nothing we can do about it).
Linus
^ permalink raw reply
* Re: [PATCH] Disable USE_SYMLINK_HEAD by default
From: Pavel Roskin @ 2005-11-16 1:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Johannes Schindelin, git
In-Reply-To: <7vy83plqlr.fsf@assigned-by-dhcp.cox.net>
On Tue, 2005-11-15 at 10:21 -0800, Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:
> The voice of reason comes from Pasky; I agree with this.
OK, let's prepare for post-1.0 switchover then.
> I am in favor of that. Something like this, perhaps:
>
> core.filemode = 1 # trustworthy
> core.usesymlink = 0 # new style
Thanks for implemented this.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: pushing patches to an imap folder
From: Mike McCormack @ 2005-11-16 1:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Langhoff
In-Reply-To: <7vzmo5ka20.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Wow. How is the acceptance by wine community? Favorable, I
> hope.
wine.git hasn't been announced on any of the wine mailing lists yet. As
long as we don't get rid of CVS entirely, I don't think there'll be too
many complaints. Hopefully when it's announced, we'll have a few GIT
users who can tell people why it's good to use.
> git-cvsexportcommit? I haven't had a chance to use it myself,
> although I have to interoperate with CVS in some projects.
> Martin, do you want to do a plug (or brag) here?
git-cvsexportcommit looks nice. I guess Alexandre is using something
like that now. I was thinking more ambitiously... something like a
git-cvsd. That would be a pretty awesome migration tool :)
> It is handy, especially for simple things like rebasing topic
> branches, when the things are of managable size without using
> quilt or StGIT. Do you manage binary files?
No, there's no binary files in the Wine CVS (or symlinks ;).
> Yes, I saw that value there. Maybe adding hooks to format-patch
> so that it can do form-letter-ish things you had to add there
> without patching might help? I dunno.
I'll have a go at integrating my code with format-patch. Hooks for a
template would be helpful.
Mike
^ permalink raw reply
* [PATCH] Fix tests with new git in C
From: Johannes Schindelin @ 2005-11-16 1:44 UTC (permalink / raw)
To: git, junkio
GIT_EXEC_PATH *has* to be set.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
t/test-lib.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
applies-to: 923eb95f309cc9765505d187ce03881a555e75f6
ab9cab703171b1ccfe1bee5c3b210ca7369a0476
diff --git a/t/test-lib.sh b/t/test-lib.sh
index a8f239d..e654155 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -158,6 +158,8 @@ test_done () {
# Test the binaries we have just built. The tests are kept in
# t/ subdirectory and are run in trash subdirectory.
PATH=$(pwd)/..:$PATH
+GIT_EXEC_PATH=$(pwd)/..
+export GIT_EXEC_PATH
# Test repository
test=trash
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH] Fix compilation of git.c
From: Johannes Schindelin @ 2005-11-16 1:44 UTC (permalink / raw)
To: git, junkio
Some systems do not define GLOB_ABORTED and GLOB_NOMATCH.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
applies-to: c20dc1194fcfa73a7bf6e9d315c878d4f8c2828a
57cce66195a824221c0e9517ff4999daf2fbe2d2
diff --git a/git.c b/git.c
index 583923d..30b3c04 100644
--- a/git.c
+++ b/git.c
@@ -77,13 +77,17 @@ static void list_commands(const char *ex
case GLOB_NOSPACE:
puts("Out of memory when running glob()");
exit(2);
+#ifdef GLOB_ABORTED
case GLOB_ABORTED:
printf("'%s': Read error: %s\n", exec_path, strerror(errno));
exit(2);
+#endif
+#ifdef GLOB_NOMATCH
case GLOB_NOMATCH:
printf("No git commands available in '%s'.\n", exec_path);
printf("Do you need to specify --exec-path or set GIT_EXEC_PATH?\n");
exit(1);
+#endif
}
for (i = 0; i < gl.gl_pathc; i++) {
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] Small script to patch .spec for Suse
From: Josef Weidendorfer @ 2005-11-16 1:32 UTC (permalink / raw)
To: git
In-Reply-To: <437A5FAF.2000609@zytor.com>
On Tuesday 15 November 2005 23:22, H. Peter Anvin wrote:
> Sure. It's called %if. There is also %ifdef and %define.
So by replacing @@FOR_SUSE@@ to 0 or 1 in the Makefile, this:
%if @@FOR_SUSE@@
BuildRequires: openssh ...
%else
BuildRequires: openssh-clients ...
%endif
would work?
Josef
^ permalink raw reply
* Re: [PATCH 0/3] Support setting SymrefsOnly=true from scripts
From: Junio C Hamano @ 2005-11-16 1:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511160127130.4334@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 15 Nov 2005, Junio C Hamano wrote:
>
>> I am almost tempted to say that we should be doing --template=
>> option to git-init-db for something like this, and make the
>> template instantiation first thing before even reading the
>> config file.
>
> Well, problem is that if you use templates to install a .git/config, the
> code in init-db which checks for safe filemode no longer gets called. And
> we don't know yet what else we might want to write into the config from
> init-db, or from anywhere else for that matter.
>
> Furthermore: if you have a nice template which says that SymrefsOnly=true,
> init-db will still create HEAD as a symlink!
Funny. These two are what I meant by "make the template
instantiation first thing". So instead of the hardcoded
only_symbolic_ref assignment and filemode check code, can't we
do something like this?
- copy the template; if the commandline specifies where the
templates are, take them from there otherwise use the
built-in location.
- read from config; note if you actually read any (may not have
config in your template suite, or you might not have
templates at all).
- do filemode check, and maybe git_config_set() there and write
the result back as the new config for that repository.
- create the rest, including the HEAD ref.
The user could even have more than one template set (one for
VFAT and another for non VFAT). Once we go that route, we may
not even need the special filemode check code in init-db. No?
^ permalink raw reply
* Re: [PATCH] Disable USE_SYMLINK_HEAD by default
From: Josef Weidendorfer @ 2005-11-16 1:05 UTC (permalink / raw)
To: git
In-Reply-To: <20051115121854.GV30496@pasky.or.cz>
On Tuesday 15 November 2005 13:18, Petr Baudis wrote:
> being the canonical format in the next major release after 1.0, giving
Talking about versions...
Do we have an easy way to detect the format version of a git repository?
If not, I suggest git-init-db to add something like
echo "1" > .git/version
and let all the git-tools which read/write any files in .git themself
test against version 1. Or is this overkill?
Josef
^ permalink raw reply
* Re: [PATCH 0/3] Support setting SymrefsOnly=true from scripts
From: Johannes Schindelin @ 2005-11-16 0:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfypxh5mn.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 15 Nov 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > - set SymrefsOnly=true right from the start with
> > git-init-db --dont-use-symrefs
>
> I am almost tempted to say that we should be doing --template=
> option to git-init-db for something like this, and make the
> template instantiation first thing before even reading the
> config file.
Well, problem is that if you use templates to install a .git/config, the
code in init-db which checks for safe filemode no longer gets called. And
we don't know yet what else we might want to write into the config from
init-db, or from anywhere else for that matter.
Furthermore: if you have a nice template which says that SymrefsOnly=true,
init-db will still create HEAD as a symlink! (Note that my patch sets
the *global* only_use_symrefs from the command line option, not a
local variable!)
So, if you want a repository to explicitely force symrefs, you have to
have special handling in init-db. And for consistency, you should
modify/write the config file to include "SymrefsOnly=true" right away.
Alternatively, or in addition to my patch, you could do a git_config()
just after copy_templates() (you allude to this, but note that init-db
does not read the config at any stage yet).
However! This only works if you are sure that the templates you need are
installed. I *never* install git, but *always* have my private working
directory in the PATH. So, I never have templates installed. Neither do I
plan to.
> The rest might be useful to better support end-users, but I am
> not sure. Is it that much hassle to them to edit an .ini file?
Obviously, I'd prefer to have at least the patch adding git_config_set()
applied. This is core plumbing. It actually checks if the name is valid,
and it automatically escapes the value when needed. Before doing anything,
it checks that the config file is valid. It does locking. It creates a
simple config if none was there yet. And it's small.
As for git-config-set, I guess it would be rather handy for Porcelains
(and t/blabla-config.sh), but I could be convinced otherwise.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/3] C implementation of the 'git' program, take two.
From: Andreas Ericsson @ 2005-11-16 0:42 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0511151603510.11232@g5.osdl.org>
Linus Torvalds wrote:
>
> On Wed, 16 Nov 2005, Andreas Ericsson wrote:
>
>>+
>>+ /* allow relative paths, but run with exact */
>>+ if (chdir(exec_path)) {
>>+ printf("git: '%s': %s\n", exec_path, strerror(errno));
>>+ exit (1);
>>+ }
>>+
>>+ getcwd(git_command, sizeof(git_command));
>>+ chdir(wd);
>
>
> Argh. This is pretty horrible way to turn a path into an absolute one.
It was your idea to begin with, actually, in the thread on how to do
proper path validation in the git-daemon. :)
>
> Why don't you just do
>
> if (exec_path[0] != '/') {
> .. prepend "cwd/" to exec_path ..
>
You mean
setenv("PATH", concat3(cwd, exec_path, old_path), 1);
?
Because that can fail too. Every solution is bad if you twist and turn
it enough.
>
> The reason to avoid "chdir(relative) + chdir(back)" is that it totally
> unnecessarily breaks under some extreme cases. For example, if the
> exec_path is already absolute, and we just happen to be in a really deep
> subdirectory, then the getcwd() could have failed due to the PATH_MAX
> limitations.
>
True. So, would something like
char *try_goddamn_hard_to_get_working_dir(char *rel_path)
{
size_t plen = PATH_MAX;
char *p = malloc(PATH_MAX);
while(p && plen < 1 << 20 && !(p = getcwd(p, plen))) {
plen += PATH_MAX;
p = realloc(p, plen);
}
return p;
}
be considered safe from this particular point of view?
> Also, depending on getcwd() will not work if any parent directory is
> unreadable or non-executable (well, under Linux it will, as long as it's
> executable, since getcwd() is actually a system call. Not in UNIX in
> general, though). Again, that means that unless you _have_ to know what
> the cwd is, you should try to avoid relying on it.
>
True. I'll redo that part (tomorrow).
>
> and the nicer thign to do is to just not try to be clever.
>
I never try. It just comes to me naturally. ;)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 3/3] git --help COMMAND brings up the git-COMMAND man-page.
From: Andreas Ericsson @ 2005-11-16 0:24 UTC (permalink / raw)
To: git
In-Reply-To: <7vsltxeakh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>>+
>>+ execlp(PATH_TO_MAN, "man", page, NULL);
>>+}
>
>
> If you do PATH_TO_MAN absolute, execl would suffice, but just
> saying "man" and have execlp look for it would be easier to
> manage.
>
>
Never even occurred to me, actually. I just re-submitted the patch.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH 3/3] git --help COMMAND brings up the git-COMMAND man-page., take two
From: Andreas Ericsson @ 2005-11-16 0:23 UTC (permalink / raw)
To: git
It's by design a bit stupid (matching ^git rather than ^git-), so as
to work with 'gitk' and 'git' as well.
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
Documentation/git.txt | 2 ++
git.c | 26 ++++++++++++++++++++++++--
2 files changed, 26 insertions(+), 2 deletions(-)
applies-to: 8a47ae8a825ab0e68ac46392bccd1ec16df39456
53e2024f89514d31a45936e3596e3d285dfd1bfe
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 91e9f9f..7cbfaf8 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -24,6 +24,8 @@ OPTIONS
--help::
prints the synopsis and a list of available commands.
+ If a git command is named this option will bring up the
+ man-page for that command.
--exec-path::
path to wherever your core git programs are installed.
diff --git a/git.c b/git.c
index d189801..4b7cbf6 100644
--- a/git.c
+++ b/git.c
@@ -160,6 +160,24 @@ static void prepend_to_path(const char *
setenv("PATH", path, 1);
}
+static void show_man_page(char *git_cmd)
+{
+ char *page;
+
+ if (!strncmp(git_cmd, "git", 3))
+ page = git_cmd;
+ else {
+ int page_len = strlen(git_cmd) + 4;
+
+ page = malloc(page_len + 1);
+ strcpy(page, "git-");
+ strcpy(page + 4, git_cmd);
+ page[page_len] = 0;
+ }
+
+ execlp("man", "man", page, NULL);
+}
+
int main(int argc, char **argv, char **envp)
{
char git_command[PATH_MAX + 1];
@@ -199,8 +217,12 @@ int main(int argc, char **argv, char **e
usage(NULL, NULL);
}
- if (i >= argc || show_help)
- usage(exec_path, NULL);
+ if (i >= argc || show_help) {
+ if (i >= argc)
+ usage(exec_path, NULL);
+
+ show_man_page(argv[i]);
+ }
/* allow relative paths, but run with exact */
if (chdir(exec_path)) {
---
0.99.9.GIT
^ 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