- 03 6月, 2013 2 次提交
-
-
由 René Scharfe 提交于
ie_match_stat and ie_modified only derefence their struct cache_entry pointers for reading. Add const to the parameter declaration here and do the same for the static helper function used by them, as it's the same there as well. This allows callers to pass in const pointers. Signed-off-by: NRené Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 René Scharfe 提交于
Add const for pointers that are only dereferenced for reading by the inline functions copy_cache_entry and ce_mode_from_stat. This allows callers to pass in const pointers. Signed-off-by: NRené Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 4月, 2013 2 次提交
-
-
由 Lukas Fleischer 提交于
This allows for optionally getting the size of the returned data and will be used in a follow-up patch. Signed-off-by: NLukas Fleischer <git@cryptocrack.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Lukas Fleischer 提交于
Extract the read_index_data() function from attr.c and move it to read-cache.c; rename it to read_blob_data_from_index() and update the function signature of it to align better with index/cache API functions. This allows for reusing the function in convert.c later. Signed-off-by: NLukas Fleischer <git@cryptocrack.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 4月, 2013 1 次提交
-
-
由 Torsten Bögershausen 提交于
All calls to set_shared_perm() use mode == 0, so simplify the function. Because all callers use the macro adjust_shared_perm(path) from cache.h to call this function, convert it to a proper function, losing set_shared_perm(). Since path.c has much more functions than just mkpath() these days, drop the stale comment about it. Signed-off-by: NTorsten Bögershausen <tboegi@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 4月, 2013 1 次提交
-
-
由 Jonathan Nieder 提交于
A common workflow in large projects is to chdir into a subdirectory of interest and only do work there: cd src vi foo.c make test git add -u git commit The upcoming change to 'git add -u' behavior would not affect such a workflow: when the only changes present are in the current directory, 'git add -u' will add all changes, and whether that happens via an implicit "." or implicit ":/" parameter is an unimportant implementation detail. The warning about use of 'git add -u' with no pathspec is annoying because it seemingly serves no purpose in this case. So suppress the warning unless there are changes outside the cwd that are not being added. A previous version of this patch ran two I/O-intensive diff-files passes: one to find changes outside the cwd, and another to find changes to add to the index within the cwd. This version runs one full-tree diff and decides for each change whether to add it or warn and suppress it in update_callback. As a result, even on very large repositories "git add -u" will not be significantly slower than the future default behavior ("git add -u :/"), and the slowdown relative to "git add -u ." should be a useful clue to users of such repositories to get into the habit of explicitly passing '.'. Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Acked-by: NJeff King <peff@peff.net> Improved-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 27 3月, 2013 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
In checkout_paths() we do this - for all updated items, call match_pathspec - for all items, call match_pathspec (inside unmerge_cache) - for all items, call match_pathspec (for showing "path .. is unmerged) - for updated items, call match_pathspec and update paths That's a lot of duplicate match_pathspec(s) and the function is not exactly cheap to be called so many times, especially on large indexes. This patch makes it call match_pathspec once per updated index entry, save the result in ce_flags and reuse the results in the following loops. The changes in 0a1283bc (checkout $tree $path: do not clobber local changes in $path not in $tree - 2011-09-30) limit the affected paths to ones we read from $tree. We do not do anything to other modified entries in this case, so the "for all items" above could be modified to "for all updated items". But.. The command's behavior now is modified slightly: unmerged entries that match $path, but not updated by $tree, are now NOT touched. Although this should be considered a bug fix, not a regression. A new test is added for this change. And while at there, free ps_matched after use. The following command is tested on webkit, 215k entries. The pattern is chosen mainly to make match_pathspec sweat: git checkout -- "*[a-zA-Z]*[a-zA-Z]*[a-zA-Z]*" before after real 0m3.493s 0m2.737s user 0m2.239s 0m1.586s sys 0m1.252s 0m1.151s Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 3月, 2013 1 次提交
-
-
由 René Scharfe 提交于
We use the function git_deflate_init() -- which wraps the zlib function deflateInit() -- to initialize compression of ZIP file entries. This results in compressed data prefixed with a two-bytes long header and followed by a four-bytes trailer. ZIP file entries consist of ZIP headers and raw compressed data instead, so we remove the zlib wrapper before writing the result. We can ask zlib for the the raw compressed data without the unwanted parts in the first place by using deflateInit2() and specifying a negative number of bits to size the window. For that purpose, factor out the function do_git_deflate_init() and add git_deflate_init_raw(), which wraps it. Then use the latter in archive-zip.c and get rid of the code that stripped the zlib header and trailer. Also rename the helper function zlib_deflate() to zlib_deflate_raw() to reflect the change. Thus we avoid generating data that we throw away anyway, the code becomes shorter and some magic constants are removed. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 3月, 2013 2 次提交
-
-
由 Jeff King 提交于
If an explicit GIT_DIR is given without a working tree, we implicitly assume that the current working directory should be used as the working tree. E.g.,: GIT_DIR=/some/repo.git git status would compare against the cwd. Unfortunately, we fool this rule for sub-invocations of git by setting GIT_DIR internally ourselves. For example: git init foo cd foo/.git git status ;# fails, as we expect git config alias.st status git status ;# does not fail, but should What happens is that we run setup_git_directory when doing alias lookup (since we need to see the config), set GIT_DIR as a result, and then leave GIT_WORK_TREE blank (because we do not have one). Then when we actually run the status command, we do setup_git_directory again, which sees our explicit GIT_DIR and uses the cwd as an implicit worktree. It's tempting to argue that we should be suppressing that second invocation of setup_git_directory, as it could use the values we already found in memory. However, the problem still exists for sub-processes (e.g., if "git status" were an external command). You can see another example with the "--bare" option, which sets GIT_DIR explicitly. For example: git init foo cd foo/.git git status ;# fails git --bare status ;# does NOT fail We need some way of telling sub-processes "even though GIT_DIR is set, do not use cwd as an implicit working tree". We could do it by putting a special token into GIT_WORK_TREE, but the obvious choice (an empty string) has some portability problems. Instead, we add a new boolean variable, GIT_IMPLICIT_WORK_TREE, which suppresses the use of cwd as a working tree when GIT_DIR is set. We trigger the new variable when we know we are in a bare setting. The variable is left intentionally undocumented, as this is an internal detail (for now, anyway). If somebody comes up with a good alternate use for it, and once we are confident we have shaken any bugs out of it, we can consider promoting it further. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
The GIT_PREFIX variable is set based on our location within the working tree. It should therefore be cleared whenever GIT_WORK_TREE is cleared. In practice, this doesn't cause any bugs, because none of the sub-programs we invoke with local_repo_env cleared actually care about GIT_PREFIX. But this is the right thing to do, and future proofs us against that assumption changing. While we're at it, let's define a GIT_PREFIX_ENVIRONMENT macro; this avoids repetition of the string literal, which can help catch any spelling mistakes in the code. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 3月, 2013 1 次提交
-
-
由 Jeff King 提交于
We keep a static array of variables that should be cleared when invoking a sub-process on another repo. We statically size the array with the LOCAL_REPO_ENV_SIZE macro so that any readers do not have to count it themselves. As it turns out, no readers actually use the macro, and it creates a maintenance headache, as modifications to the array need to happen in two places (one to add the new element, and another to bump the size). Since it's NULL-terminated, we can just drop the size macro entirely. While we're at it, we'll clean up some comments around it, and add a new mention of it at the top of the list of environment variable macros. Even though local_repo_env is right below that list, it's easy to miss, and additions to that list should consider local_repo_env. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 2月, 2013 1 次提交
-
-
由 Karsten Blees 提交于
With core.ignorecase=true, name-hash.c builds a case insensitive index of all tracked directories. Currently, the existing cache entry structures are added multiple times to the same hashtable (with different name lengths and hash codes). However, there's only one dir_next pointer, which gets completely messed up in case of hash collisions. In the worst case, this causes an endless loop if ce == ce->dir_next (see t7062). Use a separate hashtable and separate structures for the directory index so that each directory entry has its own next pointer. Use reference counting to track which directory entry contains files. There are only slight changes to the name-hash.c API: - new free_name_hash() used by read_cache.c::discard_index() - remove_name_hash() takes an additional index_state parameter - index_name_exists() for a directory (trailing '/') may return a cache entry that has been removed (CE_UNHASHED). This is not a problem as the return value is only used to check if the directory exists (dir.c) or to normalize casing of directory names (read-cache.c). Getting rid of cache_entry.dir_next reduces memory consumption, especially with core.ignorecase=false (which doesn't use that member at all). With core.ignorecase=true, building the directory index is slightly faster as we add / check the parent directory first (instead of going through all directory levels for each file in the index). E.g. with WebKit (~200k files, ~7k dirs), time spent in lazy_init_name_hash is reduced from 176ms to 130ms. Signed-off-by: NKarsten Blees <blees@dcon.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 2月, 2013 1 次提交
-
-
由 Jeff King 提交于
Now that we can read packet data from memory as easily as a descriptor, get_remote_heads can take either one as a source. This will allow further refactoring in remote-curl. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 2月, 2013 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
prepare_packed_git_one() is modified to allow count-objects to hook a report function to so we don't need to duplicate the pack searching logic in count-objects.c. When report_pack_garbage is NULL, the overhead is insignificant. The garbage is reported with warning() instead of error() in packed garbage case because it's not an error to have garbage. Loose garbage is still reported as errors and will be converted to warnings later. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 2月, 2013 1 次提交
-
-
由 Junio C Hamano 提交于
Even though "git fetch" has full infrastructure to parse refspecs to be fetched and match them against the list of refs to come up with the final list of refs to be fetched, the list of refs that are requested to be fetched were internally converted to a plain list of strings at the transport layer and then passed to the underlying fetch-pack driver. Stop this conversion and instead pass around an array of refs. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 1月, 2013 2 次提交
-
-
由 Junio C Hamano 提交于
When we push to update an existing ref, if: * the object at the tip of the remote is not a commit; or * the object we are pushing is not a commit, it won't be correct to suggest to fetch, integrate and push again, as the old and new objects will not "merge". We should explain that the push must be forced when there is a non-committish object is involved in such a case. If we do not have the current object at the tip of the remote, we do not even know that object, when fetched, is something that can be merged. In such a case, suggesting to pull first just like non-fast-forward case may not be technically correct, but in practice, most such failures are seen when you try to push your work to a branch without knowing that somebody else already pushed to update the same branch since you forked, so "pull first" would work as a suggestion most of the time. And if the object at the tip is not a commit, "pull first" will fail, without making any permanent damage. As a side effect, it also makes the error message the user will get during the next "push" attempt easier to understand, now the user is aware that a non-commit object is involved. In these cases, the current code already rejects such a push on the client end, but we used the same error and advice messages as the ones used when rejecting a non-fast-forward push, i.e. pull from there and integrate before pushing again. Introduce new rejection reasons and reword the messages appropriately. [jc: with help by Peff on message details] Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
The "nonfastforward" and "update" fields are only used while deciding what value to assign to the "status" locally in a single function. Remove them from the "struct ref". The "requires_force" field is not used to decide if the proposed update requires a --force option to succeed, or to record such a decision made elsewhere. It is used by status reporting code that the particular update was "forced". Rename it to "forced_update", and move the code to assign to it around to further clarify how it is used and what it is used for. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 1月, 2013 1 次提交
-
-
由 Jeff King 提交于
The config callback functions get keys of the general form: section.subsection.key (where the subsection may be contain arbitrary data, or may be missing). For matching keys without subsections, it is simple enough to call "strcmp". Matching keys with subsections is a little more complicated, and each callback does it in an ad-hoc way, usually involving error-prone pointer arithmetic. Let's provide a helper that keeps the pointer arithmetic all in one place. Signed-off-by: NJeff King <peff@peff.net> Reviewed-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 1月, 2013 1 次提交
-
-
由 Robin Rosenberg 提交于
Specifically the fields uid, gid, ctime, ino and dev are set to zero by JGit. Other implementations, eg. Git in cygwin are allegedly also somewhat incompatible with Git For Windows and on *nix platforms the resolution of the timestamps may differ. Any stat checking by git will then need to check content, which may be very slow, particularly on Windows. Since mtime and size is typically enough we should allow the user to tell git to avoid checking these fields if they are set to zero in the index. This change introduces a core.checkstat config option where the the user can select to check all fields (default), or just size and the whole second part of mtime (minimal). Signed-off-by: NRobin Rosenberg <robin.rosenberg@dewire.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 1月, 2013 3 次提交
-
-
由 Junio C Hamano 提交于
When pushing to update a branch with a commit that is not a descendant of the commit at the tip, a wrong message "already exists" was given, instead of the correct "non-fast-forward", if we do not have the object sitting in the destination repository at the tip of the ref we are updating. The primary cause of the bug is that the check in a new helper function is_forwardable() assumed both old and new objects are available and can be checked, which is not always the case. The way the caller uses the result of this function is also wrong. If the helper says "we do not want to let this push go through", the caller unconditionally translates it into "we blocked it because the destination already exists", which is not true at all in this case. Fix this by doing these three things: * Remove unnecessary not_forwardable from "struct ref"; it is only used inside set_ref_status_for_push(); * Make "refs/tags/" the only hierarchy that cannot be replaced without --force; * Remove the misguided attempt to force that everything that updates an existing ref has to be a commit outside "refs/tags/" hierarchy. The policy last one tried to implement may later be resurrected and extended to ensure fast-forwardness (defined as "not losing objects", extending from the traditional "not losing commits from the resulting history") when objects that are not commit are involved (e.g. an annotated tag in hierarchies outside refs/tags), but such a logic belongs to "is this a fast-forward?" check that is done by ref_newer(); is_forwardable(), which is now removed, was not the right place to do so. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Some users do want to write a line that begin with a pound sign, #, in their commit log message. Many tracking system recognise a token of #<bugid> form, for example. The support we offer these use cases is not very friendly to the end users. They have a choice between - Don't do it. Avoid such a line by rewrapping or indenting; and - Use --cleanup=whitespace but remove all the hint lines we add. Give them a way to set a custom comment char, e.g. $ git -c core.commentchar="%" commit so that they do not have to do either of the two workarounds. [jc: although I started the topic, all the tests and documentation updates, many of the call sites of the new strbuf_add_commented_*() functions, and the change to git-submodule.sh scripted Porcelain are from Ralf.] Signed-off-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NRalf Thielow <ralf.thielow@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Max Horn 提交于
Commit a469a101 wraps some error calls in macros to give the compiler a chance to do more static analysis on their constant -1 return value. We limit the use of these macros to __GNUC__, since gcc is the primary beneficiary of the new information, and because we use GNU features for handling variadic macros. However, clang also defines __GNUC__, but generates warnings with -Wunused-value when these macros are used in a void context, because the constant "-1" ends up being useless. Gcc does not complain about this case (though it is unclear if it is because it is smart enough to see what we are doing, or too dumb to realize that the -1 is unused). We can squelch the warning by just disabling these macros when clang is in use. Signed-off-by: NMax Horn <max@quendi.de> Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 12月, 2012 1 次提交
-
-
由 Jeff King 提交于
Git takes pathspec arguments in many places to limit the scope of an operation. These pathspecs are treated not as literal paths, but as glob patterns that can be fed to fnmatch. When a user is giving a specific pattern, this is a nice feature. However, when programatically providing pathspecs, it can be a nuisance. For example, to find the latest revision which modified "$foo", one can use "git rev-list -- $foo". But if "$foo" contains glob characters (e.g., "f*"), it will erroneously match more entries than desired. The caller needs to quote the characters in $foo, and even then, the results may not be exactly the same as with a literal pathspec. For instance, the depth checks in match_pathspec_depth do not kick in if we match via fnmatch. This patch introduces a global command-line option (i.e., one for "git" itself, not for specific commands) to turn this behavior off. It also has a matching environment variable, which can make it easier if you are a script or porcelain interface that is going to issue many such commands. This option cannot turn off globbing for particular pathspecs. That could eventually be done with a ":(noglob)" magic pathspec prefix. However, that level of granularity is more cumbersome to use for many cases, and doing ":(noglob)" right would mean converting the whole codebase to use "struct pathspec", as the usual "const char **pathspec" cannot represent extra per-item flags. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 12月, 2012 1 次提交
-
-
由 Jeff King 提交于
There are a few error functions that simply wrap error() and provide a standardized message text. Like error(), they always return -1; knowing that can help the compiler silence some false positive -Wuninitialized warnings. One strategy would be to just declare these as inline in the header file so that the compiler can see that they always return -1. However, gcc does not always inline them (e.g., it will not inline opterror, even with -O3), which renders our change pointless. Instead, let's follow the same route we did with error() in the last patch, and define a macro that makes the constant return value obvious to the compiler. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 12月, 2012 1 次提交
-
-
由 Jeff King 提交于
In a bare repository, there isn't a simple way to respect an in-tree mailmap without extracting it to a temporary file. This patch provides a config variable, similar to mailmap.file, which reads the mailmap from a blob in the repository. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 12月, 2012 4 次提交
-
-
由 Chris Rorvick 提交于
References are allowed to update from one commit-ish to another if the former is an ancestor of the latter. This behavior is oriented to branches which are expected to move with commits. Tag references are expected to be static in a repository, though, thus an update to something under refs/tags/ should be rejected unless the update is forced. Signed-off-by: NChris Rorvick <chris@rorvick.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Chris Rorvick 提交于
Add a flag for indicating an update to a reference requires force. Currently the `nonfastforward` flag is used for this when generating the status message. A separate flag insulates dependent logic from the details of set_ref_status_for_push(). Signed-off-by: NChris Rorvick <chris@rorvick.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Chris Rorvick 提交于
If the reference exists on the remote and it is not being removed, then mark as an update. This is in preparation for handling tags (lightweight and annotated) exceptionally. Signed-off-by: NChris Rorvick <chris@rorvick.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Chris Rorvick 提交于
Advising the user to fetch and merge only makes sense if the rejected reference is a branch. If none of the rejections are for branches, just tell the user the reference already exists. Signed-off-by: NChris Rorvick <chris@rorvick.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 27 11月, 2012 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
When a pattern contains only a single asterisk as wildcard, e.g. "foo*bar", after literally comparing the leading part "foo" with the string, we can compare the tail of the string and make sure it matches "bar", instead of running fnmatch() on "*bar" against the remainder of the string. -O2 build on linux-2.6, without the patch: $ time git rev-list --quiet HEAD -- '*.c' real 0m40.770s user 0m40.290s sys 0m0.256s With the patch $ time ~/w/git/git rev-list --quiet HEAD -- '*.c' real 0m34.288s user 0m33.997s sys 0m0.205s The above command is not supposed to be widely popular. It's chosen because it exercises pathspec matching a lot. The point is it cuts down matching time for popular patterns like *.c, which could be used as pathspec in other places. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 11月, 2012 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
We mark pathspec with wildcards with the field use_wildcard. We could do better by saving the length of the non-wildcard part, which can be used for optimizations such as f9f6e2ce (exclude: do strcmp as much as possible before fnmatch - 2012-06-07). Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 11月, 2012 2 次提交
-
-
由 Jeff King 提交于
We keep track of whether the user ident was given to us explicitly, or if we guessed at it from system parameters like username and hostname. However, we kept only a single variable. This covers the common cases (because the author and committer will usually come from the same explicit source), but can miss two cases: 1. GIT_COMMITTER_* is set explicitly, but we fallback for GIT_AUTHOR. We claim the ident is explicit, even though the author is not. 2. GIT_AUTHOR_* is set and we ask for author ident, but not committer ident. We will claim the ident is implicit, even though it is explicit. This patch uses two variables instead of one, updates both when we set the "fallback" values, and updates them individually when we read from the environment. Rather than keep user_ident_sufficiently_given as a compatibility wrapper, we update the only two callers to check the committer_ident, which matches their intent and what was happening already. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
In v1.5.6-rc0~56^2 (2008-05-04) "user_ident_explicitly_given" was introduced as a global for communication between config, ident, and builtin-commit. In v1.7.0-rc0~72^2 (2010-01-07) readers switched to using the common wrapper user_ident_sufficiently_given(). After v1.7.11-rc1~15^2~18 (2012-05-21), the var is only written in ident.c. Now we can make it static, which will enable further refactoring without worrying about upsetting other code. Signed-off-by: NJeff King <peff@peff.net> Reviewed-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 10月, 2012 4 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
This is used by diff-no-index.c, part of libgit.a while it stays in builtin/diff.c. Move it to diff.c so that we won't get undefined reference if a program that uses libgit.a happens to pull it in. While at it, move check_pager from git.c to pager.c. It makes more sense there and pager.c is also part of libgit.a Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJeff King <peff@peff.net>
-
由 Nguyễn Thái Ngọc Duy 提交于
These functions are called in sequencer.c, which is part of libgit.a. This makes libgit.a potentially require builtin/merge.c for external git commands. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJeff King <peff@peff.net>
-
由 Michael Haggerty 提交于
Change longest_ancestor_length() to take the prefixes argument as a string_list rather than as a colon-separated string. This will make it easier for the caller to alter the entries before calling longest_ancestor_length(). Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJeff King <peff@peff.net>
-
由 Michael Haggerty 提交于
The function is like real_path(), except that it returns NULL on error instead of dying. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJeff King <peff@peff.net>
-
- 16 9月, 2012 3 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-