git/setup.c, branch v1.5.2

Merge branch 'maint'

2007-03-11T06:07:26Z

* maint: git.el: Retrieve commit log information from .dotest directory. git.el: Avoid appending a signoff line that is already present. setup_git_directory_gently: fix off-by-one error user-manual: install user manual stylesheet with other web documents user-manual: fix rendering of history diagrams user-manual: fix missing colon in git-show example user-manual: fix inconsistent use of pull and merge user-manual: fix inconsistent example glossary: fix overoptimistic automatic linking of defined terms Documentation: s/seperator/separator/ Adjust reflog filemode in shared repository

setup_git_directory_gently: fix off-by-one error

2007-03-11T05:47:45Z

don't tell getcwd that the buffer has one spare byte for an extra / Signed-off-by: Matthias Lederhofer Signed-off-by: Junio C Hamano

Mechanical conversion to use prefixcmp()

2007-02-21T06:03:15Z

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: Junio C Hamano

Do not verify filenames in a bare repository

2007-01-21T03:10:26Z

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: Johannes Schindelin

Detached HEAD (experimental)

2007-01-08T11:02:11Z

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: Junio C Hamano

Automatically detect a bare git repository.

2006-12-31T06:22:13Z

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: Shawn O. Pearce Signed-off-by: Junio C Hamano

Move deny_non_fast_forwards handling completely into receive-pack.

2006-10-31T03:35:16Z

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: Shawn O. Pearce Signed-off-by: Junio C Hamano

add receive.denyNonFastforwards config variable

2006-09-20T23:15:45Z

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: Johannes Schindelin Signed-off-by: Junio C Hamano

Fix crash when GIT_DIR is invalid

2006-08-04T18:30:19Z

We used to test if a pointer was NULL, and if it was, try to access it. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

setup_git_directory_gently: do not barf when GIT_DIR is given.

2006-07-31T00:45:57Z

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: Matthias Lederhofer Signed-off-by: Junio C Hamano