git/setup.c, branch v2.8.2

setup: set startup_info->have_repository more reliably

2016-03-07T01:18:16Z

When setup_git_directory() is called, we set a flag in startup_info to indicate we have a repository. But there are a few other mechanisms by which we might set up a repo: 1. When creating a new repository via init_db(), we transition from no-repo to being in a repo. We should tweak this flag at that moment. 2. In enter_repo(), a stricter form of setup_git_directory() used by server-side programs, we check the repository format config. After doing so, we know we're in a repository, and can set the flag. With these changes, library code can now reliably tell whether we are in a repository and act accordingly. We'll leave the "prefix" field as NULL, which is what happens when setup_git_directory() finds there is no prefix. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

setup: make startup_info available everywhere

2016-03-07T01:17:37Z

Commit a60645f (setup: remember whether repository was found, 2010-08-05) introduced the startup_info structure, which records some parts of the setup_git_directory() process (notably, whether we actually found a repository or not). One of the uses of this data is for functions to behave appropriately based on whether we are in a repo. But the startup_info struct is just a pointer to storage provided by the main program, and the only program that sets it up is the git.c wrapper. Thus builtins have access to startup_info, but externally linked programs do not. Worse, library code which is accessible from both has to be careful about accessing startup_info. This can be used to trigger a die("BUG") via get_sha1(): $ git fast-import <<-\EOF tag foo from HEAD:./whatever EOF fatal: BUG: startup_info struct is not initialized. Obviously that's fairly nonsensical input to feed to fast-import, but we should never hit a die("BUG"). And there may be other ways to trigger it if other non-builtins resolve sha1s. So let's point the storage for startup_info to a static variable in setup.c, making it available to all users of the library code. We _could_ turn startup_info into a regular extern struct, but doing so would mean tweaking all of the existing use sites. So let's leave the pointer indirection in place. We can, however, drop any checks for NULL, as they will always be false (and likewise, we can drop the test covering this case, which was a rather artificial situation using one of the test-* programs). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'jk/tighten-alloc'

2016-02-26T21:37:16Z

Update various codepaths to avoid manually-counted malloc(). * jk/tighten-alloc: (22 commits) ewah: convert to REALLOC_ARRAY, etc convert ewah/bitmap code to use xmalloc diff_populate_gitlink: use a strbuf transport_anonymize_url: use xstrfmt git-compat-util: drop mempcpy compat code sequencer: simplify memory allocation of get_message test-path-utils: fix normalize_path_copy output buffer size fetch-pack: simplify add_sought_entry fast-import: simplify allocation in start_packfile write_untracked_extension: use FLEX_ALLOC helper prepare_{git,shell}_cmd: use argv_array use st_add and st_mult for allocation size computation convert trivial cases to FLEX_ARRAY macros use xmallocz to avoid size arithmetic convert trivial cases to ALLOC_ARRAY convert manual allocations to argv_array argv-array: add detach function add helpers for allocating flex-array structs harden REALLOC_ARRAY and xcalloc against size_t overflow tree-diff: catch integer overflow in combine_diff_path allocation ...

Merge branch 'nd/dwim-wildcards-as-pathspecs'

2016-02-24T21:25:52Z

"git show 'HEAD:Foo[BAR]Baz'" did not interpret the argument as a rev, i.e. the object named by the the pathname with wildcard characters in a tree object. * nd/dwim-wildcards-as-pathspecs: get_sha1: don't die() on bogus search strings check_filename: tighten dwim-wildcard ambiguity checkout: reorder check_filename conditional

use xmallocz to avoid size arithmetic

2016-02-22T22:51:09Z

We frequently allocate strings as xmalloc(len + 1), where the extra 1 is for the NUL terminator. This can be done more simply with xmallocz, which also checks for integer overflow. There's no case where switching xmalloc(n+1) to xmallocz(n) is wrong; the result is the same length, and malloc made no guarantees about what was in the buffer anyway. But in some cases, we can stop manually placing NUL at the end of the allocated buffer. But that's only safe if it's clear that the contents will always fill the buffer. In each case where this patch does so, I manually examined the control flow, and I tried to err on the side of caution. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'nd/do-not-move-worktree-manually'

2016-02-10T22:20:05Z

