git/setup.c, branch v2.16.2

Merge branch 'sg/setup-doc-update'

2017-12-19T19:33:58Z

Comment update. * sg/setup-doc-update: setup.c: fix comment about order of .git directory discovery

setup.c: fix comment about order of .git directory discovery

2017-12-07T16:09:06Z

Since gitfiles were introduced in b44ebb19e (Add platform-independent .git "symlink", 2008-02-20) the order of checks during .git directory discovery is: gitfile, gitdir, bare repo. However, that commit did only partially update the in-code comment describing this order, missing the last line which still puts gitdir before gitfile. Signed-off-by: SZEDER Gábor Signed-off-by: Junio C Hamano

Integrate hash algorithm support with repo setup

2017-11-13T04:20:44Z

In future versions of Git, we plan to support an additional hash algorithm. Integrate the enumeration of hash algorithms with repository setup, and store a pointer to the enumerated data in struct repository. Of course, we currently only support SHA-1, so hard-code this value in read_repository_format. In the future, we'll enumerate this value from the configuration. Add a constant, the_hash_algo, which points to the hash_algo structure pointer in the repository global. Note that this is the hash which is used to serialize data to disk, not the hash which is used to display items to the user. The transition plan anticipates that these may be different. We can add an additional element in the future (say, ui_hash_algo) to provide for this case. Include repository.h in cache.h since we now need to have access to these struct and variable definitions. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

setup: expose enumerated repo info

2017-11-13T04:20:44Z

We enumerate several different items as part of struct repository_format, but then actually set up those values using the global variables we've initialized from them. Instead, let's pass a pointer to the structure down to the code where we enumerate these values, so we can later on use those values directly to perform setup. This technique makes it easier for us to determine additional items about the repository format (such as the hash algorithm) and then use them for setup later on, without needing to add additional global variables. We can't avoid using the existing global variables since they're intricately intertwined with how things work at the moment, but this improves things for the future. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

Merge branch 'js/early-config'

2017-11-09T05:31:29Z

Correct start-up sequence so that a repository could be placed immediately under the root directory again (which was broken at around Git 2.13). * js/early-config: setup: avoid double slashes when looking for HEAD

setup: avoid double slashes when looking for HEAD

2017-11-03T14:02:25Z

Andrew Baumann reported that when called outside of any Git worktree, `git rev-parse --is-inside-work-tree` eventually tries to access `//HEAD`, i.e. any `HEAD` file in the root directory, but with a double slash. This double slash is not only unintentional, but is allowed by the POSIX standard to have a special meaning. And most notably on Windows, it does, where it refers to a UNC path of the form `//server/share/`. As a consequence, afore-mentioned `rev-parse` call not only looks for the wrong thing, but it also causes serious delays, as Windows will try to access a server called `HEAD`. Let's simply avoid the unintended double slash. Signed-off-by: Jeff King Acked-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Merge branch 'ks/verify-filename-non-option-error-message-tweak'

2017-10-07T07:27:56Z

Error message tweak. * ks/verify-filename-non-option-error-message-tweak: setup: update error message to be more meaningful

setup: update error message to be more meaningful

2017-10-04T04:13:02Z

The error message shown when a flag is found when expecting a filename wasn't clear as it didn't communicate what was wrong using the 'suitable' words in *all* cases. $ git ls-files README.md test-file Correct case, $ git rev-parse README.md --flags README.md --flags fatal: bad flag '--flags' used after filename Incorrect case, $ git grep "some random regex" -n fatal: bad flag '-n' used after filename The above case is incorrect as "some random regex" isn't a filename in this case. Change the error message to be general and communicative. This results in the following output, $ git rev-parse README.md --flags README.md --flags fatal: option '--flags' must come before non-option arguments $ git grep "some random regex" -n fatal: option '-n' must come before non-option arguments Signed-off-by: Kaartic Sivaraam Signed-off-by: Junio C Hamano

read_gitfile_gently: clarify return value ownership.

2017-09-27T00:14:02Z

Signed-off-by: Han-Wen Nienhuys Signed-off-by: Junio C Hamano

set_git_dir: handle feeding gitdir to itself

2017-09-06T09:06:26Z

Ideally we'd free the existing gitdir field before assigning the new one, to avoid a memory leak. But we can't do so safely because some callers do the equivalent of: set_git_dir(get_git_dir()); We can detect that case as a noop, but there are even more complicated cases like: set_git_dir(remove_leading_path(worktree, get_git_dir()); where we really do need to do some work, but the original string must remain valid. Rather than put the burden on callers to make a copy of the string (only to free it later, since we'll make a copy of it ourselves), let's solve the problem inside set_git_dir(). We can make a copy of the pointer for the old gitdir, and then avoid freeing it until after we've made our new copy. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano