summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2009-10-18Merge branch 'cc/replace-no-replace'Libravatar Junio C Hamano1-0/+7
* cc/replace-no-replace: git: add --no-replace-objects option to disable replacing
2009-10-18Merge branch 'jk/maint-1.6.3-ls-files-no-ignore-cached'Libravatar Junio C Hamano1-0/+32
* jk/maint-1.6.3-ls-files-no-ignore-cached: ls-files: excludes should not impact tracked files
2009-10-17Merge branch 'jc/maint-blank-at-eof'Libravatar Junio C Hamano3-3/+110
* jc/maint-blank-at-eof: diff -B: colour whitespace errors diff.c: emit_add_line() takes only the rest of the line diff.c: split emit_line() from the first char and the rest of the line diff.c: shuffling code around diff --whitespace: fix blank lines at end core.whitespace: split trailing-space into blank-at-{eol,eof} diff --color: color blank-at-eof diff --whitespace=warn/error: fix blank-at-eof check diff --whitespace=warn/error: obey blank-at-eof diff.c: the builtin_diff() deals with only two-file comparison apply --whitespace: warn blank but not necessarily empty lines at EOF apply --whitespace=warn/error: diagnose blank at EOF apply.c: split check_whitespace() into two apply --whitespace=fix: detect new blank lines at eof correctly apply --whitespace=fix: fix handling of blank lines at the eof
2009-10-17Merge branch 'maint'Libravatar Junio C Hamano1-0/+66
* maint: GIT 1.6.5.1 grep: do not segfault when -f is used
2009-10-16Merge branch 'maint-1.6.4' into maintLibravatar Junio C Hamano1-0/+66
* maint-1.6.4: grep: do not segfault when -f is used
2009-10-16grep: do not segfault when -f is usedLibravatar Matt Kraai1-0/+66
"git grep" would segfault if its -f option was used because it would try to use an uninitialized strbuf, so initialize the strbuf. Thanks to Johannes Sixt <j.sixt@viscovery.net> for the help with the test cases. Signed-off-by: Matt Kraai <kraai@ftbfs.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-14Merge branch 'pv/maint-add-p-no-exclude'Libravatar Junio C Hamano1-0/+14
* pv/maint-add-p-no-exclude: git-add--interactive: never skip files included in index
2009-10-14Merge branch 'maint'Libravatar Junio C Hamano1-0/+9
* maint: sha1_file: Fix infinite loop when pack is corrupted
2009-10-14sha1_file: Fix infinite loop when pack is corruptedLibravatar Shawn O. Pearce1-0/+9
Some types of corruption to a pack may confuse the deflate stream which stores an object. In Andy's reported case a 36 byte region of the pack was overwritten, leading to what appeared to be a valid deflate stream that was trying to produce a result larger than our allocated output buffer could accept. Z_BUF_ERROR is returned from inflate() if either the input buffer needs more input bytes, or the output buffer has run out of space. Previously we only considered the former case, as it meant we needed to move the stream's input buffer to the next window in the pack. We now abort the loop if inflate() returns Z_BUF_ERROR without consuming the entire input buffer it was given, or has filled the entire output buffer but has not yet returned Z_STREAM_END. Either state is a clear indicator that this loop is not working as expected, and should not continue. This problem cannot occur with loose objects as we open the entire loose object as a single buffer and treat Z_BUF_ERROR as an error. Reported-by: Andy Isaacson <adi@hexapodia.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Acked-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-13git: add --no-replace-objects option to disable replacingLibravatar Christian Couder1-0/+7
Commit dae556b (environment: add global variable to disable replacement) adds a variable to enable/disable replacement, and it is enabled by default for most commands. So there is no way to disable it for some commands, which is annoying when we want to get information about a commit that has been replaced. For example: $ git cat-file -p N would output information about the replacement commit if commit N is replaced. With the "--no-replace-objects" option that this patch adds it is possible to get information about the original commit using: $ git --no-replace-objects cat-file -p N While at it, let's add some documentation about this new option in the "git replace" man page too. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-12Let --decorate show HEAD positionLibravatar Thomas Rast2-2/+2
'git log --graph --oneline --decorate --all' is a useful way to get a general overview of the repository state, similar to 'gitk --all'. Let it indicate the position of HEAD by loading that ref too, so that the --decorate code can see it. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-12ls-files: excludes should not impact tracked filesLibravatar Jeff King1-0/+32
In all parts of git, .gitignore and other exclude files impact only how we treat untracked files; they should have no effect on files listed in the index. This behavior was originally implemented very early on in 9ff768e, but only for --exclude-from. Later, commit 63d285c accidentally caused us to trigger the behavior for --exclude-per-directory. This patch totally ignores excludes for files found in the index. This means we are reversing the original intent of 9ff768e, while at the same time fixing the accidental behavior of 63d285c. This is a good thing, though, as the way that 9ff768e behaved does not really make sense with the way exclusions are used in modern git. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-10git-add--interactive: never skip files included in indexLibravatar Pauli Virtanen1-0/+14
Make "git add -p" to not skip files that are in index even if they are excluded (by .gitignore etc.). This fixes the contradictory behavior that "git status" and "git commit -a" listed such files as modified, but "git add -p FILENAME" ignored them. Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-09Merge branch 'rs/maint-archive-prefix'Libravatar Junio C Hamano1-0/+12
* rs/maint-archive-prefix: Git archive and trailing "/" in prefix
2009-10-08Git archive and trailing "/" in prefixLibravatar René Scharfe1-0/+12
With --prefix=string that does not end with a slash, the top-level entries are written out with the specified prefix as expected, but no paths in the directories are added. Fix this by adding the prefix in write_archive_entry() instead of letting get_pathspec() and read_tree_recursive() pair; they are designed to only handle prefixes that are path components. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-04Merge branch 'maint'Libravatar Junio C Hamano1-0/+8
* maint: show-branch: fix segfault when showbranch.default exists
2009-10-04Merge branch 'jc/maint-1.6.4-show-branch-default' into maintLibravatar Junio C Hamano1-0/+8
* jc/maint-1.6.4-show-branch-default: show-branch: fix segfault when showbranch.default exists
2009-10-04show-branch: fix segfault when showbranch.default existsLibravatar Junio C Hamano1-0/+8
When running "git show-branch" without any parameter in a repository that has showbranch.default defined, we used to rely on the fact that our handcrafted option parsing loop never looked at av[0]. The array of default strings had the first real command line argument in default_arg[0], but the option parser wanted to look at the array starting at av[1], so we assigned the address of -1th element to av to force the loop start working from default_arg[0]. This no longer worked since 5734365 (show-branch: migrate to parse-options API, 2009-05-21), as parse_options_start() saved the incoming &av[0] in its ctx->out and later in parse_options_end() it did memmove to ctx->out (with ctx->cpidx == 0), overwriting the memory before default_arg[] array. I am not sure if this is a bug in parse_options(), or a bug in the caller, and tonight I do not have enough concentration to figure out which. In any case, this patch works the issue around. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-03Fix '--relative-date'Libravatar Johan Sageryd1-0/+1
This fixes '--relative-date' so that it does not give '0 year, 12 months', for the interval 360 <= diff < 365. Signed-off-by: Johan Sageryd <j416@1616.se> Signed-off-by: Jeff King <peff@peff.net>
2009-10-02tests: make all test files executableLibravatar Mark Rada2-0/+0
For consistency with the rest of the test files. Signed-off-by: Mark Rada <marada@uwaterloo.ca> Signed-off-by: Jeff King <peff@peff.net>
2009-09-29parse-opt: ignore negation of OPT_NONEG for ambiguity checksLibravatar Andreas Schwab1-0/+20
parse_long_opt always matches both --opt and --no-opt for any option "opt", and only get_value checks whether --no-opt is actually valid. Since the options for git branch contains both "no-merged" and "merged" there are two matches for --no-merge, but no exact match. With this patch the negation of a NONEG option is rejected earlier, but it changes the error message from "option `no-opt' isn't available" to "unknown option `no-opt'". [jk: added test] Signed-off-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2009-09-16Merge branch 'jc/maint-unpack-objects-strict' into maintLibravatar Junio C Hamano1-0/+35
* jc/maint-unpack-objects-strict: Fix "unpack-objects --strict" Conflicts: builtin-unpack-objects.c
2009-09-16Merge branch 'jk/maint-1.6.3-checkout-unborn' into maintLibravatar Junio C Hamano1-0/+40
* jk/maint-1.6.3-checkout-unborn: checkout: do not imply "-f" on unborn branches
2009-09-16Merge branch 'jc/maint-checkout-index-to-prefix' into maintLibravatar Junio C Hamano1-0/+9
* jc/maint-checkout-index-to-prefix: check_path(): allow symlinked directories to checkout-index --prefix
2009-09-15Merge branch 'jc/maint-1.6.0-blank-at-eof' (early part) into ↵Libravatar Junio C Hamano3-3/+110
jc/maint-blank-at-eof * 'jc/maint-1.6.0-blank-at-eof' (early part): diff --whitespace: fix blank lines at end core.whitespace: split trailing-space into blank-at-{eol,eof} diff --color: color blank-at-eof diff --whitespace=warn/error: fix blank-at-eof check diff --whitespace=warn/error: obey blank-at-eof diff.c: the builtin_diff() deals with only two-file comparison apply --whitespace: warn blank but not necessarily empty lines at EOF apply --whitespace=warn/error: diagnose blank at EOF apply.c: split check_whitespace() into two apply --whitespace=fix: detect new blank lines at eof correctly apply --whitespace=fix: fix handling of blank lines at the eof
2009-09-14diff --whitespace: fix blank lines at endLibravatar Junio C Hamano1-1/+1
The earlier logic tried to colour any and all blank lines that were added beyond the last blank line in the original, but this was very wrong. If you added 96 blank lines, a non-blank line, and then 3 blank lines at the end, only the last 3 lines should trigger the error, not the earlier 96 blank lines. We need to also make sure that the lines are after the last non-blank line in the postimage as well before deciding to paint them. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-13test local clone by copyingLibravatar Clemens Buchacher1-21/+33
Test the effect of an earlier change by f7835a2 (preserve mtime of local clone, 2009-09-12) to keep stale loose object files stale in the new repository when a local clone is made by copying files in .git/ directory. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-13Merge branch 'jt/pushinsteadof'Libravatar Junio C Hamano1-0/+47
* jt/pushinsteadof: Add url.<base>.pushInsteadOf: URL rewriting for push only Wrap rewrite globals in a struct in preparation for adding another set
2009-09-13Merge branch 'maint'Libravatar Junio C Hamano2-0/+31
* maint: GIT 1.6.4.3 svn: properly escape arguments for authors-prog http.c: remove verification of remote packs grep: accept relative paths outside current working directory grep: fix exit status if external_grep() punts Conflicts: GIT-VERSION-GEN RelNotes
2009-09-13svn: properly escape arguments for authors-progLibravatar Mark Lodato1-0/+14
Previously, the call to authors-prog was not properly escaped, so any special characters in the Subversion username, such as spaces and semi-colons, would be interpreted by the shell rather than being passed in as the first argument. Now all unsafe characters are escaped using "git rev-parse --sq-quote" [ew: switched from "\Q..\E" to "rev-parse --sq-quote"] Signed-off-by: Mark Lodato <lodatom@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-13Merge branch 'cb/maint-1.6.3-grep-relative-up' into maintLibravatar Junio C Hamano1-0/+17
* cb/maint-1.6.3-grep-relative-up: grep: accept relative paths outside current working directory grep: fix exit status if external_grep() punts Conflicts: t/t7002-grep.sh
2009-09-08Add url.<base>.pushInsteadOf: URL rewriting for push onlyLibravatar Josh Triplett1-0/+47
This configuration option allows systematically rewriting fetch-only URLs to push-capable URLs when used with push. For instance: [url "ssh://example.org/"] pushInsteadOf = "git://example.org/" This will allow clones of "git://example.org/path/to/repo" to subsequently push to "ssh://example.org/path/to/repo", without manually configuring pushurl for that remote. Includes documentation for the new option, bash completion updates, and test cases (both that pushInsteadOf applies to push, that it does not apply to fetch, and that it is ignored when pushURL is already defined). Signed-off-by: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-07Merge branch 'jc/mailinfo-scissors'Libravatar Junio C Hamano8-8/+265
* jc/mailinfo-scissors: mailinfo.scissors: new configuration am/mailinfo: Disable scissors processing by default Documentation: describe the scissors mark support of "git am" Teach mailinfo to ignore everything before -- >8 -- mark builtin-mailinfo.c: fix confusing internal API to mailinfo()
2009-09-07Merge branch 'jk/clone-b'Libravatar Junio C Hamano1-0/+68
* jk/clone-b: clone: add --branch option to select a different HEAD
2009-09-07Merge branch 'jc/upload-pack-hook'Libravatar Junio C Hamano1-0/+69
* jc/upload-pack-hook: upload-pack: feed "kind [clone|fetch]" to post-upload-pack hook upload-pack: add a trigger for post-upload-pack hook
2009-09-07Merge branch 'tr/reset-checkout-patch'Libravatar Junio C Hamano5-0/+291
* tr/reset-checkout-patch: stash: simplify defaulting to "save" and reject unknown options Make test case number unique tests: disable interactive hunk selection tests if perl is not available DWIM 'git stash save -p' for 'git stash -p' Implement 'git stash save --patch' Implement 'git checkout --patch' Implement 'git reset --patch' builtin-add: refactor the meat of interactive_add() Add a small patch-mode testing library git-apply--interactive: Refactor patch mode code Make 'git stash -k' a short form for 'git stash save --keep-index'
2009-09-07grep: accept relative paths outside current working directoryLibravatar Clemens Buchacher1-0/+17
"git grep" would barf at relative paths pointing outside the current working directory (or subdirectories thereof). Use quote_path_relative(), which can handle such cases just fine. [jc: added tests.] Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-04diff --color: color blank-at-eofLibravatar Junio C Hamano1-0/+9
Since the coloring logic processed the patch output one line at a time, we couldn't easily color code the new blank lines at the end of file. Reuse the adds_blank_at_eof() function to find where the runs of such blank lines start, keep track of the line number in the preimage while processing the patch output one line at a time, and paint the new blank lines that appear after that line to implement this. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-04diff --whitespace=warn/error: fix blank-at-eof checkLibravatar Junio C Hamano1-0/+7
The "diff --check" logic used to share the same issue as the one fixed for "git apply" earlier in this series, in that a patch that adds new blank lines at end could appear as @@ -l,5 +m,7 @@$ _context$ _context$ -deleted$ +$ +$ +$ _$ _$ where _ stands for SP and $ shows a end-of-line. Instead of looking at each line in the patch in the callback, simply count the blank lines from the end in two versions, and notice the presence of new ones. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-04diff --whitespace=warn/error: obey blank-at-eofLibravatar Junio C Hamano2-3/+3
The "diff --check" code used to conflate trailing-space whitespace error class with this, but now we have a proper separate error class, we should check it under blank-at-eof, not trailing-space. The whitespace error is not about _having_ blank lines at end, but about adding _new_ blank lines. To keep the message consistent with what is given by "git apply", call whitespace_error_string() to generate it, instead of using a hardcoded custom message. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-04apply --whitespace: warn blank but not necessarily empty lines at EOFLibravatar Junio C Hamano1-0/+13
The whitespace error of adding blank lines at the end of file should trigger if you added a non-empty line at the end, if the contents of the line is full of whitespaces. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-04apply --whitespace=warn/error: diagnose blank at EOFLibravatar Junio C Hamano1-0/+26
"git apply" strips new blank lines at EOF under --whitespace=fix option, but neigher --whitespace=warn nor --whitespace=error paid any attention to these errors. Introduce a new whitespace error class, blank-at-eof, to make the whitespace error handling more consistent. The patch adds a new "linenr" field to the struct fragment in order to record which line the hunk started in the input file, but this is needed solely for reporting purposes. The detection of this class of whitespace errors cannot be done while parsing a patch like we do for all the other classes of whitespace errors. It instead has to wait until we find where to apply the hunk, but at that point, we do not have an access to the original line number in the input file anymore, hence the new field. Depending on your point of view, this may be a bugfix that makes warn and error in line with fix. Or you could call it a new feature. The line between them is somewhat fuzzy in this case. Strictly speaking, triggering more errors than before is a change in behaviour that is not backward compatible, even though the reason for the change is because the code was not checking for an error that it should have. People who do not want added blank lines at EOF to trigger an error can disable the new error class. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-04apply --whitespace=fix: detect new blank lines at eof correctlyLibravatar Junio C Hamano1-0/+24
The command tries to strip blank lines at the end of the file added by a patch. It is done by first detecting if a hunk in patch has additional blank lines at the end of itself, and if so checking if such a hunk applies at the end of file. This patch addresses a bug in the logic to implement the former (the previous one addressed a bug in the latter). If the original ends with blank lines, often the patch hunk ends like this: @@ -l,5 +m,7 @@$ _context$ _context$ -deleted$ +$ +$ +$ _$ _$ where _ stands for SP and $ shows a end-of-line. This example patch adds three trailing blank lines, but the code fails to notice it, because it only pays attention to added blank lines at the very end of the hunk. In this example, the three added blank lines do not appear textually at the end in the patch, even though you can see that they are indeed added at the end, if you rearrange the diff like this: @@ -l,5 +m,7 @@$ _context$ _context$ -deleted$ _$ _$ +$ +$ +$ The fix is not to reset the number of (candidate) added blank lines at the end when the loop sees a context line that is empty. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-04apply --whitespace=fix: fix handling of blank lines at the eofLibravatar Junio C Hamano1-0/+29
b94f2ed (builtin-apply.c: make it more line oriented, 2008-01-26) broke the logic used to detect if a hunk adds blank lines at the end of the file. With the new code after that commit: - img holds the contents of the file that the hunk is being applied to; - preimage has the lines the hunk expects to be in img; and - postimage has the lines the hunk wants to update the part in img that corresponds to preimage with. and we need to compare if the last line of preimage (not postimage) matches the last line of img to see if the hunk applies at the end of the file. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-03Merge branch 'maint-1.6.3' into maintLibravatar Junio C Hamano1-2/+4
* maint-1.6.3: git-clone: add missing comma in --reference documentation git-cvsserver: no longer use deprecated 'git-subcommand' commands clone: disconnect transport after fetching
2009-09-03Merge branch 'maint-1.6.2' into maint-1.6.3Libravatar Junio C Hamano1-2/+4
* maint-1.6.2: git-clone: add missing comma in --reference documentation clone: disconnect transport after fetching
2009-09-02Merge branch 'maint'Libravatar Junio C Hamano1-2/+4
* maint: git-cvsserver: no longer use deprecated 'git-subcommand' commands clone: disconnect transport after fetching
2009-09-02Merge branch 'maint-1.6.3' into maintLibravatar Junio C Hamano1-2/+4
* maint-1.6.3: git-cvsserver: no longer use deprecated 'git-subcommand' commands clone: disconnect transport after fetching
2009-09-02Merge branch 'maint-1.6.2' into maint-1.6.3Libravatar Junio C Hamano1-2/+4
* maint-1.6.2: clone: disconnect transport after fetching
2009-09-02clone: disconnect transport after fetchingLibravatar Jeff King1-2/+4
The current code just leaves the transport in whatever state it was in after performing the fetch. For a non-empty clone over the git protocol, the transport code already disconnects at the end of the fetch. But for an empty clone, we leave the connection hanging, and eventually close the socket when clone exits. This causes the remote upload-pack to complain "the remote end hung up unexpectedly". While this message is harmless to the clone itself, it is unnecessarily scary for a user to see and may pollute git-daemon logs. This patch just explicitly calls disconnect after we are done with the remote end, which sends a flush packet to upload-pack and cleanly disconnects, avoiding the error message. Other transports are unaffected or slightly improved: - for a non-empty repo over the git protocol, the second disconnect is a no-op (since we are no longer connected) - for "walker" transports (like HTTP or FTP), we actually free some used memory (which previously just sat until the clone process exits) - for "rsync", disconnect is always a no-op anyway Signed-off-by: Jeff King <peff@peff.net> Acked-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>