git init --shared=0xxx, where '0xxx' is an octal number, will create
a repository with file modes set to '0xxx'. Users with a safe umask
value (0077) can use this option to force file modes. For example,
'0640' is a group-readable but not group-writable regardless of
user's umask value. Values compatible with old Git versions are written
as they were before, for compatibility reasons. That is, "1" for
"group" and "2" for "everybody".

"git config core.sharedRepository 0xxx" is also handled.
Signed-off-by: NHeikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

setup_git_directory_gently() only modified the value of its *nongit_ok
argument if we were not in a git repository.  Now it will always set it
to 0 when we are inside a repository.

Also remove now unnecessary initializations in the callers of this
function.
Signed-off-by: NSZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

An earlier commit d089ebaa (setup: sanitize absolute and funny paths) made
get_pathspec() aware of absolute paths, but with a botched interface that
forced the callers to count the resulting pathspecs in order to detect
an error of giving a path that is outside the work tree.

This fixes it, by dying inside the function.

We had ls-tree test that relied on a misfeature in the original
implementation of its pathspec handling.  Leading slashes were silently
removed from them.  However we allow giving absolute pathnames (people
want to cut and paste from elsewhere) that are inside work tree these
days, so a pathspec that begin with slash _should_ be treated as a full
path.  The test is adjusted to match the updated rule for get_pathspec().

Earlier I mistook three tests given by Robin that they should succeed, but
these are attempts to add path outside work tree, which should fail
loudly.  These tests also have been fixed.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This change removes all obvious useless if-before-free tests.
E.g., it replaces code like this:

        if (some_expression)
                free (some_expression);

with the now-equivalent:

        free (some_expression);

It is equivalent not just because POSIX has required free(NULL)
to work for a long time, but simply because it has worked for
so long that no reasonable porting target fails the test.
Here's some evidence from nearly 1.5 years ago:

    http://www.winehq.org/pipermail/wine-patches/2006-October/031544.html

FYI, the change below was prepared by running the following:

  git ls-files -z | xargs -0 \
  perl -0x3b -pi -e \
    's/\bif\s*\(\s*(\S+?)(?:\s*!=\s*NULL)?\s*\)\s+(free\s*\(\s*\1\s*\))/$2/s'

Note however, that it doesn't handle brace-enclosed blocks like
"if (x) { free (x); }".  But that's ok, since there were none like
that in git sources.

Beware: if you do use the above snippet, note that it can
produce syntactically invalid C code.  That happens when the
affected "if"-statement has a matching "else".
E.g., it would transform this

  if (x)
    free (x);
  else
    foo ();

into this:

  free (x);
  else
    foo ();

There were none of those here, either.

If you're interested in automating detection of the useless
tests, you might like the useless-if-before-free script in gnulib:
[it *does* detect brace-enclosed free statements, and has a --name=S
 option to make it detect free-like functions with different names]

  http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=build-aux/useless-if-before-free

Addendum:
  Remove one more (in imap-send.c), spotted by Jean-Luc Herren <jlh@gmx.ch>.
Signed-off-by: NJim Meyering <meyering@redhat.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJohannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

core.worktree expects a string value
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The prefix_path() function called from get_pathspec() is
responsible for translating list of user-supplied pathspecs to
list of pathspecs that is relative to the root of the work
tree.  When working inside a subdirectory, the user-supplied
pathspecs are taken to be relative to the current subdirectory.

Among special path components in pathspecs, we used to accept
and interpret only "." ("the directory", meaning a no-op) and
".."  ("up one level") at the beginning.  Everything else was
passed through as-is.

For example, if you are in Documentation/ directory of the
project, you can name Documentation/howto/maintain-git.txt as:

    howto/maintain-git.txt
    ../Documentation/howto/maitain-git.txt
    ../././Documentation/howto/maitain-git.txt

but not as:

    howto/./maintain-git.txt
    $(pwd)/howto/maintain-git.txt

