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>

If the config variable 'core.sharedrepository' is set, the directories

	$GIT_DIR/objects/
	$GIT_DIR/objects/??
	$GIT_DIR/objects/pack
	$GIT_DIR/refs
	$GIT_DIR/refs/heads
	$GIT_DIR/refs/heads/tags

are set group writable (and g+s, since the git group may be not the primary
group of all users).

Since all files are written as lock files first, and then moved to
their destination, they do not have to be group writable.  Indeed, if
this leads to problems you found a bug.

Note that -- as in my first attempt -- 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.

[jc: git variables should be in environment.c unless there is a
 compelling reason to do otherwise.]
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Dereference the environment variable before using it.
Signed-off-by: NTommi Virtanen <tv@inoi.fi>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

 - prefix_filename() is like prefix_path() but can be used to
   name any file on the filesystem, not the files that might go
   into the index file.

 - setup_git_directory_gently() tries to find the GIT_DIR, but does
   not die() if called outside a git repository.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

After figuring out the GIT_DIR location, make sure the
repository is of the right vintage, by calling
check_repository_format(). .
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This adds the repository format version code, first done by
Martin Atukunda.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

setup_git_directory() always trusted what the user told where
GIT_DIR was, and assumed that is a valid .git/ directory.  This
commit changes it to at least do the same level validation as
is_toplevel_directory() does -- has refs/, has objects/ unless
GIT_OBJECT_DIRECTORY is set, and has valid HEAD symlink or
symref.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This adds the counterpart of git-update-ref that lets you read
and create "symbolic refs".  By default it uses a symbolic link
to represent ".git/HEAD -> refs/heads/master", but it can be compiled
to use the textfile symbolic ref.

The places that did 'readlink .git/HEAD' and 'ln -s refs/heads/blah
.git/HEAD' have been converted to use new git-symbolic-ref command, so
that they can deal with either implementation.
Signed-off-by: NJunio C Hamano <junio@twinsun.com>

This is a long overdue clean-up to the code for parsing and passing
diff options.  It also tightens some constness issues.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We have deprecated the old environment variable names for quite a
while and now it's time to remove them.  Gone are:

    SHA1_FILE_DIRECTORIES AUTHOR_DATE AUTHOR_EMAIL AUTHOR_NAME
    COMMIT_AUTHOR_EMAIL COMMIT_AUTHOR_NAME SHA1_FILE_DIRECTORY
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Inspired by a report by Kalle Valo, this changes git-sh-setup-script and
the "setup_git_directory()" function to test that $GIT_DIR/HEAD is a
symlink, since a number of core git features depend on that these days.

We used to allow a regular file there, but git-fsck-cache has been
complaining about that for a while, and anything that uses branches
depends on the HEAD file being a symlink, so let's just encode that as a
fundamental requirement.

Before, a non-symlink HEAD file would appear to work, but have subtle bugs
like not having the HEAD show up as a valid reference (because it wasn't
under "refs"). Now, we will complain loudly, and the user can fix it up
trivially instead of getting strange behaviour.

This also removes the tests for "$GIT_DIR" and "$GIT_OBJECT_DIRECTORY"
being directories, since the other tests will implicitly test for that
anyway (ie the tests for HEAD, refs and 00 would fail).
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Not all programs necessarily have a pathspec array of pathnames, some of
them (like git-update-cache) want to do things one file at a time.  So
export the single-path interface too.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This fixes up usage of ".." (without an ending slash) and "." (with or
without the ending slash) in the git diff family.

It also fixes pathspec matching for the case of an empty pathspec, since a
"." in the top-level directory (or enough ".." under subdirectories) will
result in an empty pathspec. We used to not match it against anything, but
it should in fact match everything.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We may not actually have a valid HEAD at all times, so relax the validity 
tests for a .git subdirectory accordingly.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We always show the diff as an absolute path, but pathnames to diff are
taken relative to the current working directory (and if no pathnames are
given, the default ends up being all of the current working directory).

Note that "../xyz" also works, so you can do

	cd linux/drivers/char
	git diff ../block

and it will generate a diff of the linux/drivers/block changes.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>