- 24 7月, 2008 1 次提交
-
-
由 Pierre Habouzit 提交于
This fixes an issue when you use: $ git checkout -- <path1> [<paths>...] and that <path1> can also be understood as a reference. git-checkout mistakenly understands this as the same as: $ git checkout <path1> -- [<paths>...] because parse-options was eating the '--' and the argument parser thought he was parsing: $ git checkout <path1> [<paths>...] Where there indeed is an ambiguity Signed-off-by: NPierre Habouzit <madcoder@debian.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 21 7月, 2008 1 次提交
-
-
由 Jonathan Nieder 提交于
Without this patch, git-grep gives confusing usage information: $ git grep --confused usage: git grep <option>* <rev>* [-e] <pattern> [<path>...] $ git grep HEAD pattern fatal: ambiguous argument 'pattern': unknown revision or path no t in the working tree. Use '--' to separate paths from revisions So put <pattern> before the <rev>s, in accordance with actual correct usage. While we're changing the usage string, we might as well include the "--" separating revisions and paths, too. Signed-off-by: NJonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 7月, 2008 3 次提交
-
-
由 Junio C Hamano 提交于
5fdeacb0 (Teach update-index about --ignore-submodules, 2008-05-14) added a new refresh option flag but did not assign a unique bit for it correctly, and broke "update-index --ignore-missing". This fixes it. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Olivier Marin 提交于
When hold_locked_index() is called with a relative git_dir and you are outside the work tree, the lock file become relative to the current directory. So when later setup_work_tree() change the current directory it breaks lock file path and commit_locked_index() fails. This patch move index locking code after setup_work_tree() call to make lock file relative to the working tree as it should be and add a test case. Noticed by Nick Andrew. Signed-off-by: NOlivier Marin <dkr@freesurf.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 7月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
* sp/maint-index-pack: index-pack: Honor core.deltaBaseCacheLimit when resolving deltas index-pack: Track the object_entry that creates each base_data index-pack: Chain the struct base_data on the stack for traversal index-pack: Refactor base arguments of resolve_delta into a struct
-
- 18 7月, 2008 3 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Nick Andrew noticed that rev-list lets --quiet option to be parsed by underlying diff_options parser but did not pick up the result. This resulted in --quiet option to become effectively a no-op. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Stephan Beyer 提交于
Replace "run_command_v_opt_dir" by "run_command_v_opt_cd". Signed-off-by: NStephan Beyer <s-beyer@gmx.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 7月, 2008 12 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
If the repo is empty, it is obvious that there are no common commits when fetching from _anywhere_. So there is no use in saying it in that case, and it can even be annoying. Therefore suppress the message unilaterally if the repository is empty prior to the fetch. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
* js/maint-pretty-mailmap: Add pretty format %aN which gives the author name, respecting .mailmap
-
由 Junio C Hamano 提交于
* sp/maint-bash-completion-optim: bash completion: Resolve git show ref:path<tab> losing ref: portion bash completion: Append space after file names have been completed bash completion: Don't offer "a.." as a completion for "a." bash completion: Improve responsiveness of git-log completion
-
由 Junio C Hamano 提交于
* sp/maint-pack-memuse: Correct pack memory leak causing git gc to try to exceed ulimit
-
由 Junio C Hamano 提交于
* ls/maint-mailinfo-patch-label: git-mailinfo: Fix getting the subject from the in-body [PATCH] line
-
由 Junio C Hamano 提交于
* js/maint-daemon-syslog: git daemon: avoid calling syslog() from a signal handler
-
由 Stephan Beyer 提交于
When "rebase -i -p" tries to preserve merges of unrelated branches, it lost some parents: - When you have more than two parents, the commit in the new history ends up with fewer than expected number of parents and this breakage goes unnoticed; - When you are rebasing a merge with two parents and one is lost, the command tries to cherry-pick the original merge commit, and the command fails. Signed-off-by: NStephan Beyer <s-beyer@gmx.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Sixt 提交于
It used plain 'if git merge ...', which hides a segfault. The test does not pass. Signed-off-by: NJohannes Sixt <johannes.sixt@telecom.at> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Dmitry Potapov 提交于
If PATH_MAX on your system is smaller than a path stored in the git repo, it may cause the buffer overflow in prepare_attr_stack. Signed-off-by: NDmitry Potapov <dpotapov@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Dmitry Potapov 提交于
If PATH_MAX on your system is smaller than a path stored, it may cause buffer overflow and stack corruption in diff_addremove() and diff_change() functions when running git-diff Signed-off-by: NDmitry Potapov <dpotapov@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Dmitry Potapov 提交于
If PATH_MAX on your system is smaller than any path stored in the git repository, that can cause memory corruption inside of the grep_tree function used by git-grep. Signed-off-by: NDmitry Potapov <dpotapov@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 7月, 2008 2 次提交
-
-
由 Lars Noschinski 提交于
git-cvsserver.perl contained a single call to a nonexistant function cleanupWorkDir(). This was obviously a typo for cleanupWorkTree(). Signed-off-by: NLars Noschinski <lars@public.noschinski.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Petr Baudis 提交于
The manual page of git-cherry-pick and git-revert asserts that -n works primarily on the working tree, while in fact the primary object it operates on is the index, and the changes only "accidentally" propagate to the working tree. This e.g. leads innocent #git IRC folks to believe that you can use -n to prepare changes for git-add -i staging. Signed-off-by: NPetr Baudis <pasky@suse.cz> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 7月, 2008 5 次提交
-
-
由 Shawn O. Pearce 提交于
If we are trying to resolve deltas for a long delta chain composed of multi-megabyte objects we can easily run into requiring 500M+ of memory to hold each object in the chain on the call stack while we recurse into the dependent objects and resolve them. We now use a simple delta cache that discards objects near the bottom of the call stack first, as they are the most least recently used objects in this current delta chain. If we recurse out of a chain we may find the base object is no longer available, as it was free'd to keep memory under the deltaBaseCacheLimit. In such cases we must unpack the base object again, which will require recursing back to the root of the top of the delta chain as we released that root first. The astute reader will probably realize that we can still exceed the delta base cache limit, but this happens only if the most recent base plus the delta plus the inflated dependent sum up to more than the base cache limit. Due to the way patch_delta is currently implemented we cannot operate in less memory anyway. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Shawn O. Pearce 提交于
If we free the data stored within a base_data we need the struct object_entry to get the data back again for use with another dependent delta. Storing the object_entry* in base_data makes it simple to call get_data_from_pack() to recover the compressed information. This however means that we must add the missing base object to the end of our packfile prior to calling resolve_delta() on each of the dependent deltas. Adding the base first ensures we can read the base back from the pack we are indexing, as if it had been included by the remote side. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Shawn O. Pearce 提交于
We need to release earlier inflated base objects when memory gets low, which means we need to be able to walk up or down the stack to locate the objects we want to release, and free their data. The new link/unlink routines allow inserting and removing the struct base_data during recursion inside resolve_delta, and the global base_cache gives us the head of the chain (bottom of the stack) so we can traverse it. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Shawn O. Pearce 提交于
We need to discard base objects which are not recently used if our memory gets low, such as when we are unpacking a long delta chain of a very large object. To support tracking the available base objects we combine the pointer and size into a struct. Future changes would allow the data pointer to be free'd and marked NULL if memory gets low. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Shawn O. Pearce 提交于
Linus reported that the bash completion for git show often dropped the ref portion of the argument (stuff before the :) when trying to complete a file name of a file in another branch or tag. Björn Steinbrink tracked it down to the gvfs completion script which comes standard on many Fedora Core based systems. That is removing : from COMP_WORDBREAKS, making readline treat the entire argument (including the ref) as the name that must be completed. When the git completion routines supplied a completion of just the filename, readline replaced everything. Since Git users often need to use "ref:path" or "ref:ref" sort of arguments, and expect completion support on both sides of the : we really want the : in COMP_WORDBREAKS to provide a good user experience. This is also the default that ships with bash as it can be useful in other contexts, such as rcp/scp. We now try to add : back to COMP_WORDBREAKS if it has been removed by a script that loaded before us. However if this doesn't work (as the : is stripped after we load) we fallback in the completion routines to include "ref:" as part of the prefix for completions, allowing readine to fully insert the argument the user wanted. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 7月, 2008 6 次提交
-
-
由 Shawn O. Pearce 提交于
When completing `git show origin/maint:Makef<tab>` we should add a space after the filename has been completed, so that the user can immediately begin the next argument. I also added a special case for the symlink variant so we treat it just like a normal blob, as there are no items below it in the Git tree structure. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Lukas Sandström 提交于
"Subject: " isn't in the static array "header", and thus memcmp("Subject:", header[i], 7) will never match. Even if it did so, hdr_data[] may not have been allocated if there weren't a "Subject: " in-body when we process "[PATCH]" in the affected codepath. Signed-off-by: NLukas Sandström <lukass@etek.chalmers.se> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Shawn O. Pearce 提交于
If the user is trying to complete "v1.5.3.<tab>" to see all of the available maintenance releases for 1.5.3 we should not give them an extra dot as the completion. Instead if the user wants a ".." or a "..." operator they should key the two dots out on their own. Its the same number of keystrokes either way. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Stephan Beyer 提交于
Signed-off-by: NStephan Beyer <s-beyer@gmx.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Shawn O. Pearce 提交于
Junio noticed the bash completion has been taking a long time lately. Petr Baudis tracked it down to 72e5e989 ("bash: Add space after unique command name is completed."). Tracing the code showed we spent significant time inside of this loop within __gitcomp, due to the string copying overhead. [28.146109654] _git common over [28.164791148] gitrefs in [28.280302268] gitrefs dir out [28.300939737] gitcomp in [28.308378112] gitcomp pre-case * [28.313407453] gitcomp iter in * [28.701270296] gitcomp iter out [28.713370786] out normal Since __git_refs avoids this string copying by forking and using echo we use the same trick here when we need to finish generating the names for the caller. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 7月, 2008 4 次提交
-
-
由 Junio C Hamano 提交于
The test created an initial commit, made .git/objects unwritable and then exercised various codepaths to create loose commit, tree and blob objects to make sure the commands notice failures from these attempts. However, the initial commit was not preceded with test_tick, which made its object name depend on the timestamp. The names of all the later tree and blob objects the test tried to create were static. If the initial commit's object name happened to begin with the same two hexdigits as the tree or blob objects the test later attempted to create, the fan-out directory in which these tree or blob would be created is already created when the initial commit was made, and the object creation succeeds, and commands being tested should not notice any failure --- in short, the test was bogus. This makes the fan-out directories also unwritable, and adds test_tick before the commit object creation to make the test repeatable. The contents of the file to create a blob from "a" to "60" is to force the name of the blob object to begin with "1b", which shares the fan-out directory with the initial commit that is created with the test. This was useful when diagnosing the breakage of this test. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
The pretty format %an does not respect .mailmap, but gives the exact author name recorded in the commit. Sometimes it is more desirable, however, to look if the email has another name mapped to it in .mailmap. This commit adds %aN (and %cN for the committer name) to do exactly that. Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Lukas Sandström 提交于
Signed-off-by: NLukas Sandström <lukass@etek.chalmers.se> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Petr Baudis 提交于
06cbe855 (Make core.sharedRepository more generic, 2008-04-16) broke the traditional setting of core.sharedRepository to true, which was to make the repository group writable: with umask 022, it would clear the permission bits for 'other'. (umask 002 did not exhibit this behaviour since pre-chmod() check in adjust_shared_perm() fails in that case.) The call to adjust_shared_perm() should only loosen the permission. If the user has umask like 022 or 002 that allow others to read, the resulting files should be made readable and writable by group, without restricting the readability by others. This patch fixes the adjust_shared_perm() mode tweak based on Junio's suggestion and adds the appropriate tests to t/t1301-shared-repo.sh. Cc: Heikki Orsila <heikki.orsila@iki.fi> Signed-off-by: NPetr Baudis <pasky@suse.cz> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 7月, 2008 1 次提交
-
-
由 Shawn O. Pearce 提交于
When recursing to unpack a delta base we must unuse_pack() so that the pack window for the current object does not remain pinned in memory while the delta base is itself being unpacked and materialized for our use. On a long delta chain of 50 objects we may need to access 6 different windows from a very large (>3G) pack file in order to obtain all of the delta base content. If the process ulimit permits us to map/allocate only 1.5G we must release windows during this recursion to ensure we stay within the ulimit and transition memory from pack cache to standard malloc, or other mmap needs. Inserting an unuse_pack() call prior to the recursion allows us to avoid pinning the current window, making it available for garbage collection if memory runs low. This has been broken since at least before 1.5.1-rc1, and very likely earlier than that. Its fixed now. :) Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 7月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-