This patch updates prefix_path() in several ways:

 - If the pathspec is not absolute, prefix (i.e. the current
   subdirectory relative to the root of the work tree, with
   terminating slash, if not empty) and the pathspec is
   concatenated first and used in the next step.  Otherwise,
   that absolute pathspec is used in the next step.

 - Then special path components "." (no-op) and ".." (up one
   level) are interpreted to simplify the path.  It is an error
   to have too many ".." to cause the intermediate result to
   step outside of the input to this step.

 - If the original pathspec was not absolute, the result from
   the previous step is the resulting "sanitized" pathspec.
   Otherwise, the result from the previous step is still
   absolute, and it is an error if it does not begin with the
   directory that corresponds to the root of the work tree.  The
   directory is stripped away from the result and is returned.

 - In any case, the resulting pathspec in the array
   get_pathspec() returns omit the ones that caused errors.

With this patch, the last two examples also behave as expected.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJim Meyering <meyering@redhat.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

setup_git_directory_gently has done the check already.
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio 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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Acked-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Using the helper function to test for absolute paths makes porting easier.
Signed-off-by: NSteffen Prohaska <prohaska@zib.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio 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: NMike Hommey <mh@glandium.org>
Acked-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio 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: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NShawn 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: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NJunio 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: NJunio C Hamano <gitster@pobox.com>
Acked-by: NJohannes 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: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Some lines were not indented by tabs but by spaces.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio 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: NJohannes Schindelin <johannes.schindelin@gmx.de>
Tested-by: Nmartin f krafft <madduck@madduck.net>
Signed-off-by: NJunio 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: NJunio C Hamano <gitster@pobox.com>

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: NJunio 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: NMatthias Lederhofer <matled@gmx.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Up to now to check for a working tree this was used:
	!is_bare && !inside_git_dir
(the check for bare is redundant because is_inside_git_dir
returned already 1 for bare repositories).
Now the check is:
	inside_work_tree && !inside_git_dir
Signed-off-by: NMatthias Lederhofer <matled@gmx.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

setup_gdg is used as abbreviation for setup_git_directory_gently.

The work tree can be specified using the environment variable
GIT_WORK_TREE and the config option core.worktree (the environment
variable has precendence over the config option).  Additionally
there is a command line option --work-tree which sets the
environment variable.

setup_gdg does the following now:

GIT_DIR unspecified
repository in .git directory
    parent directory of the .git directory is used as work tree,
    GIT_WORK_TREE is ignored

GIT_DIR unspecified
repository in cwd
    GIT_DIR is set to cwd
    see the cases with GIT_DIR specified what happens next and
    also see the note below

GIT_DIR specified
GIT_WORK_TREE/core.worktree unspecified
    cwd is used as work tree

GIT_DIR specified
GIT_WORK_TREE/core.worktree specified
    the specified work tree is used

Note on the case where GIT_DIR is unspecified and repository is in cwd:
    GIT_WORK_TREE is used but is_inside_git_dir is always true.
    I did it this way because setup_gdg might be called multiple
    times (e.g. when doing alias expansion) and in successive calls
    setup_gdg should do the same thing every time.

Meaning of is_bare/is_inside_work_tree/is_inside_git_dir:

(1) is_bare_repository
    A repository is bare if core.bare is true or core.bare is
    unspecified and the name suggests it is bare (directory not
    named .git).  The bare option disables a few protective
    checks which are useful with a working tree.  Currently
    this changes if a repository is bare:
        updates of HEAD are allowed
        git gc packs the refs
        the reflog is disabled by default

(2) is_inside_work_tree
    True if the cwd is inside the associated working tree (if there
    is one), false otherwise.

(3) is_inside_git_dir
    True if the cwd is inside the git directory, false otherwise.
    Before this patch is_inside_git_dir was always true for bare
    repositories.

When setup_gdg finds a repository git_config(git_default_config) is
always called.  This ensure that is_bare_repository makes use of
core.bare and does not guess even though core.bare is specified.

inside_work_tree and inside_git_dir are set if setup_gdg finds a
repository.  The is_inside_work_tree and is_inside_git_dir functions
will die if they are called before a successful call to setup_gdg.
Signed-off-by: NMatthias Lederhofer <matled@gmx.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

don't tell getcwd that the buffer has one spare byte for an extra /
Signed-off-by: NMatthias Lederhofer <matled@gmx.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This mechanically converts strncmp() to use prefixcmp(), but only when
the parameters match specific patterns, so that they can be verified
easily.  Leftover from this will be fixed in a separate step, including
idiotic conversions like

    if (!strncmp("foo", arg, 3))

  =>

    if (!(-prefixcmp(arg, "foo")))

