2005-10-12 01:47:34 +00: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"
|
2017-06-22 18:43:33 +00:00
|
|
|
#include "repository.h"
|
2017-06-14 18:07:36 +00:00
|
|
|
#include "config.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>
2011-07-05 17:54:44 +00:00
|
|
|
#include "refs.h"
|
2011-10-09 17:33:34 +00:00
|
|
|
#include "fmt-merge-msg.h"
|
2013-12-05 13:02:45 +00:00
|
|
|
#include "commit.h"
|
2005-10-12 01:47:34 +00:00
|
|
|
|
|
|
|
int trust_executable_bit = 1;
|
2008-07-28 06:31:28 +00:00
|
|
|
int trust_ctime = 1;
|
2013-01-22 07:49:22 +00:00
|
|
|
int check_stat = 1;
|
2007-03-02 21:11:30 +00:00
|
|
|
int has_symlinks = 1;
|
2016-10-01 00:19:37 +00:00
|
|
|
int minimum_abbrev = 4, default_abbrev = -1;
|
2008-03-21 23:52:46 +00:00
|
|
|
int ignore_case;
|
2006-08-15 17:23:48 +00:00
|
|
|
int assume_unchanged;
|
|
|
|
int prefer_symlink_refs;
|
2007-01-07 10:00:28 +00:00
|
|
|
int is_bare_repository_cfg = -1; /* unspecified */
|
2006-03-24 07:42:40 +00:00
|
|
|
int warn_ambiguous_refs = 1;
|
cat-file: disable object/refname ambiguity check for batch mode
A common use of "cat-file --batch-check" is to feed a list
of objects from "rev-list --objects" or a similar command.
In this instance, all of our input objects are 40-byte sha1
ids. However, cat-file has always allowed arbitrary revision
specifiers, and feeds the result to get_sha1().
Fortunately, get_sha1() recognizes a 40-byte sha1 before
doing any hard work trying to look up refs, meaning this
scenario should end up spending very little time converting
the input into an object sha1. However, since 798c35f
(get_sha1: warn about full or short object names that look
like refs, 2013-05-29), when we encounter this case, we
spend the extra effort to do a refname lookup anyway, just
to print a warning. This is further exacerbated by ca91993
(get_packed_ref_cache: reload packed-refs file when it
changes, 2013-06-20), which makes individual ref lookup more
expensive by requiring a stat() of the packed-refs file for
each missing ref.
With no patches, this is the time it takes to run:
$ git rev-list --objects --all >objects
$ time git cat-file --batch-check='%(objectname)' <objects
on the linux.git repository:
real 1m13.494s
user 0m25.924s
sys 0m47.532s
If we revert ca91993, the packed-refs up-to-date check, it
gets a little better:
real 0m54.697s
user 0m21.692s
sys 0m32.916s
but we are still spending quite a bit of time on ref lookup
(and we would not want to revert that patch, anyway, which
has correctness issues). If we revert 798c35f, disabling
the warning entirely, we get a much more reasonable time:
real 0m7.452s
user 0m6.836s
sys 0m0.608s
This patch does the moral equivalent of this final case (and
gets similar speedups). We introduce a global flag that
callers of get_sha1() can use to avoid paying the price for
the warning.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-12 06:20:05 +00:00
|
|
|
int warn_on_object_refname_ambiguity = 1;
|
2015-03-20 18:43:06 +00:00
|
|
|
int ref_paranoia = -1;
|
2015-06-23 10:54:11 +00:00
|
|
|
int repository_format_precious_objects;
|
2017-12-05 16:58:43 +00:00
|
|
|
char *repository_format_partial_clone;
|
2007-03-12 19:33:18 +00:00
|
|
|
const char *git_commit_encoding;
|
2007-03-07 01:44:17 +00:00
|
|
|
const char *git_log_output_encoding;
|
2006-08-15 17:23:48 +00:00
|
|
|
const char *apply_default_whitespace;
|
2009-08-04 11:16:49 +00:00
|
|
|
const char *apply_default_ignorewhitespace;
|
2011-10-06 18:22:24 +00:00
|
|
|
const char *git_attributes_file;
|
2016-05-04 22:58:12 +00:00
|
|
|
const char *git_hooks_path;
|
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-09 20:56:50 +00:00
|
|
|
int zlib_compression_level = Z_BEST_SPEED;
|
|
|
|
int core_compression_level;
|
2016-11-16 01:42:40 +00:00
|
|
|
int pack_compression_level = Z_DEFAULT_COMPRESSION;
|
2008-06-18 22:18:44 +00:00
|
|
|
int fsync_object_files;
|
2006-12-24 05:46:13 +00:00
|
|
|
size_t packed_git_window_size = DEFAULT_PACKED_GIT_WINDOW_SIZE;
|
|
|
|
size_t packed_git_limit = DEFAULT_PACKED_GIT_LIMIT;
|
2014-05-04 17:13:57 +00:00
|
|
|
size_t delta_base_cache_limit = 96 * 1024 * 1024;
|
2011-04-05 17:44:11 +00:00
|
|
|
unsigned long big_file_threshold = 512 * 1024 * 1024;
|
2006-07-29 22:27:43 +00:00
|
|
|
int pager_use_color = 1;
|
2008-02-16 05:01:41 +00:00
|
|
|
const char *editor_program;
|
2010-08-30 13:38:38 +00:00
|
|
|
const char *askpass_program;
|
2008-02-16 05:01:59 +00:00
|
|
|
const char *excludes_file;
|
2010-05-19 20:43:10 +00:00
|
|
|
enum auto_crlf auto_crlf = AUTO_CRLF_FALSE;
|
2014-02-18 11:24:55 +00:00
|
|
|
int check_replace_refs = 1;
|
2015-06-11 21:34:59 +00:00
|
|
|
char *git_replace_ref_base;
|
2011-05-09 19:52:12 +00:00
|
|
|
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>
2008-02-06 11:25:58 +00:00
|
|
|
enum safe_crlf safe_crlf = SAFE_CRLF_WARN;
|
2007-12-06 08:14:14 +00:00
|
|
|
unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;
|
2008-02-19 16:24:37 +00:00
|
|
|
enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;
|
2008-05-10 22:36:29 +00:00
|
|
|
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>
2012-03-20 04:31:33 +00:00
|
|
|
enum push_default_type push_default = PUSH_DEFAULT_UNSPECIFIED;
|
2009-04-27 22:32:25 +00:00
|
|
|
#ifndef OBJECT_CREATION_MODE
|
|
|
|
#define OBJECT_CREATION_MODE OBJECT_CREATION_USES_HARDLINKS
|
2009-04-25 09:57:14 +00:00
|
|
|
#endif
|
2009-04-27 22:32:25 +00:00
|
|
|
enum object_creation_mode object_creation_mode = OBJECT_CREATION_MODE;
|
2009-10-09 10:21:57 +00:00
|
|
|
char *notes_ref_name;
|
2009-07-23 15:33:49 +00:00
|
|
|
int grafts_replace_parents = 1;
|
2009-08-20 13:47:08 +00:00
|
|
|
int core_apply_sparse_checkout;
|
2011-10-07 06:12:09 +00:00
|
|
|
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>
2012-07-08 13:50:25 +00:00
|
|
|
int precomposed_unicode = -1; /* see probe_utf8_pathname_composition() */
|
2011-10-28 21:48:40 +00:00
|
|
|
unsigned long pack_size_limit_cfg;
|
mingw: introduce the 'core.hideDotFiles' setting
On Unix (and Linux), files and directories whose names start with a dot
are usually not shown by default. This convention is used by Git: the
.git/ directory should be left alone by regular users, and only accessed
through Git itself.
On Windows, no such convention exists. Instead, there is an explicit flag
to mark files or directories as hidden.
In the early days, Git for Windows did not mark the .git/ directory (or
for that matter, any file or directory whose name starts with a dot)
hidden. This lead to quite a bit of confusion, and even loss of data.
Consequently, Git for Windows introduced the core.hideDotFiles setting,
with three possible values: true, false, and dotGitOnly, defaulting to
marking only the .git/ directory as hidden.
The rationale: users do not need to access .git/ directly, and indeed (as
was demonstrated) should not really see that directory, either. However,
not all dot files should be hidden by default, as e.g. Eclipse does not
show them (and the user would therefore be unable to see, say, a
.gitattributes file).
In over five years since the last attempt to bring this patch into core
Git, a slightly buggy version of this patch has served Git for Windows'
users well: no single report indicated problems with the hidden .git/
directory, and the stream of problems caused by the previously non-hidden
.git/ directory simply stopped. The bugs have been fixed during the
process of getting this patch upstream.
Note that there is a funny quirk we have to pay attention to when
creating hidden files: we use Win32's _wopen() function which
transmogrifies its arguments and hands off to Win32's CreateFile()
function. That latter function errors out with ERROR_ACCESS_DENIED (the
equivalent of EACCES) when the equivalent of the O_CREAT flag was passed
and the file attributes (including the hidden flag) do not match an
existing file's. And _wopen() accepts no parameter that would be
transmogrified into said hidden flag. Therefore, we simply try again
without O_CREAT.
A slightly different method is required for our fopen()/freopen()
function as we cannot even *remove* the implicit O_CREAT flag.
Therefore, we briefly mark existing files as unhidden when opening them
via fopen()/freopen().
The ERROR_ACCESS_DENIED error can also be triggered by opening a file
that is marked as a system file (which is unlikely to be tracked in
Git), and by trying to create a file that has *just* been deleted and is
awaiting the last open handles to be released (which would be handled
better by the "Try again?" logic, a story for a different patch series,
though). In both cases, it does not matter much if we try again without
the O_CREAT flag, read: it does not hurt, either.
For details how ERROR_ACCESS_DENIED can be triggered, see
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858
Original-patch-by: Erik Faye-Lund <kusmabite@gmail.com>
Initial-Test-By: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-11 08:43:37 +00:00
|
|
|
enum hide_dotfiles_type hide_dotfiles = HIDE_DOTFILES_DOTGITONLY;
|
2017-01-27 10:09:47 +00:00
|
|
|
enum log_refs_config log_all_ref_updates = LOG_REFS_UNSET;
|
2005-10-12 01:47:34 +00:00
|
|
|
|
2014-12-15 23:15:20 +00:00
|
|
|
#ifndef PROTECT_HFS_DEFAULT
|
|
|
|
#define PROTECT_HFS_DEFAULT 0
|
|
|
|
#endif
|
|
|
|
int protect_hfs = PROTECT_HFS_DEFAULT;
|
|
|
|
|
2014-12-16 22:46:59 +00:00
|
|
|
#ifndef PROTECT_NTFS_DEFAULT
|
|
|
|
#define PROTECT_NTFS_DEFAULT 0
|
|
|
|
#endif
|
|
|
|
int protect_ntfs = PROTECT_NTFS_DEFAULT;
|
|
|
|
|
2013-01-16 19:18:48 +00:00
|
|
|
/*
|
|
|
|
* The character that begins a commented line in user-editable file
|
|
|
|
* that is subject to stripspace.
|
|
|
|
*/
|
|
|
|
char comment_line_char = '#';
|
2014-05-17 01:52:23 +00:00
|
|
|
int auto_comment_line_char;
|
2013-01-16 19:18:48 +00:00
|
|
|
|
2008-11-14 00:36:30 +00:00
|
|
|
/* Parallel index stat data preload? */
|
2014-06-02 16:43:00 +00:00
|
|
|
int core_preload_index = 1;
|
2008-11-14 00:36:30 +00:00
|
|
|
|
2016-01-27 06:58:06 +00:00
|
|
|
/*
|
|
|
|
* This is a hack for test programs like test-dump-untracked-cache to
|
|
|
|
* ensure that they do not modify the untracked cache when reading it.
|
|
|
|
* Do not use it otherwise!
|
|
|
|
*/
|
|
|
|
int ignore_untracked_cache_config;
|
|
|
|
|
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 00:30:14 +00:00
|
|
|
/* This is set by setup_git_dir_gently() and/or git_default_config() */
|
|
|
|
char *git_work_tree_cfg;
|
|
|
|
|
2017-09-05 13:04:57 +00:00
|
|
|
static char *namespace;
|
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>
2011-07-05 17:54:44 +00:00
|
|
|
|
2016-10-07 18:18:48 +00:00
|
|
|
static const char *super_prefix;
|
|
|
|
|
2010-02-24 23:34:14 +00:00
|
|
|
/*
|
2013-03-08 09:29:08 +00:00
|
|
|
* Repository-local GIT_* environment variables; see cache.h for details.
|
2010-02-24 23:34:14 +00:00
|
|
|
*/
|
2013-03-08 09:29:08 +00:00
|
|
|
const char * const local_repo_env[] = {
|
2010-02-24 23:34:14 +00:00
|
|
|
ALTERNATE_DB_ENVIRONMENT,
|
|
|
|
CONFIG_ENVIRONMENT,
|
2010-08-24 06:41:14 +00:00
|
|
|
CONFIG_DATA_ENVIRONMENT,
|
2010-02-24 23:34:14 +00:00
|
|
|
DB_ENVIRONMENT,
|
|
|
|
GIT_DIR_ENVIRONMENT,
|
|
|
|
GIT_WORK_TREE_ENVIRONMENT,
|
setup: suppress implicit "." work-tree for bare repos
If an explicit GIT_DIR is given without a working tree, we
implicitly assume that the current working directory should
be used as the working tree. E.g.,:
GIT_DIR=/some/repo.git git status
would compare against the cwd.
Unfortunately, we fool this rule for sub-invocations of git
by setting GIT_DIR internally ourselves. For example:
git init foo
cd foo/.git
git status ;# fails, as we expect
git config alias.st status
git status ;# does not fail, but should
What happens is that we run setup_git_directory when doing
alias lookup (since we need to see the config), set GIT_DIR
as a result, and then leave GIT_WORK_TREE blank (because we
do not have one). Then when we actually run the status
command, we do setup_git_directory again, which sees our
explicit GIT_DIR and uses the cwd as an implicit worktree.
It's tempting to argue that we should be suppressing that
second invocation of setup_git_directory, as it could use
the values we already found in memory. However, the problem
still exists for sub-processes (e.g., if "git status" were
an external command).
You can see another example with the "--bare" option, which
sets GIT_DIR explicitly. For example:
git init foo
cd foo/.git
git status ;# fails
git --bare status ;# does NOT fail
We need some way of telling sub-processes "even though
GIT_DIR is set, do not use cwd as an implicit working tree".
We could do it by putting a special token into
GIT_WORK_TREE, but the obvious choice (an empty string) has
some portability problems.
Instead, we add a new boolean variable, GIT_IMPLICIT_WORK_TREE,
which suppresses the use of cwd as a working tree when
GIT_DIR is set. We trigger the new variable when we know we
are in a bare setting.
The variable is left intentionally undocumented, as this is
an internal detail (for now, anyway). If somebody comes up
with a good alternate use for it, and once we are confident
we have shaken any bugs out of it, we can consider promoting
it further.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-08 09:32:22 +00:00
|
|
|
GIT_IMPLICIT_WORK_TREE_ENVIRONMENT,
|
2010-02-24 23:34:14 +00:00
|
|
|
GRAFT_ENVIRONMENT,
|
|
|
|
INDEX_ENVIRONMENT,
|
|
|
|
NO_REPLACE_OBJECTS_ENVIRONMENT,
|
2015-06-11 21:34:59 +00:00
|
|
|
GIT_REPLACE_REF_BASE_ENVIRONMENT,
|
2013-03-08 09:30:25 +00:00
|
|
|
GIT_PREFIX_ENVIRONMENT,
|
2016-10-07 18:18:48 +00:00
|
|
|
GIT_SUPER_PREFIX_ENVIRONMENT,
|
2013-12-05 13:02:45 +00:00
|
|
|
GIT_SHALLOW_FILE_ENVIRONMENT,
|
$GIT_COMMON_DIR: a new environment variable
This variable is intended to support multiple working directories
attached to a repository. Such a repository may have a main working
directory, created by either "git init" or "git clone" and one or more
linked working directories. These working directories and the main
repository share the same repository directory.
In linked working directories, $GIT_COMMON_DIR must be defined to point
to the real repository directory and $GIT_DIR points to an unused
subdirectory inside $GIT_COMMON_DIR. File locations inside the
repository are reorganized from the linked worktree view point:
- worktree-specific such as HEAD, logs/HEAD, index, other top-level
refs and unrecognized files are from $GIT_DIR.
- the rest like objects, refs, info, hooks, packed-refs, shallow...
are from $GIT_COMMON_DIR (except info/sparse-checkout, but that's
a separate patch)
Scripts are supposed to retrieve paths in $GIT_DIR with "git rev-parse
--git-path", which will take care of "$GIT_DIR vs $GIT_COMMON_DIR"
business.
The redirection is done by git_path(), git_pathdup() and
strbuf_git_path(). The selected list of paths goes to $GIT_COMMON_DIR,
not the other way around in case a developer adds a new
worktree-specific file and it's accidentally promoted to be shared
across repositories (this includes unknown files added by third party
commands)
The list of known files that belong to $GIT_DIR are:
ADD_EDIT.patch BISECT_ANCESTORS_OK BISECT_EXPECTED_REV BISECT_LOG
BISECT_NAMES CHERRY_PICK_HEAD COMMIT_MSG FETCH_HEAD HEAD MERGE_HEAD
MERGE_MODE MERGE_RR NOTES_EDITMSG NOTES_MERGE_WORKTREE ORIG_HEAD
REVERT_HEAD SQUASH_MSG TAG_EDITMSG fast_import_crash_* logs/HEAD
next-index-* rebase-apply rebase-merge rsync-refs-* sequencer/*
shallow_*
Path mapping is NOT done for git_path_submodule(). Multi-checkouts are
not supported as submodules.
Helped-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-30 08:24:36 +00:00
|
|
|
GIT_COMMON_DIR_ENVIRONMENT,
|
2010-02-24 23:34:14 +00:00
|
|
|
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>
2011-07-05 17:54:44 +00:00
|
|
|
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);
|
2011-09-15 21:10:25 +00:00
|
|
|
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>
2011-07-05 17:54:44 +00:00
|
|
|
die("bad git namespace path \"%s\"", raw_namespace);
|
|
|
|
strbuf_addch(&buf, '/');
|
|
|
|
return strbuf_detach(&buf, NULL);
|
|
|
|
}
|
|
|
|
|
2017-06-20 19:19:32 +00:00
|
|
|
void setup_git_env(void)
|
2005-10-12 01:47:34 +00:00
|
|
|
{
|
2013-12-05 13:02:45 +00:00
|
|
|
const char *shallow_file;
|
2015-06-11 21:34:59 +00:00
|
|
|
const char *replace_ref_base;
|
2013-08-31 01:04:14 +00:00
|
|
|
|
2009-11-18 06:50:58 +00:00
|
|
|
if (getenv(NO_REPLACE_OBJECTS_ENVIRONMENT))
|
2014-02-18 11:24:55 +00:00
|
|
|
check_replace_refs = 0;
|
2015-06-11 21:34:59 +00:00
|
|
|
replace_ref_base = getenv(GIT_REPLACE_REF_BASE_ENVIRONMENT);
|
2017-09-05 13:04:57 +00:00
|
|
|
free(git_replace_ref_base);
|
2015-06-11 21:34:59 +00:00
|
|
|
git_replace_ref_base = xstrdup(replace_ref_base ? replace_ref_base
|
|
|
|
: "refs/replace/");
|
2017-09-05 13:04:57 +00:00
|
|
|
free(namespace);
|
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>
2011-07-05 17:54:44 +00:00
|
|
|
namespace = expand_namespace(getenv(GIT_NAMESPACE_ENVIRONMENT));
|
2013-12-05 13:02:45 +00:00
|
|
|
shallow_file = getenv(GIT_SHALLOW_FILE_ENVIRONMENT);
|
|
|
|
if (shallow_file)
|
|
|
|
set_alternate_shallow_file(shallow_file, 0);
|
2006-12-14 22:41:17 +00:00
|
|
|
}
|
|
|
|
|
2007-01-07 10:00:28 +00:00
|
|
|
int is_bare_repository(void)
|
2006-12-14 22:41:17 +00: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 00:30:14 +00: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 01:47:34 +00:00
|
|
|
}
|
|
|
|
|
config: only read .git/config from configured repos
When git_config() runs, it looks in the system, user-wide,
and repo-level config files. It gets the latter by calling
git_pathdup(), which in turn calls get_git_dir(). If we
haven't set up the git repository yet, this may simply
return ".git", and we will look at ".git/config". This
seems like it would be helpful (presumably we haven't set up
the repository yet, so it tries to find it), but it turns
out to be a bad idea for a few reasons:
- it's not sufficient, and therefore hides bugs in a
confusing way. Config will be respected if commands are
run from the top-level of the working tree, but not from
a subdirectory.
- it's not always true that we haven't set up the
repository _yet_; we may not want to do it at all. For
instance, if you run "git init /some/path" from inside
another repository, it should not load config from the
existing repository.
- there might be a path ".git/config", but it is not the
actual repository we would find via setup_git_directory().
This may happen, e.g., if you are storing a git
repository inside another git repository, but have
munged one of the files in such a way that the
inner repository is not valid (e.g., by removing HEAD).
We have at least two bugs of the second type in git-init,
introduced by ae5f677 (lazily load core.sharedrepository,
2016-03-11). It causes init to use git_configset(), which
loads all of the config, including values from the current
repo (if any). This shows up in two ways:
1. If we happen to be in an existing repository directory,
we'll read and respect core.sharedrepository from it,
even though it should have no bearing on the new
repository. A new test in t1301 covers this.
2. Similarly, if we're in an existing repo that sets
core.logallrefupdates, that will cause init to fail to
set it in a newly created repository (because it thinks
that the user's templates already did so). A new test
in t0001 covers this.
We also need to adjust an existing test in t1302, which
gives another example of why this patch is an improvement.
That test creates an embedded repository with a bogus
core.repositoryformatversion of "99". It wants to make sure
that we actually stop at the bogus repo rather than
continuing upward to find the outer repo. So it checks that
"git config core.repositoryformatversion" returns 99. But
that only works because we blindly read ".git/config", even
though we _know_ we're in a repository whose vintage we do
not understand.
After this patch, we avoid reading config from the unknown
vintage repository at all, which is a safer choice. But we
need to tweak the test, since core.repositoryformatversion
will not return 99; it will claim that it could not find the
variable at all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-13 03:24:15 +00:00
|
|
|
int have_git_dir(void)
|
|
|
|
{
|
|
|
|
return startup_info->have_repository
|
2017-06-22 18:43:33 +00:00
|
|
|
|| the_repository->gitdir;
|
config: only read .git/config from configured repos
When git_config() runs, it looks in the system, user-wide,
and repo-level config files. It gets the latter by calling
git_pathdup(), which in turn calls get_git_dir(). If we
haven't set up the git repository yet, this may simply
return ".git", and we will look at ".git/config". This
seems like it would be helpful (presumably we haven't set up
the repository yet, so it tries to find it), but it turns
out to be a bad idea for a few reasons:
- it's not sufficient, and therefore hides bugs in a
confusing way. Config will be respected if commands are
run from the top-level of the working tree, but not from
a subdirectory.
- it's not always true that we haven't set up the
repository _yet_; we may not want to do it at all. For
instance, if you run "git init /some/path" from inside
another repository, it should not load config from the
existing repository.
- there might be a path ".git/config", but it is not the
actual repository we would find via setup_git_directory().
This may happen, e.g., if you are storing a git
repository inside another git repository, but have
munged one of the files in such a way that the
inner repository is not valid (e.g., by removing HEAD).
We have at least two bugs of the second type in git-init,
introduced by ae5f677 (lazily load core.sharedrepository,
2016-03-11). It causes init to use git_configset(), which
loads all of the config, including values from the current
repo (if any). This shows up in two ways:
1. If we happen to be in an existing repository directory,
we'll read and respect core.sharedrepository from it,
even though it should have no bearing on the new
repository. A new test in t1301 covers this.
2. Similarly, if we're in an existing repo that sets
core.logallrefupdates, that will cause init to fail to
set it in a newly created repository (because it thinks
that the user's templates already did so). A new test
in t0001 covers this.
We also need to adjust an existing test in t1302, which
gives another example of why this patch is an improvement.
That test creates an embedded repository with a bogus
core.repositoryformatversion of "99". It wants to make sure
that we actually stop at the bogus repo rather than
continuing upward to find the outer repo. So it checks that
"git config core.repositoryformatversion" returns 99. But
that only works because we blindly read ".git/config", even
though we _know_ we're in a repository whose vintage we do
not understand.
After this patch, we avoid reading config from the unknown
vintage repository at all, which is a safer choice. But we
need to tweak the test, since core.repositoryformatversion
will not return 99; it will claim that it could not find the
variable at all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-13 03:24:15 +00:00
|
|
|
}
|
|
|
|
|
2006-08-23 10:39:11 +00:00
|
|
|
const char *get_git_dir(void)
|
2005-10-12 01:47:34 +00:00
|
|
|
{
|
2017-06-22 18:43:33 +00:00
|
|
|
if (!the_repository->gitdir)
|
2017-06-20 19:19:32 +00:00
|
|
|
BUG("git environment hasn't been setup");
|
2017-06-22 18:43:33 +00:00
|
|
|
return the_repository->gitdir;
|
2005-10-12 01:47:34 +00:00
|
|
|
}
|
|
|
|
|
$GIT_COMMON_DIR: a new environment variable
This variable is intended to support multiple working directories
attached to a repository. Such a repository may have a main working
directory, created by either "git init" or "git clone" and one or more
linked working directories. These working directories and the main
repository share the same repository directory.
In linked working directories, $GIT_COMMON_DIR must be defined to point
to the real repository directory and $GIT_DIR points to an unused
subdirectory inside $GIT_COMMON_DIR. File locations inside the
repository are reorganized from the linked worktree view point:
- worktree-specific such as HEAD, logs/HEAD, index, other top-level
refs and unrecognized files are from $GIT_DIR.
- the rest like objects, refs, info, hooks, packed-refs, shallow...
are from $GIT_COMMON_DIR (except info/sparse-checkout, but that's
a separate patch)
Scripts are supposed to retrieve paths in $GIT_DIR with "git rev-parse
--git-path", which will take care of "$GIT_DIR vs $GIT_COMMON_DIR"
business.
The redirection is done by git_path(), git_pathdup() and
strbuf_git_path(). The selected list of paths goes to $GIT_COMMON_DIR,
not the other way around in case a developer adds a new
worktree-specific file and it's accidentally promoted to be shared
across repositories (this includes unknown files added by third party
commands)
The list of known files that belong to $GIT_DIR are:
ADD_EDIT.patch BISECT_ANCESTORS_OK BISECT_EXPECTED_REV BISECT_LOG
BISECT_NAMES CHERRY_PICK_HEAD COMMIT_MSG FETCH_HEAD HEAD MERGE_HEAD
MERGE_MODE MERGE_RR NOTES_EDITMSG NOTES_MERGE_WORKTREE ORIG_HEAD
REVERT_HEAD SQUASH_MSG TAG_EDITMSG fast_import_crash_* logs/HEAD
next-index-* rebase-apply rebase-merge rsync-refs-* sequencer/*
shallow_*
Path mapping is NOT done for git_path_submodule(). Multi-checkouts are
not supported as submodules.
Helped-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-30 08:24:36 +00:00
|
|
|
const char *get_git_common_dir(void)
|
|
|
|
{
|
2017-06-22 18:43:33 +00:00
|
|
|
if (!the_repository->commondir)
|
2017-06-20 19:19:32 +00:00
|
|
|
BUG("git environment hasn't been setup");
|
2017-06-22 18:43:33 +00:00
|
|
|
return the_repository->commondir;
|
$GIT_COMMON_DIR: a new environment variable
This variable is intended to support multiple working directories
attached to a repository. Such a repository may have a main working
directory, created by either "git init" or "git clone" and one or more
linked working directories. These working directories and the main
repository share the same repository directory.
In linked working directories, $GIT_COMMON_DIR must be defined to point
to the real repository directory and $GIT_DIR points to an unused
subdirectory inside $GIT_COMMON_DIR. File locations inside the
repository are reorganized from the linked worktree view point:
- worktree-specific such as HEAD, logs/HEAD, index, other top-level
refs and unrecognized files are from $GIT_DIR.
- the rest like objects, refs, info, hooks, packed-refs, shallow...
are from $GIT_COMMON_DIR (except info/sparse-checkout, but that's
a separate patch)
Scripts are supposed to retrieve paths in $GIT_DIR with "git rev-parse
--git-path", which will take care of "$GIT_DIR vs $GIT_COMMON_DIR"
business.
The redirection is done by git_path(), git_pathdup() and
strbuf_git_path(). The selected list of paths goes to $GIT_COMMON_DIR,
not the other way around in case a developer adds a new
worktree-specific file and it's accidentally promoted to be shared
across repositories (this includes unknown files added by third party
commands)
The list of known files that belong to $GIT_DIR are:
ADD_EDIT.patch BISECT_ANCESTORS_OK BISECT_EXPECTED_REV BISECT_LOG
BISECT_NAMES CHERRY_PICK_HEAD COMMIT_MSG FETCH_HEAD HEAD MERGE_HEAD
MERGE_MODE MERGE_RR NOTES_EDITMSG NOTES_MERGE_WORKTREE ORIG_HEAD
REVERT_HEAD SQUASH_MSG TAG_EDITMSG fast_import_crash_* logs/HEAD
next-index-* rebase-apply rebase-merge rsync-refs-* sequencer/*
shallow_*
Path mapping is NOT done for git_path_submodule(). Multi-checkouts are
not supported as submodules.
Helped-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-30 08:24:36 +00:00
|
|
|
}
|
|
|
|
|
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>
2011-07-05 17:54:44 +00:00
|
|
|
const char *get_git_namespace(void)
|
|
|
|
{
|
|
|
|
if (!namespace)
|
2017-06-20 19:19:32 +00:00
|
|
|
BUG("git environment hasn't been setup");
|
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>
2011-07-05 17:54:44 +00:00
|
|
|
return namespace;
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *strip_namespace(const char *namespaced_ref)
|
|
|
|
{
|
2017-06-20 19:19:34 +00:00
|
|
|
const char *out;
|
|
|
|
if (skip_prefix(namespaced_ref, get_git_namespace(), &out))
|
|
|
|
return out;
|
|
|
|
return 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>
2011-07-05 17:54:44 +00:00
|
|
|
}
|
|
|
|
|
2016-10-07 18:18:48 +00:00
|
|
|
const char *get_super_prefix(void)
|
|
|
|
{
|
|
|
|
static int initialized;
|
|
|
|
if (!initialized) {
|
|
|
|
super_prefix = getenv(GIT_SUPER_PREFIX_ENVIRONMENT);
|
|
|
|
initialized = 1;
|
|
|
|
}
|
|
|
|
return super_prefix;
|
|
|
|
}
|
|
|
|
|
2008-04-27 17:39:21 +00:00
|
|
|
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)
|
|
|
|
{
|
2010-11-26 15:32:40 +00:00
|
|
|
if (git_work_tree_initialized) {
|
2011-03-17 11:26:46 +00:00
|
|
|
new_work_tree = real_path(new_work_tree);
|
2017-06-22 18:43:34 +00:00
|
|
|
if (strcmp(new_work_tree, the_repository->worktree))
|
2010-11-26 15:32:40 +00:00
|
|
|
die("internal error: work tree has already been set\n"
|
|
|
|
"Current worktree: %s\nNew worktree: %s",
|
2017-06-22 18:43:34 +00:00
|
|
|
the_repository->worktree, new_work_tree);
|
2010-11-26 15:32:40 +00:00
|
|
|
return;
|
|
|
|
}
|
2008-04-27 17:39:21 +00:00
|
|
|
git_work_tree_initialized = 1;
|
2017-06-22 18:43:34 +00:00
|
|
|
repo_set_worktree(the_repository, new_work_tree);
|
2008-04-27 17:39:21 +00: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 00:30:14 +00:00
|
|
|
const char *get_git_work_tree(void)
|
|
|
|
{
|
2017-06-22 18:43:34 +00:00
|
|
|
return the_repository->worktree;
|
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 00:30:14 +00:00
|
|
|
}
|
|
|
|
|
2005-10-12 01:47:34 +00:00
|
|
|
char *get_object_directory(void)
|
|
|
|
{
|
2017-06-22 18:43:33 +00:00
|
|
|
if (!the_repository->objectdir)
|
2017-06-20 19:19:32 +00:00
|
|
|
BUG("git environment hasn't been setup");
|
2017-06-22 18:43:33 +00:00
|
|
|
return the_repository->objectdir;
|
2005-10-12 01:47:34 +00:00
|
|
|
}
|
|
|
|
|
2017-03-28 19:45:43 +00:00
|
|
|
int odb_mkstemp(struct strbuf *template, const char *pattern)
|
2010-11-06 11:45:38 +00:00
|
|
|
{
|
|
|
|
int fd;
|
|
|
|
/*
|
|
|
|
* we let the umask do its job, don't try to be more
|
|
|
|
* restrictive except to remove write permission.
|
|
|
|
*/
|
|
|
|
int mode = 0444;
|
2017-03-28 19:45:52 +00:00
|
|
|
git_path_buf(template, "objects/%s", pattern);
|
2017-03-28 19:45:43 +00:00
|
|
|
fd = git_mkstemp_mode(template->buf, mode);
|
2010-11-06 11:45:38 +00:00
|
|
|
if (0 <= fd)
|
|
|
|
return fd;
|
|
|
|
|
|
|
|
/* slow path */
|
|
|
|
/* some mkstemp implementations erase template on failure */
|
2017-03-28 19:45:52 +00:00
|
|
|
git_path_buf(template, "objects/%s", pattern);
|
2017-03-28 19:45:43 +00:00
|
|
|
safe_create_leading_directories(template->buf);
|
|
|
|
return xmkstemp_mode(template->buf, mode);
|
2010-11-06 11:45:38 +00:00
|
|
|
}
|
|
|
|
|
2017-03-16 14:27:12 +00:00
|
|
|
int odb_pack_keep(const char *name)
|
2010-11-06 11:45:38 +00:00
|
|
|
{
|
|
|
|
int fd;
|
|
|
|
|
|
|
|
fd = open(name, O_RDWR|O_CREAT|O_EXCL, 0600);
|
|
|
|
if (0 <= fd)
|
|
|
|
return fd;
|
|
|
|
|
|
|
|
/* slow path */
|
2017-03-16 14:27:12 +00:00
|
|
|
safe_create_leading_directories_const(name);
|
2010-11-06 11:45:38 +00:00
|
|
|
return open(name, O_RDWR|O_CREAT|O_EXCL, 0600);
|
|
|
|
}
|
|
|
|
|
2005-10-12 01:47:34 +00:00
|
|
|
char *get_index_file(void)
|
|
|
|
{
|
2017-06-22 18:43:33 +00:00
|
|
|
if (!the_repository->index_file)
|
2017-06-20 19:19:32 +00:00
|
|
|
BUG("git environment hasn't been setup");
|
2017-06-22 18:43:33 +00:00
|
|
|
return the_repository->index_file;
|
2005-10-12 01:47:34 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
char *get_graft_file(void)
|
|
|
|
{
|
2017-06-22 18:43:33 +00:00
|
|
|
if (!the_repository->graft_file)
|
2017-06-20 19:19:32 +00:00
|
|
|
BUG("git environment hasn't been setup");
|
2017-06-22 18:43:33 +00:00
|
|
|
return the_repository->graft_file;
|
2005-10-12 01:47:34 +00:00
|
|
|
}
|
2007-08-01 00:29:38 +00: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);
|
2017-06-22 18:43:33 +00:00
|
|
|
repo_set_gitdir(the_repository, path);
|
2007-08-01 00:29:38 +00:00
|
|
|
setup_git_env();
|
|
|
|
return 0;
|
|
|
|
}
|
2010-11-02 19:59:07 +00:00
|
|
|
|
|
|
|
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";
|
|
|
|
}
|
2016-03-11 22:36:49 +00:00
|
|
|
|
|
|
|
static int the_shared_repository = PERM_UMASK;
|
lazily load core.sharedrepository
The "shared_repository" config is loaded as part of
check_repository_format_version, but it's not quite like the
other values we check there. Something like
core.repositoryformatversion only makes sense in per-repo
config, but core.sharedrepository can be set in a per-user
config (e.g., to make all "git init" invocations shared by
default).
So it would make more sense as part of git_default_config.
Commit 457f06d (Introduce core.sharedrepository, 2005-12-22)
says:
[...]the config variable is set in the function which
checks the repository format. If this were done in
git_default_config instead, a lot of programs would need
to be modified to call git_config(git_default_config)
first.
This is still the case today, but we have one extra trick up
our sleeve. Now that we have the git_configset
infrastructure, it's not so expensive for us to ask for a
single value. So we can simply lazy-load it on demand.
This should be OK to do in general. There are some problems
with loading config before setup_git_directory() is called,
but we shouldn't be accessing the value before then (if we
were, then it would already be broken, as the variable would
not have been set by check_repository_format_version!). The
trickiest caller is git-init, but it handles the values
manually itself.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-11 22:36:53 +00:00
|
|
|
static int need_shared_repository_from_config = 1;
|
2016-03-11 22:36:49 +00:00
|
|
|
|
|
|
|
void set_shared_repository(int value)
|
|
|
|
{
|
|
|
|
the_shared_repository = value;
|
lazily load core.sharedrepository
The "shared_repository" config is loaded as part of
check_repository_format_version, but it's not quite like the
other values we check there. Something like
core.repositoryformatversion only makes sense in per-repo
config, but core.sharedrepository can be set in a per-user
config (e.g., to make all "git init" invocations shared by
default).
So it would make more sense as part of git_default_config.
Commit 457f06d (Introduce core.sharedrepository, 2005-12-22)
says:
[...]the config variable is set in the function which
checks the repository format. If this were done in
git_default_config instead, a lot of programs would need
to be modified to call git_config(git_default_config)
first.
This is still the case today, but we have one extra trick up
our sleeve. Now that we have the git_configset
infrastructure, it's not so expensive for us to ask for a
single value. So we can simply lazy-load it on demand.
This should be OK to do in general. There are some problems
with loading config before setup_git_directory() is called,
but we shouldn't be accessing the value before then (if we
were, then it would already be broken, as the variable would
not have been set by check_repository_format_version!). The
trickiest caller is git-init, but it handles the values
manually itself.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-11 22:36:53 +00:00
|
|
|
need_shared_repository_from_config = 0;
|
2016-03-11 22:36:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
int get_shared_repository(void)
|
|
|
|
{
|
lazily load core.sharedrepository
The "shared_repository" config is loaded as part of
check_repository_format_version, but it's not quite like the
other values we check there. Something like
core.repositoryformatversion only makes sense in per-repo
config, but core.sharedrepository can be set in a per-user
config (e.g., to make all "git init" invocations shared by
default).
So it would make more sense as part of git_default_config.
Commit 457f06d (Introduce core.sharedrepository, 2005-12-22)
says:
[...]the config variable is set in the function which
checks the repository format. If this were done in
git_default_config instead, a lot of programs would need
to be modified to call git_config(git_default_config)
first.
This is still the case today, but we have one extra trick up
our sleeve. Now that we have the git_configset
infrastructure, it's not so expensive for us to ask for a
single value. So we can simply lazy-load it on demand.
This should be OK to do in general. There are some problems
with loading config before setup_git_directory() is called,
but we shouldn't be accessing the value before then (if we
were, then it would already be broken, as the variable would
not have been set by check_repository_format_version!). The
trickiest caller is git-init, but it handles the values
manually itself.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-11 22:36:53 +00:00
|
|
|
if (need_shared_repository_from_config) {
|
|
|
|
const char *var = "core.sharedrepository";
|
|
|
|
const char *value;
|
|
|
|
if (!git_config_get_value(var, &value))
|
|
|
|
the_shared_repository = git_config_perm(var, value);
|
|
|
|
need_shared_repository_from_config = 0;
|
|
|
|
}
|
2016-03-11 22:36:49 +00:00
|
|
|
return the_shared_repository;
|
|
|
|
}
|
2016-09-13 03:24:23 +00:00
|
|
|
|
|
|
|
void reset_shared_repository(void)
|
|
|
|
{
|
|
|
|
need_shared_repository_from_config = 1;
|
|
|
|
}
|
git: add --no-optional-locks option
Some tools like IDEs or fancy editors may periodically run
commands like "git status" in the background to keep track
of the state of the repository. Some of these commands may
refresh the index and write out the result in an
opportunistic way: if they can get the index lock, then they
update the on-disk index with any updates they find. And if
not, then their in-core refresh is lost and just has to be
recomputed by the next caller.
But taking the index lock may conflict with other operations
in the repository. Especially ones that the user is doing
themselves, which _aren't_ opportunistic. In other words,
"git status" knows how to back off when somebody else is
holding the lock, but other commands don't know that status
would be happy to drop the lock if somebody else wanted it.
There are a couple possible solutions:
1. Have some kind of "pseudo-lock" that allows other
commands to tell status that they want the lock.
This is likely to be complicated and error-prone to
implement (and maybe even impossible with just
dotlocks to work from, as it requires some
inter-process communication).
2. Avoid background runs of commands like "git status"
that want to do opportunistic updates, preferring
instead plumbing like diff-files, etc.
This is awkward for a couple of reasons. One is that
"status --porcelain" reports a lot more about the
repository state than is available from individual
plumbing commands. And two is that we actually _do_
want to see the refreshed index. We just don't want to
take a lock or write out the result. Whereas commands
like diff-files expect us to refresh the index
separately and write it to disk so that they can depend
on the result. But that write is exactly what we're
trying to avoid.
3. Ask "status" not to lock or write the index.
This is easy to implement. The big downside is that any
work done in refreshing the index for such a call is
lost when the process exits. So a background process
may end up re-hashing a changed file multiple times
until the user runs a command that does an index
refresh themselves.
This patch implements the option 3. The idea (and the test)
is largely stolen from a Git for Windows patch by Johannes
Schindelin, 67e5ce7f63 (status: offer *not* to lock the
index and update it, 2016-08-12). The twist here is that
instead of making this an option to "git status", it becomes
a "git" option and matching environment variable.
The reason there is two-fold:
1. An environment variable is carried through to
sub-processes. And whether an invocation is a
background process or not should apply to the whole
process tree. So you could do "git --no-optional-locks
foo", and if "foo" is a script or alias that calls
"status", you'll still get the effect.
2. There may be other programs that want the same
treatment.
I've punted here on finding more callers to convert,
since "status" is the obvious one to call as a repeated
background job. But "git diff"'s opportunistic refresh
of the index may be a good candidate.
The test is taken from 67e5ce7f63, and it's worth repeating
Johannes's explanation:
Note that the regression test added in this commit does
not *really* verify that no index.lock file was written;
that test is not possible in a portable way. Instead, we
verify that .git/index is rewritten *only* when `git
status` is run without `--no-optional-locks`.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-27 06:54:30 +00:00
|
|
|
|
|
|
|
int use_optional_locks(void)
|
|
|
|
{
|
|
|
|
return git_env_bool(GIT_OPTIONAL_LOCKS_ENVIRONMENT, 1);
|
|
|
|
}
|