2005-10-12 05:47:34 +04:00
|
|
|
/*
|
|
|
|
* We put all the git config variables in this same object
|
|
|
|
* file, so that programs can link against the config parser
|
|
|
|
* without having to link against all the rest of git.
|
|
|
|
*
|
|
|
|
* In particular, no need to bring in libz etc unless needed,
|
|
|
|
* even if you might want to know where the git directory etc
|
|
|
|
* are.
|
|
|
|
*/
|
|
|
|
#include "cache.h"
|
|
|
|
|
|
|
|
char git_default_email[MAX_GITNAME];
|
|
|
|
char git_default_name[MAX_GITNAME];
|
|
|
|
int trust_executable_bit = 1;
|
2007-06-25 02:11:24 +04:00
|
|
|
int quote_path_fully = 1;
|
2007-03-03 00:11:30 +03:00
|
|
|
int has_symlinks = 1;
|
2006-08-15 21:23:48 +04:00
|
|
|
int assume_unchanged;
|
|
|
|
int prefer_symlink_refs;
|
2007-01-07 13:00:28 +03:00
|
|
|
int is_bare_repository_cfg = -1; /* unspecified */
|
Move initialization of log_all_ref_updates
The patches to prevent Porcelainish that require working tree
from doing any damage in a bare repository make a lot of sense,
and I want to make the is_bare_git_dir() function more reliable.
In order to allow the repository owner override the heuristic
implemented in is_bare_git_dir() if/when it misidentifies a
particular repository, it would make sense to introduce a new
configuration variable "[core] bare = true/false", and make
is_bare_git_dir() notice it.
The scripts would do a 'repo-config --bool --get core.bare' and
iff the command fails (i.e. there is no such variable in the
configuration file), it would use the heuristic implemented at
the script level [*1*].
However, setup_git_env() which is called a lot earlier than we
even read from the repository configuration currently makes a
call to is_bare_git_dir(), in order to change the default
setting for log_all_ref_updates. It somehow feels that this is
a hack.
By the way, [*1*] is another thing I hate about the current
config mechanism. "git-repo-config --get" does not know what
the possible configuration variables are, let alone what the
default values for them are. It allows us not to maintain a
centralized configuration table, which makes it easy to
introduce ad-hoc variables and gives a warm fuzzy feeling of
being modular, but my feeling is that it is turning out to be a
rather high price to pay for scripts.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-07 12:35:34 +03:00
|
|
|
int log_all_ref_updates = -1; /* unspecified */
|
2006-03-24 10:42:40 +03:00
|
|
|
int warn_ambiguous_refs = 1;
|
2006-08-15 21:23:48 +04:00
|
|
|
int repository_format_version;
|
2007-03-12 22:33:18 +03:00
|
|
|
const char *git_commit_encoding;
|
2007-03-07 04:44:17 +03:00
|
|
|
const char *git_log_output_encoding;
|
2006-06-10 10:09:49 +04:00
|
|
|
int shared_repository = PERM_UMASK;
|
2006-08-15 21:23:48 +04:00
|
|
|
const char *apply_default_whitespace;
|
Custom compression levels for objects and packs
Add config variables pack.compression and core.loosecompression ,
and switch --compression=level to pack-objects.
Loose objects will be compressed using core.loosecompression if set,
else core.compression if set, else Z_BEST_SPEED.
Packed objects will be compressed using --compression=level if seen,
else pack.compression if set, else core.compression if set,
else Z_DEFAULT_COMPRESSION. This is the "pack compression level".
Loose objects added to a pack undeltified will be recompressed
to the pack compression level if it is unequal to the current
loose compression level by the preceding rules, or if the loose
object was written while core.legacyheaders = true. Newly
deltified loose objects are always compressed to the current
pack compression level.
Previously packed objects added to a pack are recompressed
to the current pack compression level exactly when their
deltification status changes, since the previous pack data
cannot be reused.
In either case, the --no-reuse-object switch from the first
patch below will always force recompression to the current pack
compression level, instead of assuming the pack compression level
hasn't changed and pack data can be reused when possible.
This applies on top of the following patches from Nicolas Pitre:
[PATCH] allow for undeltified objects not to be reused
[PATCH] make "repack -f" imply "pack-objects --no-reuse-object"
Signed-off-by: Dana L. How <danahow@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-10 00:56:50 +04:00
|
|
|
int zlib_compression_level = Z_BEST_SPEED;
|
|
|
|
int core_compression_level;
|
|
|
|
int core_compression_seen;
|
2006-12-24 08:46:13 +03:00
|
|
|
size_t packed_git_window_size = DEFAULT_PACKED_GIT_WINDOW_SIZE;
|
|
|
|
size_t packed_git_limit = DEFAULT_PACKED_GIT_LIMIT;
|
2007-03-19 08:14:37 +03:00
|
|
|
size_t delta_base_cache_limit = 16 * 1024 * 1024;
|
2007-07-03 22:18:11 +04:00
|
|
|
char *pager_program;
|
2006-07-10 15:40:44 +04:00
|
|
|
int pager_in_use;
|
2006-07-30 02:27:43 +04:00
|
|
|
int pager_use_color = 1;
|
2007-07-20 16:06:09 +04:00
|
|
|
char *editor_program;
|
core.excludesfile clean-up
There are inconsistencies in the way commands currently handle
the core.excludesfile configuration variable. The problem is
the variable is too new to be noticed by anything other than
git-add and git-status.
* git-ls-files does not notice any of the "ignore" files by
default, as it predates the standardized set of ignore files.
The calling scripts established the convention to use
.git/info/exclude, .gitignore, and later core.excludesfile.
* git-add and git-status know about it because they call
add_excludes_from_file() directly with their own notion of
which standard set of ignore files to use. This is just a
stupid duplication of code that need to be updated every time
the definition of the standard set of ignore files is
changed.
* git-read-tree takes --exclude-per-directory=<gitignore>,
not because the flexibility was needed. Again, this was
because the option predates the standardization of the ignore
files.
* git-merge-recursive uses hardcoded per-directory .gitignore
and nothing else. git-clean (scripted version) does not
honor core.* because its call to underlying ls-files does not
know about it. git-clean in C (parked in 'pu') doesn't either.
We probably could change git-ls-files to use the standard set
when no excludes are specified on the command line and ignore
processing was asked, or something like that, but that will be a
change in semantics and might break people's scripts in a subtle
way. I am somewhat reluctant to make such a change.
On the other hand, I think it makes perfect sense to fix
git-read-tree, git-merge-recursive and git-clean to follow the
same rule as other commands. I do not think of a valid use case
to give an exclude-per-directory that is nonstandard to
read-tree command, outside a "negative" test in the t1004 test
script.
This patch is the first step to untangle this mess.
The next step would be to teach read-tree, merge-recursive and
clean (in C) to use setup_standard_excludes().
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-14 11:05:00 +03:00
|
|
|
char *excludes_file;
|
2007-02-14 05:16:12 +03:00
|
|
|
int auto_crlf = 0; /* 1: both ways, -1: only when adding git objects */
|
2005-10-12 05:47:34 +04:00
|
|
|
|
Clean up work-tree handling
The old version of work-tree support was an unholy mess, barely readable,
and not to the point.
For example, why do you have to provide a worktree, when it is not used?
As in "git status". Now it works.
Another riddle was: if you can have work trees inside the git dir, why
are some programs complaining that they need a work tree?
IOW it is allowed to call
$ git --git-dir=../ --work-tree=. bla
when you really want to. In this case, you are both in the git directory
and in the working tree. So, programs have to actually test for the right
thing, namely if they are inside a working tree, and not if they are
inside a git directory.
Also, GIT_DIR=../.git should behave the same as if no GIT_DIR was
specified, unless there is a repository in the current working directory.
It does now.
The logic to determine if a repository is bare, or has a work tree
(tertium non datur), is this:
--work-tree=bla overrides GIT_WORK_TREE, which overrides core.bare = true,
which overrides core.worktree, which overrides GIT_DIR/.. when GIT_DIR
ends in /.git, which overrides the directory in which .git/ was found.
In related news, a long standing bug was fixed: when in .git/bla/x.git/,
which is a bare repository, git formerly assumed ../.. to be the
appropriate git dir. This problem was reported by Shawn Pearce to have
caused much pain, where a colleague mistakenly ran "git init" in "/" a
long time ago, and bare repositories just would not work.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-01 04:30:14 +04:00
|
|
|
/* This is set by setup_git_dir_gently() and/or git_default_config() */
|
|
|
|
char *git_work_tree_cfg;
|
|
|
|
static const char *work_tree;
|
|
|
|
|
2006-08-23 14:39:11 +04:00
|
|
|
static const char *git_dir;
|
|
|
|
static char *git_object_dir, *git_index_file, *git_refs_dir, *git_graft_file;
|
|
|
|
|
2005-10-12 05:47:34 +04:00
|
|
|
static void setup_git_env(void)
|
|
|
|
{
|
|
|
|
git_dir = getenv(GIT_DIR_ENVIRONMENT);
|
|
|
|
if (!git_dir)
|
|
|
|
git_dir = DEFAULT_GIT_DIR_ENVIRONMENT;
|
|
|
|
git_object_dir = getenv(DB_ENVIRONMENT);
|
|
|
|
if (!git_object_dir) {
|
|
|
|
git_object_dir = xmalloc(strlen(git_dir) + 9);
|
|
|
|
sprintf(git_object_dir, "%s/objects", git_dir);
|
|
|
|
}
|
|
|
|
git_refs_dir = xmalloc(strlen(git_dir) + 6);
|
|
|
|
sprintf(git_refs_dir, "%s/refs", git_dir);
|
|
|
|
git_index_file = getenv(INDEX_ENVIRONMENT);
|
|
|
|
if (!git_index_file) {
|
|
|
|
git_index_file = xmalloc(strlen(git_dir) + 7);
|
|
|
|
sprintf(git_index_file, "%s/index", git_dir);
|
|
|
|
}
|
|
|
|
git_graft_file = getenv(GRAFT_ENVIRONMENT);
|
|
|
|
if (!git_graft_file)
|
2006-09-02 08:16:31 +04:00
|
|
|
git_graft_file = xstrdup(git_path("info/grafts"));
|
2006-12-15 01:41:17 +03:00
|
|
|
}
|
|
|
|
|
2007-01-07 13:00:28 +03:00
|
|
|
int is_bare_repository(void)
|
2006-12-15 01:41:17 +03:00
|
|
|
{
|
Clean up work-tree handling
The old version of work-tree support was an unholy mess, barely readable,
and not to the point.
For example, why do you have to provide a worktree, when it is not used?
As in "git status". Now it works.
Another riddle was: if you can have work trees inside the git dir, why
are some programs complaining that they need a work tree?
IOW it is allowed to call
$ git --git-dir=../ --work-tree=. bla
when you really want to. In this case, you are both in the git directory
and in the working tree. So, programs have to actually test for the right
thing, namely if they are inside a working tree, and not if they are
inside a git directory.
Also, GIT_DIR=../.git should behave the same as if no GIT_DIR was
specified, unless there is a repository in the current working directory.
It does now.
The logic to determine if a repository is bare, or has a work tree
(tertium non datur), is this:
--work-tree=bla overrides GIT_WORK_TREE, which overrides core.bare = true,
which overrides core.worktree, which overrides GIT_DIR/.. when GIT_DIR
ends in /.git, which overrides the directory in which .git/ was found.
In related news, a long standing bug was fixed: when in .git/bla/x.git/,
which is a bare repository, git formerly assumed ../.. to be the
appropriate git dir. This problem was reported by Shawn Pearce to have
caused much pain, where a colleague mistakenly ran "git init" in "/" a
long time ago, and bare repositories just would not work.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-01 04:30:14 +04:00
|
|
|
/* if core.bare is not 'false', let's see if there is a work tree */
|
|
|
|
return is_bare_repository_cfg && !get_git_work_tree();
|
2005-10-12 05:47:34 +04:00
|
|
|
}
|
|
|
|
|
2006-08-23 14:39:11 +04:00
|
|
|
const char *get_git_dir(void)
|
2005-10-12 05:47:34 +04:00
|
|
|
{
|
|
|
|
if (!git_dir)
|
|
|
|
setup_git_env();
|
|
|
|
return git_dir;
|
|
|
|
}
|
|
|
|
|
Clean up work-tree handling
The old version of work-tree support was an unholy mess, barely readable,
and not to the point.
For example, why do you have to provide a worktree, when it is not used?
As in "git status". Now it works.
Another riddle was: if you can have work trees inside the git dir, why
are some programs complaining that they need a work tree?
IOW it is allowed to call
$ git --git-dir=../ --work-tree=. bla
when you really want to. In this case, you are both in the git directory
and in the working tree. So, programs have to actually test for the right
thing, namely if they are inside a working tree, and not if they are
inside a git directory.
Also, GIT_DIR=../.git should behave the same as if no GIT_DIR was
specified, unless there is a repository in the current working directory.
It does now.
The logic to determine if a repository is bare, or has a work tree
(tertium non datur), is this:
--work-tree=bla overrides GIT_WORK_TREE, which overrides core.bare = true,
which overrides core.worktree, which overrides GIT_DIR/.. when GIT_DIR
ends in /.git, which overrides the directory in which .git/ was found.
In related news, a long standing bug was fixed: when in .git/bla/x.git/,
which is a bare repository, git formerly assumed ../.. to be the
appropriate git dir. This problem was reported by Shawn Pearce to have
caused much pain, where a colleague mistakenly ran "git init" in "/" a
long time ago, and bare repositories just would not work.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-01 04:30:14 +04:00
|
|
|
const char *get_git_work_tree(void)
|
|
|
|
{
|
|
|
|
static int initialized = 0;
|
|
|
|
if (!initialized) {
|
|
|
|
work_tree = getenv(GIT_WORK_TREE_ENVIRONMENT);
|
|
|
|
/* core.bare = true overrides implicit and config work tree */
|
|
|
|
if (!work_tree && is_bare_repository_cfg < 1) {
|
|
|
|
work_tree = git_work_tree_cfg;
|
|
|
|
/* make_absolute_path also normalizes the path */
|
|
|
|
if (work_tree && !is_absolute_path(work_tree))
|
|
|
|
work_tree = xstrdup(make_absolute_path(git_path(work_tree)));
|
|
|
|
} else if (work_tree)
|
|
|
|
work_tree = xstrdup(make_absolute_path(work_tree));
|
|
|
|
initialized = 1;
|
|
|
|
if (work_tree)
|
|
|
|
is_bare_repository_cfg = 0;
|
|
|
|
}
|
|
|
|
return work_tree;
|
|
|
|
}
|
|
|
|
|
2005-10-12 05:47:34 +04:00
|
|
|
char *get_object_directory(void)
|
|
|
|
{
|
|
|
|
if (!git_object_dir)
|
|
|
|
setup_git_env();
|
|
|
|
return git_object_dir;
|
|
|
|
}
|
|
|
|
|
|
|
|
char *get_refs_directory(void)
|
|
|
|
{
|
|
|
|
if (!git_refs_dir)
|
|
|
|
setup_git_env();
|
|
|
|
return git_refs_dir;
|
|
|
|
}
|
|
|
|
|
|
|
|
char *get_index_file(void)
|
|
|
|
{
|
|
|
|
if (!git_index_file)
|
|
|
|
setup_git_env();
|
|
|
|
return git_index_file;
|
|
|
|
}
|
|
|
|
|
|
|
|
char *get_graft_file(void)
|
|
|
|
{
|
|
|
|
if (!git_graft_file)
|
|
|
|
setup_git_env();
|
|
|
|
return git_graft_file;
|
|
|
|
}
|
2007-08-01 04:29:38 +04:00
|
|
|
|
|
|
|
int set_git_dir(const char *path)
|
|
|
|
{
|
|
|
|
if (setenv(GIT_DIR_ENVIRONMENT, path, 1))
|
|
|
|
return error("Could not set GIT_DIR to '%s'", path);
|
|
|
|
setup_git_env();
|
|
|
|
return 0;
|
|
|
|
}
|