* Re: [PATCH 2/2] repo-config: learn the flag "--no-local"
From: Aneesh Kumar K.V @ 2006-06-08 15:35 UTC (permalink / raw)
To: Karl Hasselstr?m; +Cc: Lukas Sandstr?m, Git Mailing List, junkio
In-Reply-To: <20060608133747.GA15374@diana.vm.bytemark.co.uk>
On Thu, Jun 08, 2006 at 03:37:47PM +0200, Karl Hasselstr?m wrote:
> On 2006-06-08 13:41:04 +0200, Johannes Schindelin wrote:
>
> My vote goes to --no-local, but only if we also get a --no-no-local
> flag with the opposite meaning. Otherwise, I'd prefer --global. :-)
>
I guess it makes much sense to rename the command to git-config and say
git config alias.l -> for golbal config
git config --repo alias.l -> for repo specific config
-aneesh
^ permalink raw reply
* Re: [PATCH 2/2] repo-config: learn the flag "--no-local"
From: Aneesh Kumar K.V @ 2006-06-08 15:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: junkio, git
In-Reply-To: <Pine.LNX.4.63.0606081331140.11910@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, Jun 08, 2006 at 01:31:46PM +0200, 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).
>
how about making the above
git config --repo alias.l "log --stat -M ORIG_HEAD.."
-aneesh
^ permalink raw reply
* [PATCH 1/2]: amendment
From: Johannes Schindelin @ 2006-06-08 15:22 UTC (permalink / raw)
To: junkio, git
Hi,
I completely forgot that with a global config, it makes sense to have
aliases even if we are not in a git repository.
So, in git.c, handle_alias() the "if (nongit)" makes no sense any longer.
If I have to revise the patch anyway, I will include the change, but if
you decide to take it, please change that.
Ciao,
Dscho
P.S.: There might be other users (such as git-peek-remote) who want that
change, too.
^ permalink raw reply
* Re: [PATCH 0/2] Introduce ~/.gitconfig
From: Johannes Schindelin @ 2006-06-08 15:19 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Git List, Junio C Hamano
In-Reply-To: <1149775348.23938.236.camel@cashmere.sps.mot.com>
Hi,
On Thu, 8 Jun 2006, Jon Loeliger wrote:
> On Thu, 2006-06-08 at 06:30, Johannes Schindelin wrote:
>
> > - The --no-local flag could be implemented more cleanly, but also less
>
> Could we have multiple levels, and have names that call out
> where it applies? Perhaps something like:
>
> --repo into $GIT_DIR/.gitconfig <- current default, right?
> --home into ~/.gitconfig
> --site into /etc/gitconfig
> --share into /usr/share/git/config
>
> My issue is that --no-local is vague and doesn't call out
> where it actually does go. There could be more than one
> different non-local place.
The whole idea is that there are only two levels of configuration. Global
(applies to all calls to git) and local (applies only to the repository).
Now, it makes sense to make settings overrideable in a certain order: If
the global default does not match your needs in a particular case,
override it. With "git-repo-config <key> <value>".
*However*, if you want to change the default, it makes sense to say
"--no-local" or "--global", but I doubt that it makes any sense at all to
access a certain finer level. For example, when would you possibly need to
wrap in porcelain a method to query exactly which aliases are defined in
/usr/local/share/git/config?
IOW if you want to edit /etc/gitconfig or something else you need admin
permissions for with git-repo-config, you should look for another
profession. Quickly.
> But, hey, that's all pre-coffee.
post-coffee is pre-coffee.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/2] Introduce ~/.gitconfig
From: Alex Riesen @ 2006-06-08 14:49 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Johannes Schindelin, Git List, Junio C Hamano
In-Reply-To: <1149775348.23938.236.camel@cashmere.sps.mot.com>
On 6/8/06, Jon Loeliger <jdl@freescale.com> wrote:
> --repo into $GIT_DIR/.gitconfig <- current default, right?
> --home into ~/.gitconfig
> --site into /etc/gitconfig
> --share into /usr/share/git/config
BTW, if we go that far, maybe it makes more sense to
implement a way to include files other config files?
So repo-level config can (maybe implicitely) have an
"include ~/.gitconfig" which in turn can "include /etc/gitconfig".
We could even do like C-preprocessor does: relative
pathnames can be searched in a defined set of directores.
That's all overengineered, probably. I never needed .git/config,
except for switching exec-bit (which I'd like to have on per-site
basis, to be fair).
^ permalink raw reply
* Re: [PATCH 0/2] Introduce ~/.gitconfig
From: Jon Loeliger @ 2006-06-08 14:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git List, Junio C Hamano
In-Reply-To: <Pine.LNX.4.63.0606081329200.11910@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, 2006-06-08 at 06:30, Johannes Schindelin wrote:
>
> - The name. I personally prefer .gitconfig, since we talk about the repo
> config all the time. But I have no strong feelings there.
I like .gitconfig over .gitrc.
> - The --no-local flag could be implemented more cleanly, but also less
Could we have multiple levels, and have names that call out
where it applies? Perhaps something like:
--repo into $GIT_DIR/.gitconfig <- current default, right?
--home into ~/.gitconfig
--site into /etc/gitconfig
--share into /usr/share/git/config
My issue is that --no-local is vague and doesn't call out
where it actually does go. There could be more than one
different non-local place.
> - 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...)
I have often forgotten the "repo-" part, and go looking
for the "git config ..." man page and command. I think
it should be "git config".
Perhaps, "git repo-config" would be "git config --repo ...."
And "git config ..." would need an explict --home, --repo,
--site type location flag from above?
But, hey, that's all pre-coffee.
jdl
^ permalink raw reply
* Re: [PATCH 2/2] repo-config: learn the flag "--no-local"
From: Alex Riesen @ 2006-06-08 14:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Lukas Sandström, Git Mailing List, junkio
In-Reply-To: <Pine.LNX.4.63.0606081340230.25911@wbgn013.biozentrum.uni-wuerzburg.de>
> >
> > 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! ;-)
>
"--no-gitconfig" (as "--norc" in bash).
^ permalink raw reply
* Re: [PATCH 2/2] repo-config: learn the flag "--no-local"
From: Karl Hasselström @ 2006-06-08 13:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Lukas Sandström, Git Mailing List, junkio
In-Reply-To: <Pine.LNX.4.63.0606081340230.25911@wbgn013.biozentrum.uni-wuerzburg.de>
On 2006-06-08 13:41:04 +0200, Johannes Schindelin wrote:
> 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! ;-)
My vote goes to --no-local, but only if we also get a --no-no-local
flag with the opposite meaning. Otherwise, I'd prefer --global. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ 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
* 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: 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: 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: [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: [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
* 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 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
* 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
* [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
* [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 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
* 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
* 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
* 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: [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
* [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
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