path: root/setup.c
AgeCommit message (Collapse)Author
2011-06-30Merge branch 'da/git-prefix-everywhere' into nextJunio C Hamano
* da/git-prefix-everywhere: t/ Add GIT_PREFIX tests git-mergetool--lib: Make vimdiff retain the current directory git: Remove handling for GIT_PREFIX setup: Provide GIT_PREFIX to built-ins
2011-05-30Merge branch 'maint'Junio C Hamano
* maint: separate parens by a space to avoid confusing some shells Documentation/technical/api-diff.txt: correct name of diff_unmerge() read_gitfile_gently: use ssize_t to hold read result remove tests of always-false condition rerere.c: diagnose a corrupt MERGE_RR when hitting EOF between TAB and '\0'
2011-05-30Merge branch 'jm/maint-misc-fix' into maintJunio C Hamano
* jm/maint-misc-fix: read_gitfile_gently: use ssize_t to hold read result remove tests of always-false condition rerere.c: diagnose a corrupt MERGE_RR when hitting EOF between TAB and '\0'
2011-05-26setup: Provide GIT_PREFIX to built-insDavid Aguilar
GIT_PREFIX was added in 7cf16a14f5c070f7b14cf28023769450133172ae so that aliases can know the directory from which a !alias was called. Knowing the prefix relative to the root is helpful in other programs so export it to built-ins as well. Helped-by: Michael J Gruber <> Signed-off-by: David Aguilar <> Signed-off-by: Junio C Hamano <>
2011-05-26read_gitfile_gently: use ssize_t to hold read resultJeff King
Otherwise, a negative error return becomes a very large read value. We catch this in practice because we compare the expected and actual numbers of bytes (and you are not likely to be reading (size_t)-1 bytes), but this makes the correctness a little more obvious. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-05-23Merge branch 'jc/magic-pathspec'Junio C Hamano
* jc/magic-pathspec: setup.c: Fix some "symbol not declared" sparse warnings t3703: Skip tests using directory name ":" on Windows revision.c: leave a note for "a lone :" enhancement t3703, t4208: add test cases for magic pathspec rev/path disambiguation: further restrict "misspelled index entry" diag fix overslow :/no-such-string-ever-existed diagnostics fix overstrict :<path> diagnosis grep: use get_pathspec() correctly pathspec: drop "lone : means no pathspec" from get_pathspec() Revert "magic pathspec: add ":(icase)path" to match case insensitively" magic pathspec: add ":(icase)path" to match case insensitively magic pathspec: futureproof shorthand form magic pathspec: add tentative ":/path/from/top/level" pathspec support
2011-05-18setup.c: Fix some "symbol not declared" sparse warningsRamsay Jones
In particular, sparse issues the "symbol 'a_symbol' was not declared. Should it be static?" warnings for the following symbols: setup.c:159:3: 'pathspec_magic' setup.c:176:12: 'prefix_pathspec' These symbols only require file scope, so we add the static modifier to their declarations. Signed-off-by: Ramsay Jones <> Signed-off-by: Junio C Hamano <>
2011-05-10rev/path disambiguation: further restrict "misspelled index entry" diagJunio C Hamano
A colon followed by anything !isalnum() (e.g. ":/heh") at this point is known not to be an existing rev. Just give a generic "neither a rev nor a path" error message. Signed-off-by: Junio C Hamano <>
2011-05-10fix overslow :/no-such-string-ever-existed diagnosticsJunio C Hamano
"git cmd :/no-such-string-ever-existed" runs an extra round of get_sha1() since 009fee4 (Detailed diagnosis when parsing an object name fails., 2009-12-07). Once without error diagnosis to see there is no commit with such a string in the log message (hence "it cannot be a ref"), and after seeing that :/no-such-string-ever-existed is not a filename (hence "it cannot be a path, either"), another time to give "better diagnosis". The thing is, the second time it runs, we already know that traversing the history all the way down to the root will _not_ find any matching commit. Rename misguided "gently" parameter, which is turned off _only_ when the "detailed diagnosis" codepath knows that it cannot be a ref and making the call only for the caller to die with a message. Flip its meaning (and adjust the callers) and call it "only_to_die", which is not a great name, but it describes far more clearly what the codepaths that switches their behaviour based on this variable do. On my box, the command spends ~1.8 seconds without the patch to make the report; with the patch it spends ~1.12 seconds. Signed-off-by: Junio C Hamano <>
2011-05-10pathspec: drop "lone : means no pathspec" from get_pathspec()Junio C Hamano
We may want to give the pathspec subsystem such a feature, but not while we are still using get_pathspec() that returns a stupid "char **" that loses subtle nuances that existed in the input string. In the meantime, the callers of get_pathspec() that want to support it could do an equivalent before feeding their argv[] to the function themselves quite easily. Signed-off-by: Junio C Hamano <>
2011-05-10Revert "magic pathspec: add ":(icase)path" to match case insensitively"Junio C Hamano
This reverts commit d0546e2d488b1ba185c430b638619ab1d91af509, which was only meant to be a Proof-of-concept used during the discussion. The real implementation of the feature needs to wait until we migrate all the code to use "struct pathspec", not "char **", to represent richer semantics given to pathspec.
2011-05-02Merge branch 'nd/maint-setup'Junio C Hamano
* nd/maint-setup: Kill off get_relative_cwd() setup: return correct prefix if worktree is '/' Conflicts: dir.c setup.c
2011-04-08magic pathspec: add ":(icase)path" to match case insensitivelyJunio C Hamano
Signed-off-by: Junio C Hamano <>
2011-04-08magic pathspec: futureproof shorthand formJunio C Hamano
The earlier design was to take whatever non-alnum that the short format parser happens to support, leaving the rest as part of the pattern, so a version of git that knows '*' magic and a version that does not would have behaved differently when given ":*Makefile". The former would have applied the '*' magic to the pattern "Makefile", while the latter would used no magic to the pattern "*Makefile". Instead, just reserve all non-alnum ASCII letters that are neither glob nor regexp special as potential magic signature, and when we see a magic that is not supported, die with an error message, just like the longhand codepath does. With this, ":%#!*Makefile" will always mean "%#!" magic applied to the pattern "*Makefile", no matter what version of git is used (it is a different matter if the version of git supports all of these three magic matching rules). Also make ':' without anything else to mean "there is no pathspec". This would allow differences between "git log" and "git log ." run from the top level of the working tree (the latter simplifies no-op commits away from the history) to be expressed from a subdirectory by saying "git log :". Helped-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2011-04-07magic pathspec: add tentative ":/path/from/top/level" pathspec supportJunio C Hamano
Support ":/" magic string that can be prefixed to a pathspec element to say "this names the path from the top-level of the working tree", when you are in the subdirectory. For example, you should be able to say: $ edit Makefile ;# top-level $ cd Documentation $ edit git.txt ;# in the subdirectory and then do one of three things, still inside the subdirectory: $ git add -u . ;# add only Documentation/git.txt $ git add -u :/ ;# add everything, including paths outside Documentation $ git add -u ;# whatever the default setting is. To truly support magic pathspec, the API needs to be restructured so that get_pathspec() and init_pathspec() are unified into one call. Currently, the former just prefixes the user supplied pathspec with the current subdirectory path, and the latter takes the output from the former and pre-parses them into a bit richer structure for easier handling. They should become a single API function that takes the current subdirectory path and the remainder of argv[] (after parsing --options and revision arguments from the command line) and returns an array of parsed pathspec elements, and "magic" should become attributes of struct pathspec_item. This patch implements only "top" magic because it can be hacked into the system without such a refactoring. The syntax for magic pathspec prefix is designed to be extensible yet simple to type to invoke a simple magic like "from the top". The parser for the magic prefix is hooked into get_pathspec() function in this patch, and it needs to be moved when we refactor the API. But we have to start from somewhere. Signed-off-by: Junio C Hamano <>
2011-03-29setup: return correct prefix if worktree is '/'Nguyễn Thái Ngọc Duy
The same old problem reappears after setup code is reworked. We tend to assume there is at least one path component in a path and forget that path can be simply '/'. Reported-by: Matthijs Kooijman <> Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2011-03-17Name make_*_path functions more accuratelyCarlos Martín Nieto
Rename the make_*_path functions so it's clearer what they do, in particlar make clear what the differnce between make_absolute_path and make_nonrelative_path is by renaming them real_path and absolute_path respectively. make_relative_path has an understandable name and is renamed to relative_path to maintain the name convention. The function calls have been replaced 1-to-1 in their usage. Signed-off-by: Carlos Martín Nieto <> Signed-off-by: Junio C Hamano <>
2011-02-10Merge branch 'cb/setup'Junio C Hamano
* cb/setup: setup: translate symlinks in filename when using absolute paths
2011-01-21Subject: setup: officially support --work-tree without --git-dirJonathan Nieder
The original intention of --work-tree was to allow people to work in a subdirectory of their working tree that does not have an embedded .git directory. Because their working tree, which their $cwd was in, did not have an embedded .git, they needed to use $GIT_DIR to specify where it is, and because this meant there was no way to discover where the root level of the working tree was, so we needed to add $GIT_WORK_TREE to tell git where it was. However, this facility has long been (mis)used by people's scripts to start git from a working tree _with_ an embedded .git directory, let git find .git directory, and then pretend as if an unrelated directory were the associated working tree of the .git directory found by the discovery process. It happens to work in simple cases, and is not worth causing "regression" to these scripts. Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2011-01-04setup: translate symlinks in filename when using absolute pathsCarlo Marcelo Arenas Belon
otherwise, comparison to validate against work tree will fail when the path includes a symlink and the name passed is not canonical. Signed-off-by: Carlo Marcelo Arenas Belon <> Signed-off-by: Junio C Hamano <>
2010-12-28Merge branch 'nd/setup'Junio C Hamano
* nd/setup: (47 commits) setup_work_tree: adjust relative $GIT_WORK_TREE after moving cwd git.txt: correct where --work-tree path is relative to Revert "Documentation: always respect core.worktree if set" t0001: test git init when run via an alias Remove all logic from get_git_work_tree() setup: rework setup_explicit_git_dir() setup: clean up setup_discovered_git_dir() t1020-subdirectory: test alias expansion in a subdirectory setup: clean up setup_bare_git_dir() setup: limit get_git_work_tree()'s to explicit setup case only Use git_config_early() instead of git_config() during repo setup Add git_config_early() git-rev-parse.txt: clarify --git-dir t1510: setup case #31 t1510: setup case #30 t1510: setup case #29 t1510: setup case #28 t1510: setup case #27 t1510: setup case #26 t1510: setup case #25 ...
2010-12-27setup_work_tree: adjust relative $GIT_WORK_TREE after moving cwdNguyễn Thái Ngọc Duy
When setup_work_tree() is called, it moves cwd to $GIT_WORK_TREE and makes internal copy of $GIT_WORK_TREE absolute. The environt variable, if set by user, remains unchanged. If the variable is relative, it is no longer correct because its base dir has changed. Instead of making $GIT_WORK_TREE absolute too, we just say "." and let subsequent git processes handle it. Reported-by: Michel Briand <> Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2010-12-22setup: rework setup_explicit_git_dir()Nguyễn Thái Ngọc Duy
This function is the most complex one among the three setup_* functions because all GIT_DIR, GIT_WORK_TREE, core.worktree and core.bare are involved. Because core.worktree is only effective inside setup_explicit_git_dir() and the extra code in setup_git_directory() is to handle that. The extra code can now be retired. Also note that setup_explicit assignment is removed, worktree setting is no longer decided by get_git_work_tree(). get_git_work_tree() will be simplified in the next commit. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2010-12-22setup: clean up setup_discovered_git_dir()Nguyễn Thái Ngọc Duy
If core.bare is true, discard the discovered worktree, move back to original cwd. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2010-12-22setup: clean up setup_bare_git_dir()Nguyễn Thái Ngọc Duy
work_tree_env argument is removed because this function does not need it. GIT_WORK_TREE is only effective inside setup_explicit_git_dir. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2010-12-22setup: limit get_git_work_tree()'s to explicit setup case onlyNguyễn Thái Ngọc Duy
get_git_work_tree() takes input as core.worktree, core.bare, GIT_WORK_TREE and decides correct worktree setting. Unfortunately it does not do its job well. core.worktree and GIT_WORK_TREE should only be taken into account, if GIT_DIR is set (which is handled by setup_explicit_git_dir). For other setup cases, only core.bare matters. Add a temporary variable setup_explicit to adjust get_git_work_tree() behavior as such. This variable will be gone once setup_* rework is done. Also remove is_bare_repository_cfg check in set_git_work_tree() to ease the rework. We are going to check for core.bare and core.worktree early before setting worktree. For example, if core.bare is true, no need to set worktree. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2010-12-22Use git_config_early() instead of git_config() during repo setupNguyễn Thái Ngọc Duy
When git_config() is called, either git_dir has already been set (by $GIT_DIR env or set_git_dir()), or it will default git_dir to ".git". git_config_early() gives setup functions more freedom because it does not require git_dir. Give it a config path, it will happily examine it. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2010-12-16Merge branch 'nd/extended-sha1-relpath'Junio C Hamano
* nd/extended-sha1-relpath: get_sha1: teach ":$n:<path>" the same relative path logic get_sha1: support relative path ":path" syntax Make prefix_path() return char* without const Conflicts: sha1_name.c
2010-12-13Merge branch 'jn/parse-options-extra'Junio C Hamano
* jn/parse-options-extra: update-index: migrate to parse-options API setup: save prefix (original cwd relative to toplevel) in startup_info parse-options: make resuming easier after PARSE_OPT_STOP_AT_NON_OPTION parse-options: allow git commands to invent new option types parse-options: never suppress arghelp if LITERAL_ARGHELP is set parse-options: do not infer PARSE_OPT_NOARG from option type parse-options: sanity check PARSE_OPT_NOARG flag parse-options: move NODASH sanity checks to parse_options_check parse-options: clearer reporting of API misuse parse-options: Don't call parse_options_check() so much
2010-12-07Make prefix_path() return char* without constNguyễn Thái Ngọc Duy
prefix_path() allocates new buffer. There's no reason for it to keep the buffer for itself and waste memory. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2010-12-07setup: save prefix (original cwd relative to toplevel) in startup_infoNguyễn Thái Ngọc Duy
Save the path from the original cwd to the cwd at the end of the setup procedure in the startup_info struct introduced in e37c1329 (2010-08-05). The value cannot vary from thread to thread anyway, since the cwd is global. So now in your builtin command, instead of passing prefix around, when you want to convert a user-supplied path to a cwd-relative path, you can use startup_info->prefix directly. Caveat: As with the return value from setup_git_directory_gently(), startup_info->prefix would be NULL when the original cwd is not a subdir of the toplevel. Longer term, this would allow the prefix to be reused when several noncooperating functions require access to the same repository (for example, when accessing configuration before running a builtin). Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2010-10-18prefix_filename(): safely handle the case where pfx_len=0Thomas Rast
Current prefix_filename() is proofed against the case where the prefix 'pfx' is NULL or a 0-length string, _except on Windows_. Change the behaviour to work the same on both platforms, and only check pfx_len so that callers passing a NULL prefix with a nonzero pfx_len segfault early on both. Signed-off-by: Thomas Rast <> Signed-off-by: Junio C Hamano <>
2010-08-31Merge branch 'jn/paginate-fix'Junio C Hamano
* jn/paginate-fix: t7006 (pager): add missing TTY prerequisites merge-file: run setup_git_directory_gently() sooner var: run setup_git_directory_gently() sooner ls-remote: run setup_git_directory_gently() sooner index-pack: run setup_git_directory_gently() sooner config: run setup_git_directory_gently() sooner bundle: run setup_git_directory_gently() sooner apply: run setup_git_directory_gently() sooner grep: run setup_git_directory_gently() sooner shortlog: run setup_git_directory_gently() sooner git wrapper: allow setup_git_directory_gently() be called earlier setup: remember whether repository was found git wrapper: introduce startup_info struct Conflicts: builtin/index-pack.c
2010-08-16Merge branch 'jn/maint-setup-fix' (early part) into jn/paginate-fixJunio C Hamano
* 'jn/maint-setup-fix' (early part): Revert "rehabilitate 'git index-pack' inside the object store" setup: do not forget working dir from subdir of gitdir t4111 (apply): refresh index before applying patches to it setup: split off get_device_or_die helper setup: split off a function to handle hitting ceiling in repo search setup: split off code to handle stumbling upon a repository setup: split off a function to checks working dir for .git file setup: split off $GIT_DIR-set case from setup_git_directory_gently tests: try git apply from subdir of toplevel t1501 (rev-parse): clarify
2010-08-11setup: remember whether repository was foundNguyễn Thái Ngọc Duy
As v1.7.2~16^2 (git --paginate: paginate external commands again, 2010-07-14) explains, builtins (like git config) that do not use RUN_SETUP are not finding GIT_DIR set correctly when it is time to launch the pager from run_builtin(). If they were to search for a repository sooner, then the outcome of such early repository accesses would be more predictable and reliable. The cmd_*() functions learn whether a repository was found through the *nongit_ok return value from setup_git_directory_gently(). If run_builtin() is to take care of the repository search itself, that datum needs to be retrievable from somewhere else. Use the startup_info struct for this. As a bonus, this information becomes available to functions such as git_config() which might want to avoid trying to access a repository when none is present. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <> Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2010-08-04setup: split off a function to handle ordinary .git directoriesNguyễn Thái Ngọc Duy
Finish the clean-up of setup_git_directory_gently() by splitting the last case of validation+setup (global variables, prefix, check_format, set_git_dir) into its own function. Now setup_git_git_directory_gently itself takes care of discovery only and the functions that pick up from there are nearby in the source file so they can be easily compared. Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2010-08-04setup: do not forget working dir from subdir of gitdirNguyễn Thái Ngọc Duy
v1.6.1.3~4^2 (Fix gitdir detection when in subdir of gitdir, 2009-01-16) did not go far enough: when a git directory is an ancestor of the original working directory, not only should GIT_DIR be set to point to the .git directory, but the original working directory should be restored before carrying out the relevant command. This way, the effect of running a git command from a subdir of .git will be the same whether or not GIT_DIR is explicitly set. Noticed while investigating v1.6.0.3~1 (rehabilitate 'git index-pack' inside the object store, 2008-10-20). Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2010-07-26setup: split off get_device_or_die helperJonathan Nieder
This does not eliminate any code, but it skims some off of the main loop of setup_git_directory_gently so that can be understood more easily. Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2010-07-26setup: split off a function to handle hitting ceiling in repo searchJonathan Nieder
Perhaps some day, other similar conditions (hitting the mount point, hitting the root of the file system) will share this code. Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2010-07-26setup: split off code to handle stumbling upon a repositoryJonathan Nieder
If a repository is found as an ancestor of the original working directory, it is assumed by default to be bare. Handle this case with its own function. Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2010-07-26setup: split off a function to checks working dir for .git fileJonathan Nieder
The repository discovery procedure looks something like this: while (same filesystem) { check .git in working dir check . chdir(..) } Add a function for the first step to make the actual code look a bit closer to that pseudocode. Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2010-07-26setup: split off $GIT_DIR-set case from setup_git_directory_gentlyJonathan Nieder
If $GIT_DIR is set, setup_git_directory_gently does not have to do any repository discovery at all. Split off a function for the validation it still does do, in the hope that this will make setup_git_directory_gently proper less daunting to read. Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2010-07-20Merge branch 'maint'Junio C Hamano
* maint: t/README: clarify test_must_fail description Check size of path buffer before writing into it Conflicts: t/README
2010-07-20Check size of path buffer before writing into itGreg Brockman
This prevents a buffer overrun that could otherwise be triggered by creating a file called '.git' with contents gitdir: (something really long) Signed-off-by: Greg Brockman <> Signed-off-by: Junio C Hamano <>
2010-07-14Use dev_t for device id (st_dev) from stat in setup_git_directory_gently()Raja R Harinath
The original declaration was int, which seems to cause trouble on my machine. It causes spurious "filesystem boundary" errors when running the testsuite. The cause seems to be $ stat -c%d . 2147549952 which is too large for a 32-bit int type. Using the correct type, dev_t, solves the issue. (Because I'm paranoid and forgetful, I checked -- yes, Unix v7 had dev_t.) Other uses of st_dev seem to be reasonably safe. fill_stat_cache_info truncates it to an 'unsigned int', but that value seems to be used only to validate the cache, and only if USE_STDEV is defined. Signed-off-by: Raja R Harinath <> Signed-off-by: Junio C Hamano <>
2010-06-07Merge branch 'maint'Junio C Hamano
* maint: setup: document prefix
2010-06-05setup: document prefixClemens Buchacher
Signed-off-by: Clemens Buchacher <> Signed-off-by: Junio C Hamano <>
If a missing ONE_FILESYSTEM defaults to true, the only users who set this variable set it to false to tell git not to limit the discovery to one filesystem; there are too many negations in one sentence to make a simple panda brain dizzy. Use the variable GIT_DISCOVERY_ACROSS_FILESYSTEM that changes the behaviour from the default "limit to one filesystem" to "cross the boundary as I ask you to"; makes the semantics much more straight forward. Signed-off-by: Junio C Hamano <>
2010-04-04GIT_ONE_FILESYSTEM: flip the default to stop at filesystem boundariesJunio C Hamano
Regarding the new environment variable, Linus Torvalds <> writes on Tue, 30 Mar 2010 in <>: I suspect that it is _very_ unusual to have a source repo that crosses multiple filesystems, and the original reason for this patch-series seems to me to be likely to be more common than that multi-fs case. So having the logic go the other way would seem to match the common case, no? The "crossing filesystem boundary" condition is checked by comparing st_dev field in the result from stat(2). This is slightly worrysome if non-POSIX ports return different values in the field even for directories in the same work tree extracted to the same "filesystem". Erik Faye-Lund confirms that in the msysgit port st_dev is 0, so this should be safe, as "even Windows is safe" ;-) This will affect those who use /.git to cram /etc and /home/me in the same repostiory, /home is mounted from non-root filesystem, and a git operation is done from inside /home/me/src. But that is such a corner case we don't want to give preference over helping people who will benefit from having this default so that they do not have to suffer from slow automounters. Signed-off-by: Junio C Hamano <>
2010-03-28Add support for GIT_ONE_FILESYSTEMLars R. Damerow
This patch makes git pay attention to the GIT_ONE_FILESYSTEM environment variable. When that variable is set, git will stop searching for a GIT_DIR when it attempts to cross a filesystem boundary. When working in an environment with too many automount points to make maintaining a GIT_CEILING_DIRECTORIES list enjoyable, GIT_ONE_FILESYSTEM gives the option of turning all such attempts off with one setting. Signed-off-by: Lars R. Damerow <> Signed-off-by: Junio C Hamano <>