setup_git_directory_gently has done the check already.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous implementation translated '\' to '/' on non-Windows, too
(in those cases where the prefix was actually prepended to the path).
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
* maint:
git-am -i: report rewritten title
git grep shows the same hit repeatedly for unmerged paths
Do check_repository_format() early (re-fix)
Do check_repository_format() early
Add missing inside_work_tree setting in setup_git_directory_gently
This pushes check_repository_format() (actually _gently() version)
to setup_git_directory_gently() in order to prevent from
using unsupported repositories.
New setup_git_directory_gently()'s behaviour is stop searching
for a valid gitdir and return as if there is no gitdir if a
unsupported repository is found. Warning will be thrown in these
cases.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Repository version check is only performed when
setup_git_directory() is called. This makes sure
setup_git_directory_gently() does the check too.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Using the helper function to test for absolute paths makes porting easier.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Remove getpagesize() from sha1_file.c because is it now
included in git-compat-util.h.
Conflicts:
Makefile
compat/mingw.c
git-compat-util.h
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
We check in cmd_blame() if the specified path is there, but we
failed to set up the working tree before that.
While at it, make setup_work_tree() just return if it was run
before.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Create a setup_work_tree() that can be used from any command requiring
a working tree conditionally.
Signed-off-by: Mike Hommey <mh@glandium.org>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Conflicts:
Makefile
RelNotes
builtin-ls-files.c
builtin-tag.c
cache.h
compat/mingw.c
config.c
connect.c
cpio.sh
diff.c
exec_cmd.c
git-gui/Makefile
git-gui/lib/commit.tcl
git-gui/lib/console.tcl
git-mergetool.sh
lockfile.c
path.c
rsh.c
run-command.c
setup.c
show-index.c
spawn-pipe.c
t/Makefile
t/t0000-basic.sh
t/t1300-repo-config.sh
t/t7501-commit.sh
t/test-lib.sh
Resolve as follows
--- Makefile
- mingw/devel removes
SHELL_PATH = /bin/sh
PERL_PATH = /bin/perl
This looks ok. Both are set early in the Makefile to sensible values.
mingw accepts to execute /usr/bin/perl.
- NO_SYMLINKS is no longer needed. Should be auto-detected.
- According to our 0e2bdc35af
we want
NO_R_TO_GCC_LINKER = YesPlease
take our before their change.
- Conflict prefix, SCRIPT_SH:
our 7999f434d7 set prefix =
their 4a7c98dbaf removes cpio emulator
resolve to achieve both.
- Conflict NO_MEMMEM, THREADED_DELTA_SEARCH: take theirs
--- RelNotes
take our: removed file
--- builtin-ls-files.c
Conflict write_name_quoted: take their change.
--- builtin-tag.c
Conflict strip CR
our 7734ad404c adds strip CR
their fd17f5b5f7 modifies code to use strbuf
resolve by removing our code. TODO: we probably need a replacement?
--- cache.h
Conflict is_absolute_path()
our ef5af72062 ifdef
their 637fc51696 ifndef
both achieve the same.
our is a bit more strict but we take their code because we want
to reduce differences to mingw.
--- compat/mingw.c
Conflict at end of file:
our 194c1dbb5a adds git_exit()
resolve by taking their first, followed by our.
--- config.c
Conflict 'fd ='
our 0a453a237e merge junio/master
introduced strange 'fd ='. Resolve by removing 'fd ='.
--- connect.c
- Conflict 'host must have at least 2 chars ...' take their code.
- git_connect(): take their implementation.
--- cpio.sh
Accepted their delete file.
--- diff.c
Resolve using their implementation.
--- exec_cmd.c
Resolve using their implementation.
--- git-gui/**
Resolve using our implementation.
--- git-mergetool.sh
Resolve using their implementation
--- lockfile.c
trivial resolution (empty line removed)
--- path.c
Conflict 'tmp': accepting their implementation, trying TMP, TEMP on all platforms.
--- rsh.c
Accept their delete file.
--- run-command.c
Resolve using their implementation
--- setup.c
Resolve using their implementation
--- show-index.c
Conflict PRIuMAX
our 89697a4c15 fix warning
their 5be507fc95 PRIuMAX
resolve fixing warning in their code.
--- spawn-pipe.c
Conflict environ vs lookup_prog: resolve taking neither
--- t/Makefile
our d1f83218dc --no-hardlinks
their c603988c10 automtically detect symlink support
Resolve using our --no-hardlinks but removing --no-symlinks.
--- t/0000-basic.sh
Resolve using their implementation.
--- t/t1300-repo-config.sh
Resolve using their implementation.
--- t/t7501-commit.sh
Resolve using their implementation.
--- t/test-lib.sh
our d1f83218dc --no-hardlink
their c603988c10 automatically detect symlink support
Resolve using our --no-hardlinks but removing --no-symlinks.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
When both GIT_DIR and GIT_WORK_TREE are set, and
setup_git_directory_gently() changes the current working
directory accordingly, it should also set inside_work_tree = 1.
Without this, work_tree handling code in setup_git_directory()
will be activated. If you stay in root work tree (no prefix),
it does not harm. It does if you work from a subdirectory though.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are a few programs, such as config and diff, which allow running
without a git repository. Therefore, they have to call
setup_git_directory_gently().
However, when GIT_DIR and GIT_WORK_TREE were set, and the current
directory was a subdirectory of the work tree,
setup_git_directory_gently() would return a bogus NULL prefix.
This patch fixes that.
Noticed by REPLeffect on IRC.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The old behaviour was to unilaterally default to the cwd is the work tree
when GIT_DIR was set, but GIT_WORK_TREE wasn't, no matter if we are inside
the GIT_DIR, or if GIT_DIR is actually something like ../../../.git.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
environment.c caches results of many getenv calls.
Under MinGW setenv(X) invalidates all previous values returned by getenv(X)
so cached values become dangling pointers.
Replaced all setenv(GIT_DIR, ...) with set_git_dir
Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
This fix (while correct) actually avoids another nasty bug that must be fixed later:
environment.c caches results of many getenv calls.
Under MinGW setenv(X) invalidates all previous values returned by getenv(X)
so cached values become dangling pointers.
Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In setup_git_directory_gently(), there is a hack to allow for stopping
the search at the drive letter. Only that the patch was incomplete;
we really have to stop there, instead of looping infinitely.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* maint:
apply: remove directory that becomes empty by renaming the last file away
setup.c:verify_non_filename(): don't die unnecessarily while disambiguating
If you have a working tree _file_ "foo", attempt to refer to a
branch "foo/bar" without -- to disambiguate, like this:
$ git log foo/bar
tried to make sure that foo/bar cannot be naming a working tree
file "foo/bar" (in which case we would say "which one do you
want? A rev or a working tree file? clarify with -- please").
We run lstat("foo/bar") to check that. If it does not succeed,
there is no ambiguity.
That is good. But we also checked the error status for the
lstat() and expected it to fail with ENOENT. In this particular
case, however, it fails with ENOTDIR. That should be treated as
"expected error" as well.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In set_work_tree(), variable rel needs to be reinitialized to
NULL on every call (it should not be static).
Make sure the incoming dir variable is not too long before
copying to the temporary buffer, and make sure chdir to the
resulting directory succeeds.
This was spotted and fixed by Alex and Johannes in a handful
patch exchanges. Here is the final version.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
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>
For compatibility reasons, "git init --shared=all" does not write
"all" into the config, but a number. In the shared setup, you
really have to support even older clients on the _same_ repository.
But git_config_perm() did not pick up on it.
Also, "git update-server-info" failed to pick up on the shared
permissions.
This patch fixes both issues, and adds a test to prove it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Tested-by: martin f krafft <madduck@madduck.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In user space, and for getcwd(), the check to see if the
resulting path begins with a '/' does not make sense. This is
merely a mistake by Linus who is so used to code for the kernel,
where a d_path() return value pathname can be either a real
path, or something like "pipe:[8003]", and the difference is the
'/' at the beginning.
Pointed out by Dscho, Matthias Lederhofer and clarified by Linus.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ei/worktree+filter:
filter-branch: always export GIT_DIR if it is set
setup_git_directory: fix segfault if repository is found in cwd
test GIT_WORK_TREE
extend rev-parse test for --is-inside-work-tree
Use new semantics of is_bare/inside_git_dir/inside_work_tree
introduce GIT_WORK_TREE to specify the work tree
test git rev-parse
rev-parse: introduce --is-bare-repository
rev-parse: document --is-inside-git-dir
This uses "git-apply --whitespace=strip" to fix whitespace errors that have
crept in to our source files over time. There are a few files that need
to have trailing whitespaces (most notably, test vectors). The results
still passes the test, and build result in Documentation/ area is unchanged.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Additionally there was a similar part calling setenv and getenv
in the same way which missed a check if getenv succeeded.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
