summaryrefslogtreecommitdiff
path: root/setup.c
AgeCommit message (Collapse)AuthorFilesLines
2017-03-28Merge branch 'rs/strbuf-add-real-path' into maintLibravatar Junio C Hamano1-1/+1
An helper function to make it easier to append the result from real_path() to a strbuf has been added. * rs/strbuf-add-real-path: strbuf: add strbuf_add_real_path() cocci: use ALLOC_ARRAY
2017-03-08real_pathdup(): fix callsites that wanted it to die on errorLibravatar Johannes Schindelin1-2/+2
In 4ac9006f832 (real_path: have callers use real_pathdup and strbuf_realpath, 2016-12-12), we changed the xstrdup(real_path()) pattern to use real_pathdup() directly. The problem with this change is that real_path() calls strbuf_realpath() with die_on_error = 1 while real_pathdup() calls it with die_on_error = 0. Meaning that in cases where real_path() causes Git to die() with an error message, real_pathdup() is silent and returns NULL instead. The callers, however, are ill-prepared for that change, as they expect the return value to be non-NULL (and otherwise the function died with an appropriate error message). Fix this by extending real_pathdup()'s signature to accept the die_on_error flag and simply pass it through to strbuf_realpath(), and then adjust all callers after a careful audit whether they would handle NULLs well. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-27strbuf: add strbuf_add_real_path()Libravatar René Scharfe1-1/+1
Add a function for appending the canonized absolute pathname of a given path to a strbuf. It keeps the existing contents intact, as expected of a function of the strbuf_add() family, while avoiding copying the result if the given strbuf is empty. It's more consistent with the rest of the strbuf API than strbuf_realpath(), which it's wrapping. Also add a semantic patch demonstrating its intended usage and apply it to the current tree. Using strbuf_add_real_path() instead of calling strbuf_addstr() and real_path() avoids an extra copy to a static buffer. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-26cache.h: expose the dying procedure for reading gitlinksLibravatar Stefan Beller1-22/+26
In a later patch we want to react to only a subset of errors, defaulting the rest to die as usual. Separate the block that takes care of dying into its own function so we have easy access to it. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-26setup: add gentle version of resolve_git_dirLibravatar Stefan Beller1-2/+2
This follows a93bedada (setup: add gentle version of read_gitfile, 2015-06-09), and assumes the same reasoning. resolve_git_dir is unsuited for speculative calls, so we want to use the gentle version to find out about potential errors. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-12real_path: have callers use real_pathdup and strbuf_realpathLibravatar Brandon Williams1-5/+8
Migrate callers of real_path() who duplicate the retern value to use real_pathdup or strbuf_realpath. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-09i18n: setup: mark error messages for translationLibravatar Vasco Almeida1-9/+9
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17i18n: setup: mark strings for translationLibravatar Vasco Almeida1-8/+8
Update tests that compare the strings newly marked for translation to succeed when running under GETTEXT_POISON. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-22Merge branch 'jc/xstrfmt-null-with-prec-0'Libravatar Junio C Hamano1-1/+1
* jc/xstrfmt-null-with-prec-0: setup.c: do not feed NULL to "%.*s" even with precision 0
2016-04-13Merge branch 'jk/check-repository-format'Libravatar Junio C Hamano1-66/+78
The repository set-up sequence has been streamlined (the biggest change is that there is no longer git_config_early()), so that we do not attempt to look into refs/* when we know we do not have a Git repository. * jk/check-repository-format: verify_repository_format: mark messages for translation setup: drop repository_format_version global setup: unify repository version callbacks init: use setup.c's repo version verification setup: refactor repo format reading and verification config: drop git_config_early check_repository_format_gently: stop using git_config_early lazily load core.sharedrepository wrap shared_repository global in get/set accessors setup: document check_repository_format()
2016-04-07setup.c: do not feed NULL to "%.*s" even with precision 0Libravatar Junio C Hamano1-1/+1
A recent update 75faa45a (replace trivial malloc + sprintf / strcpy calls with xstrfmt, 2015-09-24) rewrote prepare an empty buffer if (len) append the first len bytes of "prefix" to the buffer append "path" to the buffer that computed "path", optionally prefixed by "prefix", into xstrfmt("%.*s%s", len, prefix, path); However, passing a NULL pointer to the printf(3) family of functions to format it with %s conversion, even with the precision set to 0, i.e. xstrfmt("%.*s", 0, NULL) yields undefined results, at least on some platforms. Avoid this problem by substituting prefix with "" when len==0, as prefix can legally be NULL in that case. This would mimick the intent of the original code better. Reported-by: Tom G. Christensen <tgc@jupiterrise.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-11verify_repository_format: mark messages for translationLibravatar Jeff King1-2/+2
These messages are human-readable and should be translated. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-11setup: drop repository_format_version globalLibravatar Jeff King1-1/+0
Nobody reads this anymore, and they're not likely to; the interesting thing is whether or not we passed check_repository_format(), and possibly the individual "extension" variables. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-11setup: unify repository version callbacksLibravatar Jeff King1-42/+23
Once upon a time, check_repository_format_gently would parse the config with a single callback, and that callback would set up a bunch of global variables. But now that we have separate workdirs, we have to be more careful. Commit 31e26eb (setup.c: support multi-checkout repo setup, 2014-11-30) introduced a reduced callback which omits some values like core.worktree. In the "main" callback we call the reduced one, and then add back in the missing variables. Now that we have split the config-parsing from the munging of the global variables, we can do it all with a single callback, and keep all of the "are we in a separate workdir" logic together. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-11setup: refactor repo format reading and verificationLibravatar Jeff King1-39/+79
When we want to know if we're in a git repository of reasonable vintage, we can call check_repository_format_gently(), which does three things: 1. Reads the config from the .git/config file. 2. Verifies that the version info we read is sane. 3. Writes some global variables based on this. There are a few things we could improve here. One is that steps 1 and 3 happen together. So if the verification in step 2 fails, we still clobber the global variables. This is especially bad if we go on to try another repository directory; we may end up with a state of mixed config variables. The second is there's no way to ask about the repository version for anything besides the main repository we're in. git-init wants to do this, and it's possible that we would want to start doing so for submodules (e.g., to find out which ref backend they're using). We can improve both by splitting the first two steps into separate functions. Now check_repository_format_gently() calls out to steps 1 and 2, and does 3 only if step 2 succeeds. Note that the public interface for read_repository_format() and what check_repository_format_gently() needs from it are not quite the same, leading us to have an extra read_repository_format_1() helper. The extra needs from check_repository_format_gently() will go away in a future patch, and we can simplify this then to just the public interface. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-11check_repository_format_gently: stop using git_config_earlyLibravatar Jeff King1-8/+3
There's a chicken-and-egg problem with using the regular git_config during the repository setup process. We get around it here by using a special interface that lets us specify the per-repo config, and avoid calling git_pathdup(). But this interface doesn't actually make sense. It will look in the system and per-user config, too; we definitely would not want to accept a core.repositoryformatversion from there. The git_config_from_file interface is a better match, as it lets us look at a single file. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-11lazily load core.sharedrepositoryLibravatar Jeff King1-2/+0
The "shared_repository" config is loaded as part of check_repository_format_version, but it's not quite like the other values we check there. Something like core.repositoryformatversion only makes sense in per-repo config, but core.sharedrepository can be set in a per-user config (e.g., to make all "git init" invocations shared by default). So it would make more sense as part of git_default_config. Commit 457f06d (Introduce core.sharedrepository, 2005-12-22) says: [...]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. This is still the case today, but we have one extra trick up our sleeve. Now that we have the git_configset infrastructure, it's not so expensive for us to ask for a single value. So we can simply lazy-load it on demand. This should be OK to do in general. There are some problems with loading config before setup_git_directory() is called, but we shouldn't be accessing the value before then (if we were, then it would already be broken, as the variable would not have been set by check_repository_format_version!). The trickiest caller is git-init, but it handles the values manually itself. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-11wrap shared_repository global in get/set accessorsLibravatar Jeff King1-1/+1
It would be useful to control access to the global shared_repository, so that we can lazily load its config. The first step to doing so is to make sure all access goes through a set of functions. This step is purely mechanical, and should result in no change of behavior. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-11setup: document check_repository_format()Libravatar Jeff King1-2/+2
This function's interface is rather enigmatic, so let's document it further. While we're here, let's also drop the return value. It will always either be "0" or the function will die (consequently, neither of its two callers bothered to check the return). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-06setup: set startup_info->have_repository more reliablyLibravatar Jeff King1-1/+3
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-06setup: make startup_info available everywhereLibravatar Jeff King1-4/+6
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-26Merge branch 'jk/tighten-alloc'Libravatar Junio C Hamano1-3/+2
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 ...
2016-02-24Merge branch 'nd/dwim-wildcards-as-pathspecs'Libravatar Junio C Hamano1-4/+2
"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
2016-02-22use xmallocz to avoid size arithmeticLibravatar Jeff King1-3/+2
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-10Merge branch 'nd/do-not-move-worktree-manually'Libravatar Junio C Hamano1-12/+0
"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
2016-02-10check_filename: tighten dwim-wildcard ambiguityLibravatar Jeff King1-4/+2
When specifying both revisions and pathnames, we allow "<rev> -- <pathspec>" 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 <rev>. 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 <rev> nor a <pathspec>. 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-25clean: make is_git_repository a public functionLibravatar Jeff King1-0/+17
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 <a.krey@gmx.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-22worktree: stop supporting moving worktrees manuallyLibravatar Nguyễn Thái Ngọc Duy1-12/+0
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 <sunshine@sunshineco.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-26Merge branch 'jk/repository-extension'Libravatar Junio C Hamano1-3/+36
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
2015-10-20Merge branch 'jk/war-on-sprintf'Libravatar Junio C Hamano1-9/+3
Many allocations that is manually counted (correctly) that are followed by strcpy/sprintf have been replaced with a less error prone constructs such as xstrfmt. Macintosh-specific breakage was noticed and corrected in this reroll. * jk/war-on-sprintf: (70 commits) name-rev: use strip_suffix to avoid magic numbers use strbuf_complete to conditionally append slash fsck: use for_each_loose_file_in_objdir Makefile: drop D_INO_IN_DIRENT build knob fsck: drop inode-sorting code convert strncpy to memcpy notes: document length of fanout path with a constant color: add color_set helper for copying raw colors prefer memcpy to strcpy help: clean up kfmclient munging receive-pack: simplify keep_arg computation avoid sprintf and strcpy with flex arrays use alloc_ref rather than hand-allocating "struct ref" color: add overflow checks for parsing colors drop strcpy in favor of raw sha1_to_hex use sha1_to_hex_r() instead of strcpy daemon: use cld->env_array when re-spawning stat_tracking_info: convert to argv_array http-push: use an argv_array for setup_revisions fetch-pack: use argv_array for index-pack / unpack-objects ...
2015-09-25replace trivial malloc + sprintf / strcpy calls with xstrfmtLibravatar Jeff King1-9/+3
It's a common pattern to do: foo = xmalloc(strlen(one) + strlen(two) + 1 + 1); sprintf(foo, "%s %s", one, two); (or possibly some variant with strcpy()s or a more complicated length computation). We can switch these to use xstrfmt, which is shorter, involves less error-prone manual computation, and removes many sprintf and strcpy calls which make it harder to audit the code for real buffer overflows. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-14path: implement common_dir handling in git_pathdup_submodule()Libravatar Max Kirillov1-5/+12
When submodule is a linked worktree, "git diff --submodule" and other calls which directly access the submodule's object database do not correctly calculate its path. Fix it by changing the git_pathdup_submodule() behavior, to use either common or per-worktree directory. Do it similarly as for parent repository, but ignore the GIT_COMMON_DIR environment variable, because it would mean common directory for the parent repository and does not make sense for submodule. Also add test for functionality which uses this call. Signed-off-by: Max Kirillov <max@max630.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-01Merge branch 'nd/fixup-linked-gitdir'Libravatar Junio C Hamano1-2/+2
The code in "multiple-worktree" support that attempted to recover from an inconsistent state updated an incorrect file. * nd/fixup-linked-gitdir: setup: update the right file in multiple checkouts
2015-08-25write_file(): drop caller-supplied LF from calls to create a one-liner fileLibravatar Junio C Hamano1-1/+1
All of the callsites covered by this change call write_file() or write_file_gently() to create a one-liner file. Drop the caller supplied LF and let these callees to append it as necessary. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-25setup: update the right file in multiple checkoutsLibravatar Nguyễn Thái Ngọc Duy1-2/+2
This code is introduced in 23af91d (prune: strategies for linked checkouts - 2014-11-30), and it's supposed to implement this rule from that commit's message: - linked checkouts are supposed to keep its location in $R/gitdir up to date. The use case is auto fixup after a manual checkout move. Note the name, "$R/gitdir", not "$R/gitfile". Correct the path to be updated accordingly. While at there, make sure I/O errors are not silently dropped. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-24write_file(): drop "fatal" parameterLibravatar Junio C Hamano1-1/+1
All callers except three passed 1 for the "fatal" parameter to ask this function to die upon error, but to a casual reader of the code, it was not all obvious what that 1 meant. Instead, split the function into two based on a common write_file_v() that takes the flag, introduce write_file_gently() as a new way to attempt creating a file without dying on error, and make three callers to call it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-03Merge branch 'ee/clean-remove-dirs'Libravatar Junio C Hamano1-20/+69
Replace "is this subdirectory a separate repository that should not be touched?" check "git clean" does by checking if it has .git/HEAD using the submodule-related code with a more optimized check. * ee/clean-remove-dirs: read_gitfile_gently: fix use-after-free clean: improve performance when removing lots of directories p7300: add performance tests for clean t7300: add tests to document behavior of clean and nested git setup: sanity check file size in read_gitfile_gently setup: add gentle version of read_gitfile
2015-06-26read_gitfile_gently: fix use-after-freeLibravatar Jeff King1-9/+5
The "dir" variable is a pointer into the "buf" array. When we hit the cleanup_return path, the first thing we do is free(buf); but one of the error messages prints "dir", which will access the memory after the free. We can fix this by reorganizing the error path a little. We act on the fatal, error-printing conditions first, as they want to access memory and do not care about freeing. Then we free any memory, and finally return. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-24introduce "preciousObjects" repository extensionLibravatar Jeff King1-0/+2
If this extension is used in a repository, then no operations should run which may drop objects from the object storage. This can be useful if you are sharing that storage with other repositories whose refs you cannot see. For instance, if you do: $ git clone -s parent child $ git -C parent config extensions.preciousObjects true $ git -C parent config core.repositoryformatversion 1 you now have additional safety when running git in the parent repository. Prunes and repacks will bail with an error, and `git gc` will skip those operations (it will continue to pack refs and do other non-object operations). Older versions of git, when run in the repository, will fail on every operation. Note that we do not set the preciousObjects extension by default when doing a "clone -s", as doing so breaks backwards compatibility. It is a decision the user should make explicitly. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-24introduce "extensions" form of core.repositoryformatversionLibravatar Jeff King1-3/+34
Normally we try to avoid bumps of the whole-repository core.repositoryformatversion field. However, it is unavoidable if we want to safely change certain aspects of git in a backwards-incompatible way (e.g., modifying the set of ref tips that we must traverse to generate a list of unreachable, safe-to-prune objects). If we were to bump the repository version for every such change, then any implementation understanding version `X` would also have to understand `X-1`, `X-2`, and so forth, even though the incompatibilities may be in orthogonal parts of the system, and there is otherwise no reason we cannot implement one without the other (or more importantly, that the user cannot choose to use one feature without the other, weighing the tradeoff in compatibility only for that particular feature). This patch documents the existing repositoryformatversion strategy and introduces a new format, "1", which lets a repository specify that it must run with an arbitrary set of extensions. This can be used, for example: - to inform git that the objects should not be pruned based only on the reachability of the ref tips (e.g, because it has "clone --shared" children) - that the refs are stored in a format besides the usual "refs" and "packed-refs" directories Because we bump to format "1", and because format "1" requires that a running git knows about any extensions mentioned, we know that older versions of the code will not do something dangerous when confronted with these new formats. For example, if the user chooses to use database storage for refs, they may set the "extensions.refbackend" config to "db". Older versions of git will not understand format "1" and bail. Versions of git which understand "1" but do not know about "refbackend", or which know about "refbackend" but not about the "db" backend, will refuse to run. This is annoying, of course, but much better than the alternative of claiming that there are no refs in the repository, or writing to a location that other implementations will not read. Note that we are only defining the rules for format 1 here. We do not ever write format 1 ourselves; it is a tool that is meant to be used by users and future extensions to provide safety with older implementations. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-16Merge branch 'jk/die-on-bogus-worktree-late'Libravatar Junio C Hamano1-2/+10
The setup code used to die when core.bare and core.worktree are set inconsistently, even for commands that do not need working tree. * jk/die-on-bogus-worktree-late: setup_git_directory: delay core.bare/core.worktree errors
2015-06-15setup: sanity check file size in read_gitfile_gentlyLibravatar Erik Elfström1-0/+7
read_gitfile_gently will allocate a buffer to fit the entire file that should be read. Add a sanity check of the file size before opening to avoid allocating a potentially huge amount of memory if we come across a large file that someone happened to name ".git". The limit is set to a sufficiently unreasonable size that should never be exceeded by a genuine .git file. Signed-off-by: Erik Elfström <erik.elfstrom@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-09setup: add gentle version of read_gitfileLibravatar Erik Elfström1-19/+65
read_gitfile will die on most error cases. This makes it unsuitable for speculative calls. Extract the core logic and provide a gentle version that returns NULL on failure. The first usecase of the new gentle version will be to probe for submodules during git clean. Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Erik Elfström <erik.elfstrom@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-29setup_git_directory: delay core.bare/core.worktree errorsLibravatar Jeff King1-2/+10
If both core.bare and core.worktree are set, we complain about the bogus config and die. Dying is good, because it avoids commands running and doing damage in a potentially incorrect setup. But dying _there_ is bad, because it means that commands which do not even care about the work tree cannot run. This can make repairing the situation harder: [setup] $ git config core.bare true $ git config core.worktree /some/path [OK, expected.] $ git status fatal: core.bare and core.worktree do not make sense [Hrm...] $ git config --unset core.worktree fatal: core.bare and core.worktree do not make sense [Nope...] $ git config --edit fatal: core.bare and core.worktree do not make sense [Gaaah.] $ git help config fatal: core.bare and core.worktree do not make sense Instead, let's issue a warning about the bogus config when we notice it (i.e., for all commands), but only die when the command tries to use the work tree (by calling setup_work_tree). So we now get: $ git status warning: core.bare and core.worktree do not make sense fatal: unable to set up work tree using invalid config $ git config --unset core.worktree warning: core.bare and core.worktree do not make sense We have to update t1510 to accomodate this; it uses symbolic-ref to check whether the configuration works or not, but of course that command does not use the working tree. Instead, we switch it to use `git status`, as it requires a work-tree, does not need any special setup, and is read-only (so a failure will not adversely affect further tests). In addition, we add a new test that checks the desired behavior (i.e., that running "git config" with the bogus config does in fact work). Reported-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-19Merge branch 'nd/dwim-wildcards-as-pathspecs'Libravatar Junio C Hamano1-1/+3
A heuristic to help the "git <cmd> <revs> <pathspec>" command line convention to catch mistyped paths is to make sure all the non-rev parameters in the later part of the command line are names of the files in the working tree, but that means "git grep $str -- \*.c" must always be disambiguated with "--", because nobody sane will create a file whose name literally is asterisk-dot-see. Loosen the heuristic to declare that with a wildcard string the user likely meant to give us a pathspec. * nd/dwim-wildcards-as-pathspecs: pathspec: avoid the need of "--" when wildcard is used
2015-05-03pathspec: avoid the need of "--" when wildcard is usedLibravatar Duy Nguyen1-1/+3
When "--" is lacking from the command line and a command can take both revs and paths, the idea is if an argument can be seen as both an extended SHA-1 and a path, then "--" is required or git refuses to continue. It's currently implemented as: (1) if an argument is rev, then it must not exist in worktree (2) else, it must exist in worktree (3) else, "--" is required. These rules work for literal paths, but when non-literal pathspec is involved, it almost always requires the user to add "--" because it fails (2) and (1) is really rarely met (take "*.c" for example, (1) is met if there is a ref named "*.c"). This patch modifies the rules a bit by considering any valid (*) wildcard pathspec "exist in worktree". The rules become: (1) if an arg is a rev, then it must either exist in worktree or not be a valid wildcard pathspec. (2) else, it either exists in worktree or is a wildcard pathspec (3) else, "--" is required. With the new rules, "--" is not needed most of the time when wildcard pathspec is involved. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-01prune: strategies for linked checkoutsLibravatar Nguyễn Thái Ngọc Duy1-0/+13
(alias R=$GIT_COMMON_DIR/worktrees/<id>) - linked checkouts are supposed to keep its location in $R/gitdir up to date. The use case is auto fixup after a manual checkout move. - linked checkouts are supposed to update mtime of $R/gitdir. If $R/gitdir's mtime is older than a limit, and it points to nowhere, worktrees/<id> is to be pruned. - If $R/locked exists, worktrees/<id> is not supposed to be pruned. If $R/locked exists and $R/gitdir's mtime is older than a really long limit, warn about old unused repo. - "git checkout --to" is supposed to make a hard link named $R/link pointing to the .git file on supported file systems to help detect the user manually deleting the checkout. If $R/link exists and its link count is greated than 1, the repo is kept. Helped-by: Marc Branchaud <marcnarc@xiplink.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Marc Branchaud <marcnarc@xiplink.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-01setup.c: support multi-checkout repo setupLibravatar Nguyễn Thái Ngọc Duy1-9/+24
The repo setup procedure is updated to detect $GIT_DIR/commondir and set $GIT_COMMON_DIR properly. The core.worktree is ignored when $GIT_COMMON_DIR is set. This is because the config file is shared in multi-checkout setup, but checkout directories _are_ different. Making core.worktree effective in all checkouts mean it's back to a single checkout. Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-01setup.c: detect $GIT_COMMON_DIR check_repository_format_gently()Libravatar Nguyễn Thái Ngọc Duy1-2/+4
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-01setup.c: convert check_repository_format_gently to use strbufLibravatar Nguyễn Thái Ngọc Duy1-4/+8
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>