This was done by using this script in px.perl

   #!/usr/bin/perl -i.bak -p
   if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) {
           s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|;
   }
   if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) {
           s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|;
   }

and running:

   $ git grep -l strncmp -- '*.c' | xargs perl px.perl
Signed-off-by: NJunio C Hamano <junkio@cox.net>

For example, it makes no sense to check the presence of a file
named "HEAD" when calling "git log HEAD" in a bare repository.

Noticed by Han-Wen Nienhuys.
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>

This allows "git checkout v1.4.3" to dissociate the HEAD of
repository from any branch.  After this point, "git branch"
starts reporting that you are not on any branch.  You can go
back to an existing branch by saying "git checkout master", for
example.

This is still experimental.  While I think it makes sense to
allow commits on top of detached HEAD, it is rather dangerous
unless you are careful in the current form.  Next "git checkout
master" will obviously lose what you have done, so we might want
to require "git checkout -f" out of a detached HEAD if we find
that the HEAD commit is not an ancestor of any other branches.
There is no such safety valve implemented right now.

On the other hand, the reason the user did not start the ad-hoc
work on a new branch with "git checkout -b" was probably because
the work was of a throw-away nature, so the convenience of not
having that safety valve might be even better.  The user, after
accumulating some commits on top of a detached HEAD, can always
create a new branch with "git checkout -b" not to lose useful
work done while the HEAD was detached.

We'll see.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Many users find it unfriendly that they can create a bare git
repository easily with `git clone --bare` but are then unable to
run simple commands like `git log` once they cd into that newly
created bare repository.  This occurs because we do not check to
see if the current working directory is a git repository.

Instead of failing out with "fatal: Not a git repository" we should
try to automatically detect if the current working directory is
a bare repository and use that for GIT_DIR, and fail out only if
that doesn't appear to be true.

We test the current working directory only after we have tried
searching up the directory tree.  This is to retain backwards
compatibility with our previous behavior on the off chance that
a user has a 'refs' and 'objects' subdirectories and a 'HEAD'
file that looks like a symref, all stored within a repository's
associated working directory.

This change also consolidates the validation logic between the case
of GIT_DIR being supplied and GIT_DIR not being supplied, cleaning
up the code.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The 'receive.denynonfastforwards' option has nothing to do with
the repository format version.  Since receive-pack already uses
git_config to initialize itself before executing any updates we
can use the normal configuration strategy and isolate the receive
specific variables away from the core variables.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

If receive.denyNonFastforwards is set to true, git-receive-pack will deny
non fast-forwards, i.e. forced updates. Most notably, a push to a repository
which has that flag set will fail.

As a first user, 'git-init-db --shared' sets this flag, since in a shared
setup, you are most unlikely to want forced pushes to succeed.
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We used to test if a pointer was NULL, and if it was, try to access it.
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Earlier we barfed when GIT_DIR environment variable points at a
directory yet to be created, which made it impossible to use
configuration mechanism in "git-init-db".
Signed-off-by: NMatthias Lederhofer <matled@gmx.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This enhances core.sharedrepository to have additionally
specify that read and exec permissions to be given to others as
well.  It is useful when serving a repository via gitweb and
git-daemon that runs as a user outside the project group.

The configuration item can take the following values:

    [core]
	sharedrepository 	 ; the same as "group"
	sharedrepository = true  ; ditto
	sharedrepository = 1	 ; ditto
	sharedrepository = group ; allow rwx to group
	sharedrepository = all   ; allow rwx to group, allow rx to other
	sharedrepository = umask ; not shared - use umask

It also extends "git init-db" to take "--shared=all" and friends
from the command line.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

If you don't have a "--" marker, then:

 - all of the arguments we are going to assume are pathspecs
   must exist in the working tree.

 - none of the arguments we parsed as revisions could be
   interpreted as a filename.

so that there really isn't any possibility of confusion in case
somebody does have a revision that looks like a pathname too.

The former rule has been in effect; this implements the latter.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When we are in a subdirectory of a git archive, we need to take the prefix
of that subdirectory into accoung when we verify filename arguments.

Noted by Matthias Lederhofer

This also uses the improved error reporting for all the other git commands
that use the revision parsing interfaces, not just git-rev-parse. Also, it
makes the error reporting for mixed filenames and argument flags clearer
(you cannot put flags after the start of the pathname list).

[jc: with fix to a trivial typo noticed by Timo Hirvonen]
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>