|
|
|
/*
|
|
|
|
* 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"
|
ref namespaces: infrastructure
Add support for dividing the refs of a single repository into multiple
namespaces, each of which can have its own branches, tags, and HEAD.
Git can expose each namespace as an independent repository to pull from
and push to, while sharing the object store, and exposing all the refs
to operations such as git-gc.
Storing multiple repositories as namespaces of a single repository
avoids storing duplicate copies of the same objects, such as when
storing multiple branches of the same source. The alternates mechanism
provides similar support for avoiding duplicates, but alternates do not
prevent duplication between new objects added to the repositories
without ongoing maintenance, while namespaces do.
To specify a namespace, set the GIT_NAMESPACE environment variable to
the namespace. For each ref namespace, git stores the corresponding
refs in a directory under refs/namespaces/. For example,
GIT_NAMESPACE=foo will store refs under refs/namespaces/foo/. You can
also specify namespaces via the --namespace option to git.
Note that namespaces which include a / will expand to a hierarchy of
namespaces; for example, GIT_NAMESPACE=foo/bar will store refs under
refs/namespaces/foo/refs/namespaces/bar/. This makes paths in
GIT_NAMESPACE behave hierarchically, so that cloning with
GIT_NAMESPACE=foo/bar produces the same result as cloning with
GIT_NAMESPACE=foo and cloning from that repo with GIT_NAMESPACE=bar. It
also avoids ambiguity with strange namespace paths such as
foo/refs/heads/, which could otherwise generate directory/file conflicts
within the refs directory.
Add the infrastructure for ref namespaces: handle the GIT_NAMESPACE
environment variable and --namespace option, and support iterating over
refs in a namespace.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
14 years ago
|
|
|
#include "refs.h"
|
|
|
|
#include "fmt-merge-msg.h"
|
|
|
|
|
|
|
|
int trust_executable_bit = 1;
|
|
|
|
int trust_ctime = 1;
|
|
|
|
int check_stat = 1;
|
|
|
|
int has_symlinks = 1;
|
|
|
|
int minimum_abbrev = 4, default_abbrev = 7;
|
|
|
|
int ignore_case;
|
|
|
|
int assume_unchanged;
|
|
|
|
int prefer_symlink_refs;
|
|
|
|
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>
18 years ago
|
|
|
int log_all_ref_updates = -1; /* unspecified */
|
|
|
|
int warn_ambiguous_refs = 1;
|
|
|
|
int repository_format_version;
|
|
|
|
const char *git_commit_encoding;
|
|
|
|
const char *git_log_output_encoding;
|
|
|
|
int shared_repository = PERM_UMASK;
|
|
|
|
const char *apply_default_whitespace;
|
|
|
|
const char *apply_default_ignorewhitespace;
|
|
|
|
const char *git_attributes_file;
|
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>
18 years ago
|
|
|
int zlib_compression_level = Z_BEST_SPEED;
|
|
|
|
int core_compression_level;
|
|
|
|
int core_compression_seen;
|
|
|
|
int fsync_object_files;
|
|
|
|
size_t packed_git_window_size = DEFAULT_PACKED_GIT_WINDOW_SIZE;
|
|
|
|
size_t packed_git_limit = DEFAULT_PACKED_GIT_LIMIT;
|
|
|
|
size_t delta_base_cache_limit = 16 * 1024 * 1024;
|
|
|
|
unsigned long big_file_threshold = 512 * 1024 * 1024;
|
|
|
|
const char *log_pack_access;
|
|
|
|
const char *pager_program;
|
|
|
|
int pager_use_color = 1;
|
|
|
|
const char *editor_program;
|
|
|
|
const char *askpass_program;
|
|
|
|
const char *excludes_file;
|
|
|
|
enum auto_crlf auto_crlf = AUTO_CRLF_FALSE;
|
|
|
|
int read_replace_refs = 1; /* NEEDSWORK: rename to use_replace_refs */
|
|
|
|
enum eol core_eol = EOL_UNSET;
|
safecrlf: Add mechanism to warn about irreversible crlf conversions
CRLF conversion bears a slight chance of corrupting data.
autocrlf=true will convert CRLF to LF during commit and LF to
CRLF during checkout. A file that contains a mixture of LF and
CRLF before the commit cannot be recreated by git. For text
files this is the right thing to do: it corrects line endings
such that we have only LF line endings in the repository.
But for binary files that are accidentally classified as text the
conversion can corrupt data.
If you recognize such corruption early you can easily fix it by
setting the conversion type explicitly in .gitattributes. Right
after committing you still have the original file in your work
tree and this file is not yet corrupted. You can explicitly tell
git that this file is binary and git will handle the file
appropriately.
Unfortunately, the desired effect of cleaning up text files with
mixed line endings and the undesired effect of corrupting binary
files cannot be distinguished. In both cases CRLFs are removed
in an irreversible way. For text files this is the right thing
to do because CRLFs are line endings, while for binary files
converting CRLFs corrupts data.
This patch adds a mechanism that can either warn the user about
an irreversible conversion or can even refuse to convert. The
mechanism is controlled by the variable core.safecrlf, with the
following values:
- false: disable safecrlf mechanism
- warn: warn about irreversible conversions
- true: refuse irreversible conversions
The default is to warn. Users are only affected by this default
if core.autocrlf is set. But the current default of git is to
leave core.autocrlf unset, so users will not see warnings unless
they deliberately chose to activate the autocrlf mechanism.
The safecrlf mechanism's details depend on the git command. The
general principles when safecrlf is active (not false) are:
- we warn/error out if files in the work tree can modified in an
irreversible way without giving the user a chance to backup the
original file.
- for read-only operations that do not modify files in the work tree
we do not not print annoying warnings.
There are exceptions. Even though...
- "git add" itself does not touch the files in the work tree, the
next checkout would, so the safety triggers;
- "git apply" to update a text file with a patch does touch the files
in the work tree, but the operation is about text files and CRLF
conversion is about fixing the line ending inconsistencies, so the
safety does not trigger;
- "git diff" itself does not touch the files in the work tree, it is
often run to inspect the changes you intend to next "git add". To
catch potential problems early, safety triggers.
The concept of a safety check was originally proposed in a similar
way by Linus Torvalds. Thanks to Dimitry Potapov for insisting
on getting the naked LF/autocrlf=true case right.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
17 years ago
|
|
|
enum safe_crlf safe_crlf = SAFE_CRLF_WARN;
|
|
|
|
unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;
|
|
|
|
enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;
|
|
|
|
enum rebase_setup_type autorebase = AUTOREBASE_NEVER;
|
push: Provide situational hints for non-fast-forward errors
Pushing a non-fast-forward update to a remote repository will result in
an error, but the hint text doesn't provide the correct resolution in
every case. Give better resolution advice in three push scenarios:
1) If you push your current branch and it triggers a non-fast-forward
error, you should merge remote changes with 'git pull' before pushing
again.
2) If you push to a shared repository others push to, and your local
tracking branches are not kept up to date, the 'matching refs' default
will generate non-fast-forward errors on outdated branches. If this is
your workflow, the 'matching refs' default is not for you. Consider
setting the 'push.default' configuration variable to 'current' or
'upstream' to ensure only your current branch is pushed.
3) If you explicitly specify a ref that is not your current branch or
push matching branches with ':', you will generate a non-fast-forward
error if any pushed branch tip is out of date. You should checkout the
offending branch and merge remote changes before pushing again.
Teach transport.c to recognize these scenarios and configure push.c
to hint for them. If 'git push's default behavior changes or we
discover more scenarios, extension is easy. Standardize on the
advice API and add three new advice variables, 'pushNonFFCurrent',
'pushNonFFDefault', and 'pushNonFFMatching'. Setting any of these
to 'false' will disable their affiliated advice. Setting
'pushNonFastForward' to false will disable all three, thus preserving the
config option for users who already set it, but guaranteeing new
users won't disable push advice accidentally.
Based-on-patch-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Christopher Tiwald <christiwald@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
13 years ago
|
|
|
enum push_default_type push_default = PUSH_DEFAULT_UNSPECIFIED;
|
|
|
|
#ifndef OBJECT_CREATION_MODE
|
|
|
|
#define OBJECT_CREATION_MODE OBJECT_CREATION_USES_HARDLINKS
|
|
|
|
#endif
|
|
|
|
enum object_creation_mode object_creation_mode = OBJECT_CREATION_MODE;
|
|
|
|
char *notes_ref_name;
|
|
|
|
int grafts_replace_parents = 1;
|
|
|
|
int core_apply_sparse_checkout;
|
|
|
|
int merge_log_config = -1;
|
git on Mac OS and precomposed unicode
Mac OS X mangles file names containing unicode on file systems HFS+,
VFAT or SAMBA. When a file using unicode code points outside ASCII
is created on a HFS+ drive, the file name is converted into
decomposed unicode and written to disk. No conversion is done if
the file name is already decomposed unicode.
Calling open("\xc3\x84", ...) with a precomposed "Ä" yields the same
result as open("\x41\xcc\x88",...) with a decomposed "Ä".
As a consequence, readdir() returns the file names in decomposed
unicode, even if the user expects precomposed unicode. Unlike on
HFS+, Mac OS X stores files on a VFAT drive (e.g. an USB drive) in
precomposed unicode, but readdir() still returns file names in
decomposed unicode. When a git repository is stored on a network
share using SAMBA, file names are send over the wire and written to
disk on the remote system in precomposed unicode, but Mac OS X
readdir() returns decomposed unicode to be compatible with its
behaviour on HFS+ and VFAT.
The unicode decomposition causes many problems:
- The names "git add" and other commands get from the end user may
often be precomposed form (the decomposed form is not easily input
from the keyboard), but when the commands read from the filesystem
to see what it is going to update the index with already is on the
filesystem, readdir() will give decomposed form, which is different.
- Similarly "git log", "git mv" and all other commands that need to
compare pathnames found on the command line (often but not always
precomposed form; a command line input resulting from globbing may
be in decomposed) with pathnames found in the tree objects (should
be precomposed form to be compatible with other systems and for
consistency in general).
- The same for names stored in the index, which should be
precomposed, that may need to be compared with the names read from
readdir().
NFS mounted from Linux is fully transparent and does not suffer from
the above.
As Mac OS X treats precomposed and decomposed file names as equal,
we can
- wrap readdir() on Mac OS X to return the precomposed form, and
- normalize decomposed form given from the command line also to the
precomposed form,
to ensure that all pathnames used in Git are always in the
precomposed form. This behaviour can be requested by setting
"core.precomposedunicode" configuration variable to true.
The code in compat/precomposed_utf8.c implements basically 4 new
functions: precomposed_utf8_opendir(), precomposed_utf8_readdir(),
precomposed_utf8_closedir() and precompose_argv(). The first three
are to wrap opendir(3), readdir(3), and closedir(3) functions.
The argv[] conversion allows to use the TAB filename completion done
by the shell on command line. It tolerates other tools which use
readdir() to feed decomposed file names into git.
When creating a new git repository with "git init" or "git clone",
"core.precomposedunicode" will be set "false".
The user needs to activate this feature manually. She typically
sets core.precomposedunicode to "true" on HFS and VFAT, or file
systems mounted via SAMBA.
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
13 years ago
|
|
|
int precomposed_unicode = -1; /* see probe_utf8_pathname_composition() */
|
|
|
|
struct startup_info *startup_info;
|
|
|
|
unsigned long pack_size_limit_cfg;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The character that begins a commented line in user-editable file
|
|
|
|
* that is subject to stripspace.
|
|
|
|
*/
|
|
|
|
char comment_line_char = '#';
|
|
|
|
|
|
|
|
/* Parallel index stat data preload? */
|
|
|
|
int core_preload_index = 0;
|
|
|
|
|
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>
18 years ago
|
|
|
/* This is set by setup_git_dir_gently() and/or git_default_config() */
|
|
|
|
char *git_work_tree_cfg;
|
|
|
|
static char *work_tree;
|
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>
18 years ago
|
|
|
|
ref namespaces: infrastructure
Add support for dividing the refs of a single repository into multiple
namespaces, each of which can have its own branches, tags, and HEAD.
Git can expose each namespace as an independent repository to pull from
and push to, while sharing the object store, and exposing all the refs
to operations such as git-gc.
Storing multiple repositories as namespaces of a single repository
avoids storing duplicate copies of the same objects, such as when
storing multiple branches of the same source. The alternates mechanism
provides similar support for avoiding duplicates, but alternates do not
prevent duplication between new objects added to the repositories
without ongoing maintenance, while namespaces do.
To specify a namespace, set the GIT_NAMESPACE environment variable to
the namespace. For each ref namespace, git stores the corresponding
refs in a directory under refs/namespaces/. For example,
GIT_NAMESPACE=foo will store refs under refs/namespaces/foo/. You can
also specify namespaces via the --namespace option to git.
Note that namespaces which include a / will expand to a hierarchy of
namespaces; for example, GIT_NAMESPACE=foo/bar will store refs under
refs/namespaces/foo/refs/namespaces/bar/. This makes paths in
GIT_NAMESPACE behave hierarchically, so that cloning with
GIT_NAMESPACE=foo/bar produces the same result as cloning with
GIT_NAMESPACE=foo and cloning from that repo with GIT_NAMESPACE=bar. It
also avoids ambiguity with strange namespace paths such as
foo/refs/heads/, which could otherwise generate directory/file conflicts
within the refs directory.
Add the infrastructure for ref namespaces: handle the GIT_NAMESPACE
environment variable and --namespace option, and support iterating over
refs in a namespace.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
14 years ago
|
|
|
static const char *namespace;
|
|
|
|
static size_t namespace_len;
|
|
|
|
|
|
|
|
static const char *git_dir;
|
|
|
|
static char *git_object_dir, *git_index_file, *git_graft_file;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Repository-local GIT_* environment variables
|
|
|
|
* Remember to update local_repo_env_size in cache.h when
|
|
|
|
* the size of the list changes
|
|
|
|
*/
|
|
|
|
const char * const local_repo_env[LOCAL_REPO_ENV_SIZE + 1] = {
|
|
|
|
ALTERNATE_DB_ENVIRONMENT,
|
|
|
|
CONFIG_ENVIRONMENT,
|
|
|
|
CONFIG_DATA_ENVIRONMENT,
|
|
|
|
DB_ENVIRONMENT,
|
|
|
|
GIT_DIR_ENVIRONMENT,
|
|
|
|
GIT_WORK_TREE_ENVIRONMENT,
|
|
|
|
GRAFT_ENVIRONMENT,
|
|
|
|
INDEX_ENVIRONMENT,
|
|
|
|
NO_REPLACE_OBJECTS_ENVIRONMENT,
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
ref namespaces: infrastructure
Add support for dividing the refs of a single repository into multiple
namespaces, each of which can have its own branches, tags, and HEAD.
Git can expose each namespace as an independent repository to pull from
and push to, while sharing the object store, and exposing all the refs
to operations such as git-gc.
Storing multiple repositories as namespaces of a single repository
avoids storing duplicate copies of the same objects, such as when
storing multiple branches of the same source. The alternates mechanism
provides similar support for avoiding duplicates, but alternates do not
prevent duplication between new objects added to the repositories
without ongoing maintenance, while namespaces do.
To specify a namespace, set the GIT_NAMESPACE environment variable to
the namespace. For each ref namespace, git stores the corresponding
refs in a directory under refs/namespaces/. For example,
GIT_NAMESPACE=foo will store refs under refs/namespaces/foo/. You can
also specify namespaces via the --namespace option to git.
Note that namespaces which include a / will expand to a hierarchy of
namespaces; for example, GIT_NAMESPACE=foo/bar will store refs under
refs/namespaces/foo/refs/namespaces/bar/. This makes paths in
GIT_NAMESPACE behave hierarchically, so that cloning with
GIT_NAMESPACE=foo/bar produces the same result as cloning with
GIT_NAMESPACE=foo and cloning from that repo with GIT_NAMESPACE=bar. It
also avoids ambiguity with strange namespace paths such as
foo/refs/heads/, which could otherwise generate directory/file conflicts
within the refs directory.
Add the infrastructure for ref namespaces: handle the GIT_NAMESPACE
environment variable and --namespace option, and support iterating over
refs in a namespace.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
14 years ago
|
|
|
static char *expand_namespace(const char *raw_namespace)
|
|
|
|
{
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
struct strbuf **components, **c;
|
|
|
|
|
|
|
|
if (!raw_namespace || !*raw_namespace)
|
|
|
|
return xstrdup("");
|
|
|
|
|
|
|
|
strbuf_addstr(&buf, raw_namespace);
|
|
|
|
components = strbuf_split(&buf, '/');
|
|
|
|
strbuf_reset(&buf);
|
|
|
|
for (c = components; *c; c++)
|
|
|
|
if (strcmp((*c)->buf, "/") != 0)
|
|
|
|
strbuf_addf(&buf, "refs/namespaces/%s", (*c)->buf);
|
|
|
|
strbuf_list_free(components);
|
|
|
|
if (check_refname_format(buf.buf, 0))
|
ref namespaces: infrastructure
Add support for dividing the refs of a single repository into multiple
namespaces, each of which can have its own branches, tags, and HEAD.
Git can expose each namespace as an independent repository to pull from
and push to, while sharing the object store, and exposing all the refs
to operations such as git-gc.
Storing multiple repositories as namespaces of a single repository
avoids storing duplicate copies of the same objects, such as when
storing multiple branches of the same source. The alternates mechanism
provides similar support for avoiding duplicates, but alternates do not
prevent duplication between new objects added to the repositories
without ongoing maintenance, while namespaces do.
To specify a namespace, set the GIT_NAMESPACE environment variable to
the namespace. For each ref namespace, git stores the corresponding
refs in a directory under refs/namespaces/. For example,
GIT_NAMESPACE=foo will store refs under refs/namespaces/foo/. You can
also specify namespaces via the --namespace option to git.
Note that namespaces which include a / will expand to a hierarchy of
namespaces; for example, GIT_NAMESPACE=foo/bar will store refs under
refs/namespaces/foo/refs/namespaces/bar/. This makes paths in
GIT_NAMESPACE behave hierarchically, so that cloning with
GIT_NAMESPACE=foo/bar produces the same result as cloning with
GIT_NAMESPACE=foo and cloning from that repo with GIT_NAMESPACE=bar. It
also avoids ambiguity with strange namespace paths such as
foo/refs/heads/, which could otherwise generate directory/file conflicts
within the refs directory.
Add the infrastructure for ref namespaces: handle the GIT_NAMESPACE
environment variable and --namespace option, and support iterating over
refs in a namespace.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
14 years ago
|
|
|
die("bad git namespace path \"%s\"", raw_namespace);
|
|
|
|
strbuf_addch(&buf, '/');
|
|
|
|
return strbuf_detach(&buf, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void setup_git_env(void)
|
|
|
|
{
|
|
|
|
git_dir = getenv(GIT_DIR_ENVIRONMENT);
|
setup: make sure git_dir path is in a permanent buffer, getenv(3) case
getenv(3) returns not-permanent buffer which may be changed by e.g.
putenv(3) call (*).
In practice I've noticed this when trying to do `git commit -m abc`
inside msysgit under wine, getting
$ git commit -m abc
fatal: could not open 'DIR=.git/COMMIT_EDITMSG': No such file or directory
^^^^
(notice introduced 'DIR=' artifact.)
The problem was showing itself only with -m option, and actually, as
debugging showed, originally
git_dir = getenv("GIT_DIR")
returned pointer to
"GIT_DIR=.git\0"
^
git_dir
, we stored it in git_dir, than, after processing -m git-commit option,
we did setenv("GIT_EDITOR", ":") which as (*) says changed environment
variables memory layout - something like this
"...\0GIT_DIR=.git\0"
^
git_dir
and oops - we got wrong git_dir.
Avoid that by strdupping getenv("GIT_DIR") result like we did in 06f354
(setup: make sure git dir path is in a permanent buffer). Unfortunately
this also shows that other getenv usage inside git needs auditing...
(*) from man 3 getenv:
The implementation of getenv() is not required to be reentrant. The
string pointed to by the return value of getenv() may be statically
allocated, and can be modified by a subsequent call to getenv(),
putenv(3), setenv(3), or unsetenv(3).
Cc: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
14 years ago
|
|
|
git_dir = git_dir ? xstrdup(git_dir) : NULL;
|
|
|
|
if (!git_dir) {
|
|
|
|
git_dir = read_gitfile(DEFAULT_GIT_DIR_ENVIRONMENT);
|
|
|
|
git_dir = git_dir ? xstrdup(git_dir) : NULL;
|
|
|
|
}
|
|
|
|
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_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)
|
|
|
|
git_graft_file = git_pathdup("info/grafts");
|
|
|
|
if (getenv(NO_REPLACE_OBJECTS_ENVIRONMENT))
|
|
|
|
read_replace_refs = 0;
|
ref namespaces: infrastructure
Add support for dividing the refs of a single repository into multiple
namespaces, each of which can have its own branches, tags, and HEAD.
Git can expose each namespace as an independent repository to pull from
and push to, while sharing the object store, and exposing all the refs
to operations such as git-gc.
Storing multiple repositories as namespaces of a single repository
avoids storing duplicate copies of the same objects, such as when
storing multiple branches of the same source. The alternates mechanism
provides similar support for avoiding duplicates, but alternates do not
prevent duplication between new objects added to the repositories
without ongoing maintenance, while namespaces do.
To specify a namespace, set the GIT_NAMESPACE environment variable to
the namespace. For each ref namespace, git stores the corresponding
refs in a directory under refs/namespaces/. For example,
GIT_NAMESPACE=foo will store refs under refs/namespaces/foo/. You can
also specify namespaces via the --namespace option to git.
Note that namespaces which include a / will expand to a hierarchy of
namespaces; for example, GIT_NAMESPACE=foo/bar will store refs under
refs/namespaces/foo/refs/namespaces/bar/. This makes paths in
GIT_NAMESPACE behave hierarchically, so that cloning with
GIT_NAMESPACE=foo/bar produces the same result as cloning with
GIT_NAMESPACE=foo and cloning from that repo with GIT_NAMESPACE=bar. It
also avoids ambiguity with strange namespace paths such as
foo/refs/heads/, which could otherwise generate directory/file conflicts
within the refs directory.
Add the infrastructure for ref namespaces: handle the GIT_NAMESPACE
environment variable and --namespace option, and support iterating over
refs in a namespace.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
14 years ago
|
|
|
namespace = expand_namespace(getenv(GIT_NAMESPACE_ENVIRONMENT));
|
|
|
|
namespace_len = strlen(namespace);
|
|
|
|
}
|
|
|
|
|
|
|
|
int is_bare_repository(void)
|
|
|
|
{
|
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>
18 years ago
|
|
|
/* if core.bare is not 'false', let's see if there is a work tree */
|
|
|
|
return is_bare_repository_cfg && !get_git_work_tree();
|
|
|
|
}
|
|
|
|
|
|
|
|
int have_git_dir(void)
|
|
|
|
{
|
|
|
|
return !!git_dir;
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *get_git_dir(void)
|
|
|
|
{
|
|
|
|
if (!git_dir)
|
|
|
|
setup_git_env();
|
|
|
|
return git_dir;
|
|
|
|
}
|
|
|
|
|
ref namespaces: infrastructure
Add support for dividing the refs of a single repository into multiple
namespaces, each of which can have its own branches, tags, and HEAD.
Git can expose each namespace as an independent repository to pull from
and push to, while sharing the object store, and exposing all the refs
to operations such as git-gc.
Storing multiple repositories as namespaces of a single repository
avoids storing duplicate copies of the same objects, such as when
storing multiple branches of the same source. The alternates mechanism
provides similar support for avoiding duplicates, but alternates do not
prevent duplication between new objects added to the repositories
without ongoing maintenance, while namespaces do.
To specify a namespace, set the GIT_NAMESPACE environment variable to
the namespace. For each ref namespace, git stores the corresponding
refs in a directory under refs/namespaces/. For example,
GIT_NAMESPACE=foo will store refs under refs/namespaces/foo/. You can
also specify namespaces via the --namespace option to git.
Note that namespaces which include a / will expand to a hierarchy of
namespaces; for example, GIT_NAMESPACE=foo/bar will store refs under
refs/namespaces/foo/refs/namespaces/bar/. This makes paths in
GIT_NAMESPACE behave hierarchically, so that cloning with
GIT_NAMESPACE=foo/bar produces the same result as cloning with
GIT_NAMESPACE=foo and cloning from that repo with GIT_NAMESPACE=bar. It
also avoids ambiguity with strange namespace paths such as
foo/refs/heads/, which could otherwise generate directory/file conflicts
within the refs directory.
Add the infrastructure for ref namespaces: handle the GIT_NAMESPACE
environment variable and --namespace option, and support iterating over
refs in a namespace.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
14 years ago
|
|
|
const char *get_git_namespace(void)
|
|
|
|
{
|
|
|
|
if (!namespace)
|
|
|
|
setup_git_env();
|
|
|
|
return namespace;
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *strip_namespace(const char *namespaced_ref)
|
|
|
|
{
|
|
|
|
if (prefixcmp(namespaced_ref, get_git_namespace()) != 0)
|
|
|
|
return NULL;
|
|
|
|
return namespaced_ref + namespace_len;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int git_work_tree_initialized;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Note. This works only before you used a work tree. This was added
|
|
|
|
* primarily to support git-clone to work in a new repository it just
|
|
|
|
* created, and is not meant to flip between different work trees.
|
|
|
|
*/
|
|
|
|
void set_git_work_tree(const char *new_work_tree)
|
|
|
|
{
|
|
|
|
if (git_work_tree_initialized) {
|
|
|
|
new_work_tree = real_path(new_work_tree);
|
|
|
|
if (strcmp(new_work_tree, work_tree))
|
|
|
|
die("internal error: work tree has already been set\n"
|
|
|
|
"Current worktree: %s\nNew worktree: %s",
|
|
|
|
work_tree, new_work_tree);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
git_work_tree_initialized = 1;
|
|
|
|
work_tree = xstrdup(real_path(new_work_tree));
|
|
|
|
}
|
|
|
|
|
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>
18 years ago
|
|
|
const char *get_git_work_tree(void)
|
|
|
|
{
|
|
|
|
return work_tree;
|
|
|
|
}
|
|
|
|
|
|
|
|
char *get_object_directory(void)
|
|
|
|
{
|
|
|
|
if (!git_object_dir)
|
|
|
|
setup_git_env();
|
|
|
|
return git_object_dir;
|
|
|
|
}
|
|
|
|
|
|
|
|
int odb_mkstemp(char *template, size_t limit, const char *pattern)
|
|
|
|
{
|
|
|
|
int fd;
|
|
|
|
/*
|
|
|
|
* we let the umask do its job, don't try to be more
|
|
|
|
* restrictive except to remove write permission.
|
|
|
|
*/
|
|
|
|
int mode = 0444;
|
|
|
|
snprintf(template, limit, "%s/%s",
|
|
|
|
get_object_directory(), pattern);
|
|
|
|
fd = git_mkstemp_mode(template, mode);
|
|
|
|
if (0 <= fd)
|
|
|
|
return fd;
|
|
|
|
|
|
|
|
/* slow path */
|
|
|
|
/* some mkstemp implementations erase template on failure */
|
|
|
|
snprintf(template, limit, "%s/%s",
|
|
|
|
get_object_directory(), pattern);
|
|
|
|
safe_create_leading_directories(template);
|
|
|
|
return xmkstemp_mode(template, mode);
|
|
|
|
}
|
|
|
|
|
|
|
|
int odb_pack_keep(char *name, size_t namesz, unsigned char *sha1)
|
|
|
|
{
|
|
|
|
int fd;
|
|
|
|
|
|
|
|
snprintf(name, namesz, "%s/pack/pack-%s.keep",
|
|
|
|
get_object_directory(), sha1_to_hex(sha1));
|
|
|
|
fd = open(name, O_RDWR|O_CREAT|O_EXCL, 0600);
|
|
|
|
if (0 <= fd)
|
|
|
|
return fd;
|
|
|
|
|
|
|
|
/* slow path */
|
|
|
|
safe_create_leading_directories(name);
|
|
|
|
return open(name, O_RDWR|O_CREAT|O_EXCL, 0600);
|
|
|
|
}
|
|
|
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *get_log_output_encoding(void)
|
|
|
|
{
|
|
|
|
return git_log_output_encoding ? git_log_output_encoding
|
|
|
|
: get_commit_output_encoding();
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *get_commit_output_encoding(void)
|
|
|
|
{
|
|
|
|
return git_commit_encoding ? git_commit_encoding : "UTF-8";
|
|
|
|
}
|