- 23 3月, 2016 1 次提交
-
-
由 Stefan Beller 提交于
Per Cederqvist wrote: > It used to be possible to run > > git submodule deinit -f . > > to remove any submodules, no matter how many submodules you had. That > is no longer possible in projects that don't have any submodules at > all. The command will fail with: > > error: pathspec '.' did not match any file(s) known to git. This regression was introduced in 74703a1e (submodule: rewrite `module_list` shell function in C, 2015-09-02), as we changed the order of checking in new module listing to first check whether it is a gitlin before feeding it to match_pathspec(). It used to be that a pathspec that does not match any path were diagnosed as an error, but the new code complains for a pathspec that does not match any submodule path. Arguably the new behaviour may give us a better diagnosis, but that is inconsistent with the suggestion "deinit" gives, and also this was an unintended accident. The new behaviour hopefully can be redesigned and implemented better in future releases, but for now, switch these two checks to restore the same behavior as before. In an empty repository, giving the pathspec '.' will still get the same "did not match" error, but that is the same bug we had before 1.7.0. Reported-by: NPer Cederqvist <cederp@opera.com> Signed-off-by: NStefan Beller <sbeller@google.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 3月, 2016 1 次提交
-
-
由 Sven Strickroth 提交于
When concluding a conflicted "git merge --squash", the command failed to read SQUASH_MSG that was prepared by "git merge", and showed only the "# Conflicts:" list of conflicted paths. Place the contents from SQUASH_MSG at the beginning, just like we show the commit log skeleton first when concluding a normal merge, and then show the "# Conflicts:" list, to help the user write the log message for the resulting commit. Test by Junio C Hamano <gitster@pobox.com>. Signed-off-by: NSven Strickroth <sven@cs-ware.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 3月, 2016 2 次提交
-
-
由 Jeff King 提交于
When we find a blob at "a/b/c", we currently pass this to our show_object_fn callbacks as two components: "a/b/" and "c". Callbacks which want the full value then call path_name(), which concatenates the two. But this is an inefficient interface; the path is a strbuf, and we could simply append "c" to it temporarily, then roll back the length, without creating a new copy. So we could improve this by teaching the callsites of path_name() this trick (and there are only 3). But we can also notice that no callback actually cares about the broken-down representation, and simply pass each callback the full path "a/b/c" as a string. The callback code becomes even simpler, then, as we do not have to worry about freeing an allocated buffer, nor rolling back our modification to the strbuf. This is theoretically less efficient, as some callbacks would not bother to format the final path component. But in practice this is not measurable. Since we use the same strbuf over and over, our work to grow it is amortized, and we really only pay to memcpy a few bytes. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
In the previous commit, we left name_path as a thin wrapper around a strbuf. This patch drops it entirely. As a result, every show_object_fn callback needs to be adjusted. However, none of their code needs to be changed at all, because the only use was to pass it to path_name(), which now handles the bare strbuf. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 3月, 2016 1 次提交
-
-
由 Jeff King 提交于
If we are running "git grep --no-index" outside of a git repository, we behave roughly like "grep -r", examining all files in the current directory and its subdirectories. However, because we use fill_directory() to do the recursion, it will skip over any directories which look like sub-repositories. For a normal git operation (like "git grep" in a repository) this makes sense; we do not want to cross the boundary out of our current repository into a submodule. But for "--no-index" without a repository, we should look at all files, including embedded repositories. There is one exception, though: we probably should _not_ descend into ".git" directories. Doing so is inefficient and unlikely to turn up useful hits. This patch drops our use of dir.c's gitlink-detection, but we do still avoid ".git". That makes us more like tools such as "ack" or "ag", which also know to avoid cruft in .git. As a bonus, this also drops our usage of the ref code when we are outside of a repository, making the transition to pluggable ref backends cleaner. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 3月, 2016 1 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 3月, 2016 2 次提交
-
-
由 Junio C Hamano 提交于
These are automatically named by replacing .pack suffix in the name of the packfile. Add a small helper to do so, as I'll be adding another one soonish. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
When 592ce208 (index-pack: use strip_suffix to avoid magic numbers, 2014-06-30) refactored the code to derive names of .idx and .keep files from the name of .pack file, a copy-and-paste typo crept in, mistakingly attempting to create and store the keep message file in the .idx file we just created, instead of .keep file. As we create the .keep file with O_CREAT|O_EXCL, and we do so after we write the .idx file, we luckily do not clobber the .idx file, but because we deliberately ignored EEXIST when creating .keep file (which is justifiable because only the existence of .keep file matters), nobody noticed this mistake so far. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 3月, 2016 1 次提交
-
-
由 Gabriel Souza Franco 提交于
Commit 58f2ed05 (remote-curl: pass ref SHA-1 to fetch-pack as well, 2013-12-05) added support for specifying a SHA-1 as well as a ref name. Add support for specifying just a SHA-1 and set the ref name to the same value in this case. Signed-off-by: NGabriel Souza Franco <gabrielfrancosouza@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 3月, 2016 3 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
Once upon a time, you could use "--local-env-vars" and "--resolve-git-dir" outside of any git repository, but they had to come first on the command line. Commit 68889b41 (rev-parse: remove restrictions on some options, 2013-07-21) put them into the normal option-parsing loop, fixing the latter. But it inadvertently broke the former, as we call setup_git_directory() before starting that loop. We can note that those options don't care even conditionally about whether we are in a git repo. So it's fine if we simply wait to setup the repo until we see an option that needs it. However, there is one special exception we should make: historically, rev-parse will set up the repository and read config even if there are _no_ options. Some of the tests in t1300 rely on this to check "git -c $config" parsing. That's not mirroring real-world use, and we could tweak the test. But t0002 uses a bare "git rev-parse" to check "are we in a git repository?". It's plausible that real-world scripts are relying on this. So let's cover this case specially, and treat an option-less "rev-parse" as "see if we're in a repo". Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 2月, 2016 1 次提交
-
-
由 John Keeping 提交于
The --get, --get-all and --get-regexp options to git-config exit with status 1 if the key is not found but --get-urlmatch succeeds in this case. Change --get-urlmatch to behave in the same way as the other --get* options so that all four are consistent. --get-color is a special case because it accepts a default value to return and so should not return an error if the key is not found. Also clarify this behaviour in the documentation. Signed-off-by: NJohn Keeping <john@keeping.me.uk> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 2月, 2016 3 次提交
-
-
由 Jeff King 提交于
If a pack .idx file has a corrupted offset for an object, we may try to access an offset in the .idx or .pack file that is larger than the file's size. For the .pack case, we have use_pack() to protect us, which realizes the access is out of bounds. But if the corrupted value asks us to look in the .idx file's secondary 64-bit offset table, we blindly add it to the mmap'd index data and access arbitrary memory. We can fix this with a simple bounds-check compared to the size we found when we opened the .idx file. Note that there's similar code in index-pack that is triggered only during "index-pack --verify". To support both, we pull the bounds-check into a separate function, which dies when it sees a corrupted file. It would be nice if we could return an error, so that the pack code could try to find a good copy of the object elsewhere. Currently nth_packed_object_offset doesn't have any way to return an error, but it could probably use "0" as a sentinel value (since no object can start there). This is the minimal fix, and we can improve the resilience later on top. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
It is a pilot error to call `git config section.key value` outside of any Git worktree. The message error: could not lock config file .git/config: No such file or directory is not very helpful in that situation, though. Let's print a helpful message instead. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Matthieu Moy 提交于
The warning was important before the 2.0 transition, and remained important for a while after, so that new users get push.default explicitly in their configuration and do not experience inconsistent behavior if they ever used an older version of Git. The warning has been there since version 1.8.0 (Oct 2012), hence we can expect the vast majority of current Git users to have been exposed to it, and most of them have already set push.default explicitly. The switch from 'matching' to 'simple' was planned for 2.0 (May 2014), but actually happened only for 2.3 (Feb 2015). Today, the warning is mostly seen by beginners, who have not set their push.default configuration (yet). For many of them, the warning is confusing because it talks about concepts that they have not learned and asks them a choice that they are not able to make yet. See for example http://stackoverflow.com/questions/13148066/warning-push-default-is-unset-its-implicit-value-is-changing-in-git-2-0 (1260 votes for the question, 1824 for the answer as of writing) Remove the warning completely to avoid disturbing beginners. People who still occasionally use an older version of Git will be exposed to the warning through this old version. Eventually, versions of Git without the warning will be deployed enough and tutorials will not need to advise setting push.default anymore. Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 2月, 2016 1 次提交
-
-
由 Stefan Beller 提交于
This is a regression introduced by 74703a1e (submodule: rewrite `module_list` shell function in C, 2015-09-02). Add a test to ensure we list the right submodule when giving a specific pathspec. Reported-By: NCaleb Jorden <cjorden@gmail.com> Signed-off-by: NStefan Beller <sbeller@google.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 2月, 2016 17 次提交
-
-
由 Jeff King 提交于
We have two variants of this function, one that takes a string and one that takes a ptr/len combo. But we only call the latter with the length of a NUL-terminated string, so our first simplification is to drop it in favor of the string variant. Since we know we have a string, we can also replace the manual memory computation with a call to alloc_ref(). Furthermore, we can rely on get_oid_hex() to complain if it hits the end of the string. That means we can simplify the check for "<sha1> <ref>" versus just "<ref>". Rather than manage the ptr/len pair, we can just bump the start of our string forward. The original code over-allocated based on the original "namelen" (which wasn't _wrong_, but was simply wasteful and confusing). Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
If our size computation overflows size_t, we may allocate a much smaller buffer than we expected and overflow it. It's probably impossible to trigger an overflow in most of these sites in practice, but it is easy enough convert their additions and multiplications into overflow-checking variants. This may be fixing real bugs, and it makes auditing the code easier. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
Using FLEX_ARRAY macros reduces the amount of manual computation size we have to do. It also ensures we don't overflow size_t, and it makes sure we write the same number of bytes that we allocated. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
Each of these cases can be converted to use ALLOC_ARRAY or REALLOC_ARRAY, which has two advantages: 1. It automatically checks the array-size multiplication for overflow. 2. It always uses sizeof(*array) for the element-size, so that it can never go out of sync with the declared type of the array. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
There are many manual argv allocations that predate the argv_array API. Switching to that API brings a few advantages: 1. We no longer have to manually compute the correct final array size (so it's one less thing we can screw up). 2. In many cases we had to make a separate pass to count, then allocate, then fill in the array. Now we can do it in one pass, making the code shorter and easier to follow. 3. argv_array handles memory ownership for us, making it more obvious when things should be free()d and and when not. Most of these cases are pretty straightforward. In some, we switch from "run_command_v" to "run_command" which lets us directly use the argv_array embedded in "struct child_process". Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Patrick Steinhardt 提交于
Rename git_config_set_or_die functions to git_config_set, leading to the new default behavior of dying whenever a configuration error occurs. By now all callers that shall die on error have been transitioned to the _or_die variants, thus making this patch a simple rename of the functions. Signed-off-by: NPatrick Steinhardt <ps@pks.im> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Patrick Steinhardt 提交于
The desired default behavior for `git_config_set` is to die whenever an error occurs. Dying is the default for a lot of internal functions when failures occur and is in this case the right thing to do for most callers as otherwise we might run into inconsistent repositories without noticing. As some code may rely on the actual return values for `git_config_set` we still require the ability to invoke these functions without aborting. Rename the existing `git_config_set` functions to `git_config_set_gently` to keep them available for those callers. Signed-off-by: NPatrick Steinhardt <ps@pks.im> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Patrick Steinhardt 提交于
When creating an empty repository with `git init-db` we do not check for error codes returned by `git_config_set` functions. This may cause the user to end up with an inconsistent repository without any indication for the user. Fix this problem by dying early with an error message when we are unable to write the configuration files to disk. Signed-off-by: NPatrick Steinhardt <ps@pks.im> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Patrick Steinhardt 提交于
The clone command does not check for error codes returned by `git_config_set` functions. This may cause the user to end up with an inconsistent repository without any indication with what went wrong. Fix this problem by dying with an error message when we are unable to write the configuration files to disk. Signed-off-by: NPatrick Steinhardt <ps@pks.im> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Patrick Steinhardt 提交于
When manipulating remotes we try to set various configuration values without checking if the values were persisted correctly, possibly leaving the remote in an inconsistent state. Fix this issue by dying early and notifying the user about the error. Signed-off-by: NPatrick Steinhardt <ps@pks.im> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Patrick Steinhardt 提交于
When we add or set new branches (e.g. by `git remote add -f` or `git remote set-branches`) we do not check for error codes when writing the branches to the configuration file. When persisting the configuration failed we are left with a remote that has none or not all of the branches that should have been set without notifying the user. Fix this issue by dying early on configuration error. Signed-off-by: NPatrick Steinhardt <ps@pks.im> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Patrick Steinhardt 提交于
When invoking `git-remote --set-url` we do not check the return value when writing the actual new URL to the configuration file, pretending to the user that the configuration has been set while it was in fact not persisted. Fix this problem by dying early when setting the config fails. Signed-off-by: NPatrick Steinhardt <ps@pks.im> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Patrick Steinhardt 提交于
When setting the 'core.worktree' option for a newly cloned submodule we ignore the return value of `git_config_set_in_file`. As this leaves the submodule in an inconsistent state, we instead want to inform the user that something has gone wrong by printing an error and aborting the program. Signed-off-by: NPatrick Steinhardt <ps@pks.im> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Patrick Steinhardt 提交于
Signed-off-by: NPatrick Steinhardt <ps@pks.im> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Patrick Steinhardt 提交于
When we try to unset upstream configurations we do not check return codes for the `git_config_set` functions. As those may indicate that we were unable to unset the respective configuration we may exit successfully without any error message while in fact the upstream configuration was not unset. Fix this by dying with an error message when we cannot unset the configuration. Signed-off-by: NPatrick Steinhardt <ps@pks.im> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Lars Schneider 提交于
If config values are queried using 'git config' (e.g. via --get, --get-all, --get-regexp, or --list flag) then it is sometimes hard to find the configuration file where the values were defined. Teach 'git config' the '--show-origin' option to print the source configuration file for every printed value. Based-on-patch-by: NJeff King <peff@peff.net> Signed-off-by: NLars Schneider <larsxschneider@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 2月, 2016 1 次提交
-
-
由 Jeff King 提交于
You can tweak the reflog expiration for a particular subset of refs by configuring gc.foo.reflogexpire. We keep a linked list of reflog_expire_cfg structs, each of which holds the pattern and a "len" field for the length of the pattern. The pattern itself is _not_ NUL-terminated. However, we feed the pattern directly to wildmatch(), which expects a NUL-terminated string, meaning it may keep reading random junk after our struct. We can fix this by allocating an extra byte for the NUL (which is already zero because we use xcalloc). Let's also drop the misleading "len" field, which is no longer necessary. The existing use of "len" can be converted to use strncmp(). Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 2月, 2016 1 次提交
-
-
由 Junio C Hamano 提交于
The 'v'iew subcommand of the interactive mode of "git am -i" was broken by the rewrite to C we did at around 2.6.0 timeframe at 7ff26832 (builtin-am: implement -i/--interactive, 2015-08-04); we used to spawn the pager via the shell, accepting things like PAGER='less -S' in the environment, but the rewrite forgot and tried to directly spawn a command whose name is the entire string. The previous refactoring of the new helper function makes it easier for us to do the right thing. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 2月, 2016 3 次提交
-
-
由 Thomas Gummerer 提交于
Both remote add and remote rename use a slightly different hand-rolled check if the remote exits. The hand-rolled check may have some subtle cases in which it might fail to detect when a remote already exists. One such case was fixed in fb86e32d ("git remote: allow adding remotes agreeing with url.<...>.insteadOf"). Another case is when a remote is configured as follows: [remote "foo"] vcs = bar If we try to run `git remote add foo bar` with the above remote configuration, git segfaults. This change fixes it. In addition, git remote rename $existing foo with the configuration for foo as above silently succeeds, even though foo already exists, modifying its configuration. With this patch it fails with "remote foo already exists". Signed-off-by: NThomas Gummerer <t.gummerer@gmail.com> Reviewed-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Thomas Gummerer 提交于
When converting the git remote command to a builtin in 211c89 ("Make git-remote a builtin"), a few calls to check if a remote exists were converted from: if (!exists $remote->{$name}) { [...] to: remote = remote_get(argv[1]); if (!remote) [...] The new check is not quite correct, because remote_get() never returns NULL if a name is given. This leaves us with the somewhat cryptic error message "error: Could not remove config section 'remote.test'", if we are trying to remove a remote that does not exist, or a similar error if we try to rename a remote. Use the remote_is_configured() function to check whether the remote actually exists, and die with a more sensible error message ("No such remote: $remotename") instead if it doesn't. Signed-off-by: NThomas Gummerer <t.gummerer@gmail.com> Reviewed-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Thomas Gummerer 提交于
The remote_is_configured() function allows checking whether a remote exists or not. The function however only works if remote_get() wasn't called before calling it. In addition, it only checks the configuration for remotes, but not remotes or branches files. Make use of the origin member of struct remote instead, which indicates where the remote comes from. It will be set to some value if the remote is configured in any file in the repository, but is initialized to 0 if the remote is only created in make_remote(). Signed-off-by: NThomas Gummerer <t.gummerer@gmail.com> Reviewed-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 2月, 2016 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
If --force is not given but -B is, we should not proceed if the given branch is already checked out elsewhere. add_worktree() has this test, but it kicks in too late when "git branch --force" is already executed. As a result, even though we correctly refuse to create a new worktree, we have already updated the branch and mess up the other checkout. Repeat the die_if_checked_out() test again for this specific case before "git branch" runs. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-