* Re: [PATCH] cvsimport: complete the cvsps run before starting the import - BAD
From: Martin Langhoff @ 2006-06-08 0:06 UTC (permalink / raw)
To: junio; +Cc: git
Junio,
As far as I can see, you had the good sense of not applying this one.
It is bad, and should be dropped.
cheers,
martin
^ permalink raw reply
* Re: [PATCH] cvsimport: complete the cvsps run before starting the import - BAD
From: Junio C Hamano @ 2006-06-08 1:16 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90606071706w46567f6j4f4addae5c877537@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> As far as I can see, you had the good sense of not applying this one.
> It is bad, and should be dropped.
Actually it wasn't sense but distraction. I got sidetracked
while looking at the patch.
^ permalink raw reply
* Re: [PATCH] config.txt grammar, typo, and asciidoc fixes
From: Petr Baudis @ 2006-06-08 1:28 UTC (permalink / raw)
To: Francis Daly; +Cc: git
In-Reply-To: <20060607231505.GX29682@craic.sysops.org>
Dear diary, on Thu, Jun 08, 2006 at 01:15:05AM CEST, I got a letter
where Francis Daly <francis@daoine.org> said that...
> Nothing major.
>
> Signed-off-by: Francis Daly <francis@daoine.org>
>
> ---
>
> The first change makes it "the behaviour of the git command". If it was
> intended to be "the behaviour(s?) of the git commands" it would be a
> slightly different change.
Yes, it should probably read as "git commands' behavior".
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* gitignore: regex for the current dir files only?
From: Yasushi SHOJI @ 2006-06-08 2:13 UTC (permalink / raw)
To: git
Hello,
this problem came up when I was editing vmlinux.lds.S in the kernel
tree.
because we have "vmlinux*" in the toplevel .gitignore in linus's tree,
all vmlinux.lds.S under arch/$(ARCH)/kernel/ is affected. for kernel,
it might as easier to remove "*" from the exp. but I was wandering if
it's worth to have an expression for gitignore to handle "a regex for
the current dir only"?
comments?
--
yashi
^ permalink raw reply
* Re: gitignore: regex for the current dir files only?
From: Junio C Hamano @ 2006-06-08 2:40 UTC (permalink / raw)
To: Yasushi SHOJI; +Cc: git
In-Reply-To: <87mzcol7i3.wl@mail2.atmark-techno.com>
Yasushi SHOJI <yashi@atmark-techno.com> writes:
> because we have "vmlinux*" in the toplevel .gitignore in linus's tree,
> all vmlinux.lds.S under arch/$(ARCH)/kernel/ is affected. for kernel,
> it might as easier to remove "*" from the exp. but I was wandering if
> it's worth to have an expression for gitignore to handle "a regex for
> the current dir only"?
Yeah, that would be a very useful thing to have. Something like
this?
#!/bin/sh
rm -rf test
mkdir -p test/a/b/c
cd test
git init-db
date >a/vmlinux.1
date >a/b/vmlinux.2
date >a/b/c/vmlinux.3
echo 'vmlinux*' >a/.gitignore
echo '!/vmlinux*' >a/b/.gitignore
git status -u
^ permalink raw reply
* GIT 1.4.0-rc2
From: Junio C Hamano @ 2006-06-08 3:41 UTC (permalink / raw)
To: git
I've tagged the tip of "master" as v1.4.0-rc2.
Many documentation updates, new and much improved gitk, git
aliases stored in .git/config, and most importantly, http-fetch
fix.
I think we are getting there; expect real 1.4.0 this Saturday my
time. I am planning to throw in a bit of surprise in it as well.
* Shortlog since 1.4.0-rc1 *
Francis Daly:
Some doc typo fixes
config.txt grammar, typo, and asciidoc fixes
git-cvsserver asciidoc formatting tweaks
Horst H. von Brand:
Cleanup git-send-email.perl:extract_valid_email
Johannes Schindelin and Petr Baudis:
git aliases stored in .git/config
Jon Loeliger:
Refactor git_tcp_connect() functions a little.
Jonas Fonseca:
Misc doc improvements
Document git-ls-tree --fullname
Junio C Hamano:
git alias: try alias last.
send-email: be more lenient and just catch obvious mistakes.
send-email: a bit more careful domain regexp.
git-format-patch: add --output-directory long option again
HTTP cleanup
Make index file locking code reusable to others.
refs.c: convert it to use lockfile interface.
ref-log: style fixes.
Documentation: add missing docs make check-docs found.
make clean: remove dist-doc targets.
Documentation: git-ls-tree (typofix)
Documentation: add another example to git-ls-files
Nick Hengeveld:
HTTP cleanup
http-fetch: fix possible segfault
Paul Mackerras:
gitk: Make a row of controls for controlling highlighting
gitk: Highlight entries in the file list as well
gitk: Highlight paths of interest in tree view as well
gitk: First cut at a search function in the patch/file display window
gitk: Improve the text window search function
gitk: Move "pickaxe" find function to highlight facility
gitk: Fix bug in highlight stuff when no line is selected
gitk: Provide ability to highlight based on relationship to selected commit
gitk: Add a goto next/previous highlighted commit function
gitk: Show nearby tags
gitk: Show branch name(s) as well, if "show nearby tags" is enabled
gitk: Re-read the descendent/ancestor tag & head info on update
Petr Baudis:
Document git aliases support
Documentation: git aliases
Rene Scharfe:
Off-by-one error in get_path_prefix(), found by Valgrind
Robert Fitzsimons:
builtin-grep: pass ignore case option to external grep
^ permalink raw reply
* git-cvsservr questions
From: Jon Loeliger @ 2006-06-08 4:33 UTC (permalink / raw)
To: git
Mart{i,y}n et al,
I'm having a bit of a problem setting up my git-cvsserver.
I think I have followed the man page, but this is the
only real response I get:
$ setenv CVSROOT :pserver:anonymous@jdl.com:/pub/..../foo.git
$ cvs co master cvs [checkout aborted]: unrecognized auth response
from jdl.com: Unknown command BEGIN AUTH REQUEST at
/usr/bin/git-cvsserver line 132, <STDIN> line 1.
I've installed DBD:SQLite, but I don't know if it is working
or not. Not sure what file it would create in my repo if it
was working properly. I've made the bare repo directory be
mode 777 just to be sure it is writable by "nobody."
My client is 1.12.9.
I have enabled it the config file, and set a log file, but
I get no output. Do I need to enable the output somehow?
Other debug enabling bits to turn on for more help here?
Have I missed some obvious step? You know, intuit my problem
from my sparse description! :-) Well, or tell me what else
you need to know...
Thanks,
jdl
^ permalink raw reply
* Re: git-cvsservr questions
From: Martin Langhoff @ 2006-06-08 5:23 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1FoCCg-0002vH-FX@jdl.com>
On 6/8/06, Jon Loeliger <jdl@jdl.com> wrote:
> Mart{i,y}n et al,
>
> I'm having a bit of a problem setting up my git-cvsserver.
> I think I have followed the man page, but this is the
> only real response I get:
>
> $ setenv CVSROOT :pserver:anonymous@jdl.com:/pub/..../foo.git
> $ cvs co master cvs [checkout aborted]: unrecognized auth response
> from jdl.com: Unknown command BEGIN AUTH REQUEST at
> /usr/bin/git-cvsserver line 132, <STDIN> line 1.
...
> I have enabled it the config file, and set a log file
Very strange. The calling line to git-cvsserver should have the
'pserver' option. Perhaps the inetd configuration is missing the
doubled-up pserver?
cheers,
martin
^ permalink raw reply
* [PATCH] Document git-clone --use-separate-remote
From: Uwe Zeisberger @ 2006-06-08 6:50 UTC (permalink / raw)
To: git
Signed-off-by: Uwe Zeisberger <uzeisberger@io.fsforth.de>
---
Documentation/git-clone.txt | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 94d9393..7572e4b 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -11,7 +11,7 @@ SYNOPSIS
[verse]
'git-clone' [--template=<template_directory>] [-l [-s]] [-q] [-n] [--bare]
[-o <name>] [-u <upload-pack>] [--reference <repository>]
- <repository> [<directory>]
+ [--use-separate-remote] <repository> [<directory>]
DESCRIPTION
-----------
@@ -73,7 +73,7 @@ OPTIONS
files in `<directory>/.git`, make the `<directory>`
itself the `$GIT_DIR`. This implies `-n` option. When
this option is used, neither the `origin` branch nor the
- default `remotes/origin` file is created.
+ default `remotes/origin` file is created.
-o <name>::
Instead of using the branch name 'origin' to keep track
@@ -94,12 +94,17 @@ OPTIONS
if unset the templates are taken from the installation
defined default, typically `/usr/share/git-core/templates`.
+--use-separate-remote::
+ Save remotes heads under `$GIT_DIR/remotes/origin/' instead
+ of `$GIT_DIR/refs/heads/'. Only the master branch is saved
+ in the latter.
+
<repository>::
The (possibly remote) repository to clone from. It can
be any URL git-fetch supports.
<directory>::
- The name of a new directory to clone into. The "humanish"
+ The name of a new directory to clone into. The "humanish"
part of the source repository is used if no directory is
explicitly given ("repo" for "/path/to/repo.git" and "foo"
for "host.xz:foo/.git"). Cloning into an existing directory
--
1.3.3.g423a
--
Uwe Zeisberger
http://www.google.com/search?q=square+root+of+2
^ permalink raw reply related
* Re: [PATCH] Some doc typo fixes
From: Andreas Ericsson @ 2006-06-08 7:22 UTC (permalink / raw)
To: Francis Daly; +Cc: Junio C Hamano, git
In-Reply-To: <20060607174614.GU29682@craic.sysops.org>
Francis Daly wrote:
> On Wed, Jun 07, 2006 at 10:07:02AM -0700, Junio C Hamano wrote:
>
>>Junio C Hamano <junkio@cox.net> writes:
>>
>>>Francis Daly <francis@daoine.org> writes:
>
>
>>>Thanks. I am not a native, and this is very much appreciated.
>
>
> You're welcome.
>
>
>>>> . It could be named hierarchically (i.e. separated with slash
>>>>- `/`), but each of its component cannot begin with a dot `.`;
>>>>+ `/`), but each of its components cannot begin with a dot `.`;
>>>
>>>I am not sure; ...
>>
>>Sheesh, I was reading the diff backwards. Sorry.
>
>
> No worries. I had a head-scratching moment, and suspect that the whole
> stanza could be better phrased. If only there was someone who didn't
> already know what it means, they could suggest which phrasing makes
> it clear...
>
> How about rewriting it as
>
> It can include slash `/` for hierarchical (directory) grouping, but no
> slash-separated component can begin with a dot `.`;
>
> ?
>
I like it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* HEAD branch duplicated in remotes/origin
From: Uwe Zeisberger @ 2006-06-08 7:38 UTC (permalink / raw)
To: git
Hello,
when cloning with --use-separate-remote, $GITDIR/remotes/origin contains
two references to refs/heads/master. This breaks `git fetch origin'.
uzeisberger@io:~/gsrc$ git --version
git version 1.4.0.rc2.ga95e
uzeisberger@io:~/gsrc$ git clone --use-separate-remote git://git.kernel.org/pub/scm/git/git.git git-copy
Checking files out...)
100% (523/523) done
uzeisberger@io:~/gsrc$ cd git-copy
uzeisberger@io:~/gsrc/git-copy$ git fetch origin
error: no such remote ref refs/heads/master
Fetch failure: git://git.kernel.org/pub/scm/git/git.git
uzeisberger@io:~/gsrc/git-copy$ grep -n master .git/remotes/origin
2:Pull: refs/heads/master:refs/remotes/origin/master
12:Pull: refs/heads/master:refs/remotes/origin/master
uzeisberger@io:~/gsrc/git-copy$ sed -i 2d .git/remotes/origin
uzeisberger@io:~/gsrc/git-copy$ git fetch origin
uzeisberger@io:~/gsrc/git-copy$
I didn't look into it deeply, but I think this happens because the
remote HEAD is translated to refs/heads/master and added while master is
added once more while processing refs/heads/master explicitly.
Best regards
Uwe
--
Uwe Zeisberger
http://www.google.com/search?q=12+divided+by+3
^ permalink raw reply
* Re: HEAD branch duplicated in remotes/origin
From: Junio C Hamano @ 2006-06-08 8:17 UTC (permalink / raw)
To: Uwe Zeisberger; +Cc: git
In-Reply-To: <20060608073857.GA5072@informatik.uni-freiburg.de>
Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> writes:
> when cloning with --use-separate-remote, $GITDIR/remotes/origin contains
> two references to refs/heads/master.
Thanks for noticing.
Very lightly tested but I think this should fix it.
-- >8 --
git-clone: fix duplicated "master" in $GIT_DIR/remotes/origin
Under --use-separate-remote we ended up duplicating the branch
remote HEAD pointed at in $GIT_DIR/remotes/origin file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-clone.sh b/git-clone.sh
index de59904..64318b4 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -391,11 +391,16 @@ Pull: refs/heads/$head_points_at:$origin
(cd "$GIT_DIR/$remote_top" && find . -type f -print) |
while read dotslref
do
- name=`expr "$dotslref" : './\(.*\)'` &&
- test "$use_separate_remote" = '' && {
- test "$head_points_at" = "$name" ||
- test "$origin" = "$name"
- } ||
+ name=`expr "$dotslref" : './\(.*\)'`
+ if test "z$head_points_at" = "z$name"
+ then
+ continue
+ fi
+ if test "$use_separate_remote" = '' &&
+ test "z$origin" = "z$name"
+ then
+ continue
+ fi
echo "Pull: refs/heads/${name}:$remote_top/${name}"
done >>"$GIT_DIR/remotes/$origin" &&
case "$use_separate_remote" in
^ permalink raw reply related
* Re: [RFC][PATCH] Allow transfer of any valid sha1
From: Eric W. Biederman @ 2006-06-08 9:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virntsto6.fsf@assigned-by-dhcp.cox.net>
A quick status update.
I think I have clean working version of the sha1 transfer code,
I left on vacation before I could send it out so I need to dig
it out and make certain everything still applies.
I finally figured out what my problem pulling Andrew's changes
were. git-quiltimport remembers what the previous commit was and when
I added merging I forgot to update that the variable that stores
the previous commit. So since I had the history wrong git-merge
was finding the wrong common ancestor, which is an easy way
to mess up an automatic merge :)
> The last time I talked with Andrew, he is not doing a merge nor
> resolving merge conflicts. He treats git primarily as a
> patchbomb distribution mechanism, and works on (a rough
> equivalent of) the output of format-patch from merge base
> between his base tree and individual subsystem tree. After that
> things are normal quilt workflow outside git, whatever it is.
Andrews git import does appear to be a git-pull from an appropriate
tree and then a diff of the automatic merge result, so while
there doesn't appear to be manual merging there is a little
bit of automatic merging going on.
Anyway when I wake up in the morning I should see if I have
successfully imported Andres 2.6.17-rc5-mm3 tree. All of that
pulling of git trees on demand noticeably slows down the import
on my dinky test machine. I'm not certain how much of that
a machine that had plenty of memory would see though.
Eric
^ permalink raw reply
* [PATCH 0/2] Introduce ~/.gitconfig
From: Johannes Schindelin @ 2006-06-08 11:30 UTC (permalink / raw)
To: git, junkio
These two patches introduce the long awaited global config. Thanks to
Paksy for pushing and starting it.
The first patch only does the reading part, while the second introduces the
--no-local flag to git-repo-config.
There are three subjects for discussion:
- The name. I personally prefer .gitconfig, since we talk about the repo
config all the time. But I have no strong feelings there.
- The --no-local flag could be implemented more cleanly, but also less
elegantly, by introducing git_config_set_multivar_in_file(). I hesitated
to do that, because there would be even more places replicating the
global / local path resolution.
- With this, repo-config does no longer merit its name. What do people think
about making it a builtin named "git config"? (Of course, nothing hinders
us to keep the synonymous "repo-config" indefinitely...)
Ciao,
Dscho
^ permalink raw reply
* [PATCH 1/2] Read configuration also from ~/.gitconfig
From: Johannes Schindelin @ 2006-06-08 11:31 UTC (permalink / raw)
To: git; +Cc: junkio
This patch is based on Pasky's, with three notable differences:
- I did not yet update the documentation
- I named it .gitconfig, not .gitrc
- git-repo-config does not barf when a unique key is overridden locally
The last means that if you have something like
[alias]
l = log --stat -M
in ~/.gitconfig, and
[alias]
l = log --stat -M next..
in $GIT_DIR/config, then
git-repo-config alias.l
returns only one value, namely the value from $GIT_DIR/config.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
config.c | 13 ++++++++++++-
repo-config.c | 9 ++++++++-
t/t1300-repo-config.sh | 3 ++-
3 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/config.c b/config.c
index 2ae6153..0987943 100644
--- a/config.c
+++ b/config.c
@@ -317,7 +317,18 @@ int git_config_from_file(config_fn_t fn,
int git_config(config_fn_t fn)
{
- return git_config_from_file(fn, git_path("config"));
+ int ret = 0;
+ const char *home = getenv("HOME");
+
+ if (home) {
+ ret = git_config_from_file(fn, mkpath("%s/.gitconfig", home));
+ /* ignore if global config does not exist */
+ if (ret < 0)
+ ret = 0;
+ }
+
+ ret += git_config_from_file(fn, git_path("config"));
+ return ret;
}
/*
diff --git a/repo-config.c b/repo-config.c
index 08fc4cc..59c2bfb 100644
--- a/repo-config.c
+++ b/repo-config.c
@@ -65,6 +65,8 @@ static int show_config(const char* key_,
static int get_value(const char* key_, const char* regex_)
{
char *tl;
+ const char *home = getenv("HOME");
+ const char *global = (home ? mkpath("%s/.gitconfig", home) : NULL);
key = strdup(key_);
for (tl=key+strlen(key)-1; tl >= key && *tl != '.'; --tl)
@@ -93,7 +95,12 @@ static int get_value(const char* key_, c
}
}
- git_config(show_config);
+ if (do_all && global)
+ git_config_from_file(show_config, global);
+ git_config_from_file(show_config, git_path("config"));
+ if (!do_all && !seen)
+ git_config_from_file(show_config, global);
+
free(key);
if (regexp) {
regfree(regexp);
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 8260d57..ce36c50 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -254,8 +254,9 @@ nextsection.nonewline=wow2 for me
version.1.2.3eX.alpha=beta
EOF
+# "HOME=." is there to avoid reading ~/.gitconfig
test_expect_success 'working --list' \
- 'git-repo-config --list > output && cmp output expect'
+ 'HOME=. git-repo-config --list > output && cmp output expect'
cat > expect << EOF
beta.noindent sillyValue
--
1.4.0.rc1.g2f47-dirty
^ permalink raw reply related
* [PATCH 2/2] repo-config: learn the flag "--no-local"
From: Johannes Schindelin @ 2006-06-08 11:31 UTC (permalink / raw)
To: git; +Cc: junkio
Since there is a global config now, we need a way to access it
conveniently. Now you can say
git repo-config --no-local alias.l "log --stat -M ORIG_HEAD.."
to set the alias globally (it will be stored in ~/.gitconfig).
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
cache.h | 1 +
config.c | 23 ++++++++++++++++++-----
repo-config.c | 5 ++++-
3 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/cache.h b/cache.h
index d5d7fe4..14fe5c8 100644
--- a/cache.h
+++ b/cache.h
@@ -348,6 +348,7 @@ extern void packed_object_info_detail(st
/* Dumb servers support */
extern int update_server_info(int);
+extern int git_ignore_local_config;
typedef int (*config_fn_t)(const char *, const char *);
extern int git_default_config(const char *, const char *);
extern int git_config_from_file(config_fn_t fn, const char *);
diff --git a/config.c b/config.c
index 0987943..33f9109 100644
--- a/config.c
+++ b/config.c
@@ -10,6 +10,7 @@ #include <regex.h>
#define MAXNAME (256)
+int git_ignore_local_config = 0;
static FILE *config_file;
static const char *config_file_name;
static int config_linenr;
@@ -327,7 +328,8 @@ int git_config(config_fn_t fn)
ret = 0;
}
- ret += git_config_from_file(fn, git_path("config"));
+ if (!git_ignore_local_config)
+ ret += git_config_from_file(fn, git_path("config"));
return ret;
}
@@ -501,10 +503,20 @@ int git_config_set_multivar(const char*
int i, dot;
int fd = -1, in_fd;
int ret;
- char* config_filename = strdup(git_path("config"));
- char* lock_file = strdup(git_path("config.lock"));
+ char *config_filename, *lock_file;
const char* last_dot = strrchr(key, '.');
+ if (git_ignore_local_config) {
+ const char *home = getenv("HOME");
+ if (!home)
+ die("No home?");
+ config_filename = strdup(mkpath("%s/.gitconfig", home));
+ lock_file = strdup(mkpath("%s/.gitconfig.lock", home));
+ } else {
+ config_filename = strdup(git_path("config"));
+ lock_file = strdup(git_path("config.lock"));
+ }
+
/*
* Since "key" actually contains the section name and the real
* key name separated by a dot, we have to know where the dot is.
@@ -611,8 +623,9 @@ int git_config_set_multivar(const char*
* As a side effect, we make sure to transform only a valid
* existing config file.
*/
- if (git_config(store_aux)) {
- fprintf(stderr, "invalid config file\n");
+ if (git_config_from_file(store_aux, config_filename)) {
+ fprintf(stderr, "invalid config file: %s\n",
+ config_filename);
free(store.key);
if (store.value_regex != NULL) {
regfree(store.value_regex);
diff --git a/repo-config.c b/repo-config.c
index 59c2bfb..8c0bb20 100644
--- a/repo-config.c
+++ b/repo-config.c
@@ -97,7 +97,8 @@ static int get_value(const char* key_, c
if (do_all && global)
git_config_from_file(show_config, global);
- git_config_from_file(show_config, git_path("config"));
+ if (!git_ignore_local_config)
+ git_config_from_file(show_config, git_path("config"));
if (!do_all && !seen)
git_config_from_file(show_config, global);
@@ -125,6 +126,8 @@ int main(int argc, const char **argv)
type = T_BOOL;
else if (!strcmp(argv[1], "--list") || !strcmp(argv[1], "-l"))
return git_config(show_all_config);
+ else if (!strcmp(argv[1], "--no-local"))
+ git_ignore_local_config = 1;
else
break;
argc--;
--
1.4.0.rc1.g2f47-dirty
^ permalink raw reply related
* Re: [PATCH 2/2] repo-config: learn the flag "--no-local"
From: Lukas Sandström @ 2006-06-08 11:37 UTC (permalink / raw)
To: Git Mailing List; +Cc: Johannes Schindelin, junkio
In-Reply-To: <Pine.LNX.4.63.0606081331140.11910@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Since there is a global config now, we need a way to access it
> conveniently. Now you can say
>
> git repo-config --no-local alias.l "log --stat -M ORIG_HEAD.."
>
> to set the alias globally (it will be stored in ~/.gitconfig).
>
Wouldn't it make more sense to call the flag --global ?
/Lukas
^ permalink raw reply
* Re: [PATCH 2/2] repo-config: learn the flag "--no-local"
From: Johannes Schindelin @ 2006-06-08 11:41 UTC (permalink / raw)
To: Lukas Sandström; +Cc: Git Mailing List, junkio
In-Reply-To: <44880BE8.40804@etek.chalmers.se>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 492 bytes --]
Hi,
On Thu, 8 Jun 2006, Lukas Sandström wrote:
> Johannes Schindelin wrote:
> > Since there is a global config now, we need a way to access it
> > conveniently. Now you can say
> >
> > git repo-config --no-local alias.l "log --stat -M ORIG_HEAD.."
> >
> > to set the alias globally (it will be stored in ~/.gitconfig).
> >
>
> Wouldn't it make more sense to call the flag --global ?
Sure, why not? Other opinions? (I will not add a test case until this is
resolved! ;-)
Ciao,
Dscho
^ permalink raw reply
* SV: [PATCH 0/2] Introduce ~/.gitconfig
From: Sven Ekman @ 2006-06-08 12:02 UTC (permalink / raw)
To: Johannes Schindelin, git, junkio
In-Reply-To: <Pine.LNX.4.63.0606081329200.11910@wbgn013.biozentrum.uni-wuerzburg.de>
<Johannes.Schindelin@gmx.de> skrev:
> There are three subjects for discussion:
Have you considered making ~/.gitconfig a directory?
Maybe Git wants to store more data later.
Maybe, porcelains would want to use this directory,
too. Gitk, tig, maybe Cogito at some time. One could
have the configuration of all these git-related tools
in a common namespace.
People like me, who work on a lot of different
machines, could simply sync this directory across
accounts and always work in their environment.
Sven
^ permalink raw reply
* Re: [PATCH 0/2] Introduce ~/.gitconfig
From: Nikolai Weibull @ 2006-06-08 12:06 UTC (permalink / raw)
To: Sven Ekman; +Cc: Johannes Schindelin, git, junkio
In-Reply-To: <20060608120216.46722.qmail@web25908.mail.ukl.yahoo.com>
On 6/8/06, Sven Ekman <svekman@yahoo.se> wrote:
> <Johannes.Schindelin@gmx.de> skrev:
>
> > There are three subjects for discussion:
>
> Have you considered making ~/.gitconfig a directory?
> Maybe Git wants to store more data later.
I second that. And it'd be nice if it was configurable through
an environment variable, e.g., GIT_USER_CONFIG_HOME.
A better name may be possible ;-).
nikolai
^ permalink raw reply
* Re: [PATCH 0/2] Introduce ~/.gitconfig
From: Johannes Schindelin @ 2006-06-08 12:21 UTC (permalink / raw)
To: Nikolai Weibull; +Cc: Sven Ekman, git, junkio
In-Reply-To: <dbfc82860606080506y52dc2771sbf6c90e7246ca4c9@mail.gmail.com>
Hi,
On Thu, 8 Jun 2006, Nikolai Weibull wrote:
> On 6/8/06, Sven Ekman <svekman@yahoo.se> wrote:
> > <Johannes.Schindelin@gmx.de> skrev:
> >
> > > There are three subjects for discussion:
> >
> > Have you considered making ~/.gitconfig a directory?
> > Maybe Git wants to store more data later.
>
> I second that.
I don't. What's wrong with the simple approach of a single config file?
You can use a single tool for all the configuration, and do not need to
care about anything.
After all, it is about _configuration_, not data storing. That is what
$GIT_DIR/objects is for.
> And it'd be nice if it was configurable through an environment variable,
> e.g., GIT_USER_CONFIG_HOME.
<sarcasm ignore=if-possible>
Let's see. AFAIK all programs I know (including cvs and vim, for
one) have a fixed name. Hmm. Perhaps this is for a reason? Like, to reduce
confusion?
Alternatively, we could introduce a config variable "core.globalConfig" to
see where the global config is.
</sarcasm>
Ciao,
Dscho
^ permalink raw reply
* Re: HEAD branch duplicated in remotes/origin
From: Uwe Zeisberger @ 2006-06-08 12:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vverc9i4i.fsf@assigned-by-dhcp.cox.net>
Hello Junio,
Junio C Hamano wrote:
> Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> writes:
>
> > when cloning with --use-separate-remote, $GITDIR/remotes/origin contains
> > two references to refs/heads/master.
>
> Thanks for noticing.
>
> Very lightly tested but I think this should fix it.
> -- >8 --
> git-clone: fix duplicated "master" in $GIT_DIR/remotes/origin
>
> Under --use-separate-remote we ended up duplicating the branch
> remote HEAD pointed at in $GIT_DIR/remotes/origin file.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
> ---
> diff --git a/git-clone.sh b/git-clone.sh
> index de59904..64318b4 100755
> --- a/git-clone.sh
> +++ b/git-clone.sh
> @@ -391,11 +391,16 @@ Pull: refs/heads/$head_points_at:$origin
> (cd "$GIT_DIR/$remote_top" && find . -type f -print) |
> while read dotslref
> do
> - name=`expr "$dotslref" : './\(.*\)'` &&
> - test "$use_separate_remote" = '' && {
> - test "$head_points_at" = "$name" ||
> - test "$origin" = "$name"
> - } ||
> + name=`expr "$dotslref" : './\(.*\)'`
> + if test "z$head_points_at" = "z$name"
> + then
> + continue
> + fi
> + if test "$use_separate_remote" = '' &&
> + test "z$origin" = "z$name"
> + then
> + continue
> + fi
> echo "Pull: refs/heads/${name}:$remote_top/${name}"
> done >>"$GIT_DIR/remotes/$origin" &&
> case "$use_separate_remote" in
>
I wonder if this is easier not to add the other duplicate. That is let
this as it is and don't add the head HEAD points at. Don't know, didn't
look into it.
Moreover, is it sound to error if a Pull: line is duplicated? In my
eyes at least the error message is wrong/missleading. Otherwise the
patch works for me, but probably I only did the same testing as you.
Best regards
Uwe
--
Uwe Zeisberger
cal 9 1752 | grep 10
^ permalink raw reply
* Re: git-cvsservr questions
From: Jon Loeliger @ 2006-06-08 13:03 UTC (permalink / raw)
To: git
> Very strange. The calling line to git-cvsserver should have the
> 'pserver' option. Perhaps the inetd configuration is missing the
> doubled-up pserver?
Oh wow.
I thought I had tried that step already. So I went back and looked.
I _had_ tried that step -- but it was when I didn't have a full path
to the git-cvsserver executable on my inetd.conf line...
In summary, I had to:
use a full path to the excutable,
double the pserver command line arg,
fix the owner of my logfile to be "nobody".
Worked like a charm!
Thanks!
jdl
^ permalink raw reply
* Re: [PATCH 0/2] Introduce ~/.gitconfig
From: Nikolai Weibull @ 2006-06-08 13:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sven Ekman, git, junkio
In-Reply-To: <Pine.LNX.4.63.0606081415380.26091@wbgn013.biozentrum.uni-wuerzburg.de>
On 6/8/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 8 Jun 2006, Nikolai Weibull wrote:
> > On 6/8/06, Sven Ekman <svekman@yahoo.se> wrote:
> > > <Johannes.Schindelin@gmx.de> skrev:
> > > Have you considered making ~/.gitconfig a directory?
> > > Maybe Git wants to store more data later.
> > I second that.
> I don't. What's wrong with the simple approach of a single config file?
> You can use a single tool for all the configuration, and do not need to
> care about anything.
Who said anything about something more than one configuration file?
It's nice to have a directory if we later decide to store other kinds of files
there as well, e.g., templates or some keyring information or something else,
perhaps not well-suited for storing in an ini-like file.
> > And it'd be nice if it was configurable through an environment variable,
> > e.g., GIT_USER_CONFIG_HOME.
> Let's see. AFAIK all programs I know (including cvs and vim, for
> one) have a fixed name. Hmm. Perhaps this is for a reason? Like, to reduce
> confusion?
That's hardly a very good reason. It's not like you _have_ to use another name.
I keep as many configuration files as possible in ~/.local/etc/, as it
simplifies
keeping them in a Git repository. Here's an extract from my .zprofile:
XDG_CONFIG_HOME=~/.local/etc
VIMINIT="so $XDG_CONFIG_HOME/vim/vimrc"
INPUTRC=$XDG_CONFIG_HOME/inputrc
INDENT_PROFILE=$XDG_CONFIG_HOME/indentrc
SCREENRC=$XDG_CONFIG_HOME/screenrc
GNUPGHOME=$XDG_CONFIG_HOME/gnupg
IRBRC=$XDG_CONFIG_HOME/irbrc
LFTP_HOME=$XDG_CONFIG_HOME/lftp
MPLAYER_HOME=$XDG_CONFIG_HOME/mplayer
GTK2_RC_FILES=$XDG_CONFIG_HOME/gtkrc
The only programs that don't play along, yet, are Mozilla, OpenSSH,
and Subversion. (Mozilla is actually compile-time configurable.)
But I guess I should be providing a patch instead of just a bunch of
reasoning for someone else to write one...
> Alternatively, we could introduce a config variable "core.globalConfig" to
> see where the global config is.
That is a very good idea. We wouldn't need an environment variable in
that case.
nikolai (who wonders if people can spot irony and sarcasm without extra help)
^ permalink raw reply
* Re: [PATCH 0/2] Introduce ~/.gitconfig
From: Johannes Schindelin @ 2006-06-08 13:35 UTC (permalink / raw)
To: Nikolai Weibull; +Cc: Sven Ekman, git, junkio
In-Reply-To: <dbfc82860606080613n5b5f6a5bs7a8f461a4188228c@mail.gmail.com>
Hi,
On Thu, 8 Jun 2006, Nikolai Weibull wrote:
> Who said anything about something more than one configuration file? It's
> nice to have a directory if we later decide to store other kinds of
> files there as well, e.g., templates or some keyring information or
> something else, perhaps not well-suited for storing in an ini-like file.
My point was: this has nothing to do with the "git config". Gitk, for
example, has its own file there, ~/.gitk.
> > Alternatively, we could introduce a config variable "core.globalConfig" to
> > see where the global config is.
>
> That is a very good idea. We wouldn't need an environment variable in
> that case.
>
> nikolai (who wonders if people can spot irony and sarcasm without extra
> help)
No they can't. You almost had me falling for it...
Ciao,
Dscho
P.S.: I also wanted to mention that we could migrate all the config into
an XML format. And maybe have an SQL backend instead of an object store.
^ 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