"git worktree" had a broken code that attempted to auto-fix possible inconsistency that results from end-users moving a worktree to different places without telling Git (the original repository needs to maintain backpointers to its worktrees, but "mv" run by end-users who are not familiar with that fact will obviously not adjust them), which actually made things worse when triggered. * nd/do-not-move-worktree-manually: worktree: stop supporting moving worktrees manually worktree.c: fix indentation

check_filename: tighten dwim-wildcard ambiguity

2016-02-10T21:53:20Z

When specifying both revisions and pathnames, we allow " -- " to be spelled without the "--" as long as it is not ambiguous. The original logic was something like: 1. Resolve each item with get_sha1(). If successful, we know it can be a . Verify that it _isn't_ a filename, using verify_non_filename(), and complain of ambiguity otherwise. 2. If get_sha1() didn't succeed, make sure that it _is_ a file, using verify_filename(). If not, complain that it is neither a nor a . Both verify_filename() and verify_non_filename() rely on check_filename(), which definitely said "yes, this is a file" or "no, it is not" using lstat(). Commit 28fcc0b (pathspec: avoid the need of "--" when wildcard is used, 2015-05-02) introduced a convenience feature: check_filename() will consider anything with wildcard meta-characters as a possible filename, without even checking the filesystem. This works well for case 2. For such a wildcard, we would previously have died and said "it is neither". Post-28fcc0b, we assume it's a pathspec and proceed. But it makes some instances of case 1 worse. We may have an extended sha1 expression that contains meta-characters (e.g., "HEAD^{/foo.*bar}"), and we now complain that it's also a filename, due to the wildcard characters (even though that wildcard would not match anything in the filesystem). One solution would be to actually expand the pathname and see if it matches anything on the filesystem. But that's potentially expensive, and we do not have to be so rigorous for this DWIM magic (if you want rigor, use "--"). Instead, we can just use different rules for cases 1 and 2. When we know something is a rev, we will complain only if it meets a much higher standard for "this is also a file"; namely that it actually exists in the filesystem. Case 2 remains the same: we use the looser "it could be a filename" standard introduced by 28fcc0b. We can accomplish this by pulling the wildcard logic out of check_filename() and putting it into verify_filename(). Its partner verify_non_filename() does not need a change, since check_filename() goes back to implementing the "higher standard". Besides these two callers of check_filename(), there is one other: git-checkout does a similar DWIM itself. It hits this code path only after get_sha1() has returned failure, making it case 2, which gets the special wildcard treatment. Note that we drop the tests in t2019 in favor of a more complete set in t6133. t2019 was not the right place for them (it's about refname ambiguity, not dwim parsing ambiguity), and the second test explicitly checked for the opposite result of the case we are fixing here (which didn't really make any sense; as shown by the test_must_fail in the test, it would only serve to annoy people). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

clean: make is_git_repository a public function

2016-01-25T19:41:53Z

We have always had is_git_directory(), for looking at a specific directory to see if it contains a git repo. In 0179ca7 (clean: improve performance when removing lots of directories, 2015-06-15), we added is_git_repository() which checks for a non-bare repository by looking at its ".git" entry. However, the fix in 0179ca7 needs to be applied other places, too. Let's make this new helper globally available. We need to give it a better name, though, to avoid confusion with is_git_directory(). This patch does that, documents both functions with a comment to reduce confusion, and removes the clean-specific references in the comments. Based-on-a-patch-by: Andreas Krey Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

worktree: stop supporting moving worktrees manually

2016-01-22T22:28:42Z

The current update_linked_gitdir() has a bug that can create "gitdir" file in non-multi-worktree setup. Worse, sometimes it can write relative path to "gitdir" file, which will not work (e.g. "git worktree list" will display the worktree's location incorrectly) Instead of fixing this, we step back a bit. The original design was probably not well thought out. For now, if the user manually moves a worktree, they have to fix up "gitdir" file manually or the worktree will get pruned. Helped-by: Eric Sunshine Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

Merge branch 'jk/repository-extension'

2015-10-26T22:55:25Z

Prepare for Git on-disk repository representation to undergo backward incompatible changes by introducing a new repository format version "1", with an extension mechanism. * jk/repository-extension: introduce "preciousObjects" repository extension introduce "extensions" form of core.repositoryformatversion