summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2016-09-08Merge branch 'sg/reflog-past-root' into maintLibravatar Junio C Hamano1-1/+0
A small test clean-up for a topic introduced in v2.9.1 and later. * sg/reflog-past-root: t1410: remove superfluous 'git reflog' from the 'walk past root' test
2016-09-08Merge branch 'bw/mingw-avoid-inheriting-fd-to-lockfile' into maintLibravatar Junio C Hamano1-0/+13
The tempfile (hence its user lockfile) API lets the caller to open a file descriptor to a temporary file, write into it and then finalize it by first closing the filehandle and then either removing or renaming the temporary file. When the process spawns a subprocess after obtaining the file descriptor, and if the subprocess has not exited when the attempt to remove or rename is made, the last step fails on Windows, because the subprocess has the file descriptor still open. Open tempfile with O_CLOEXEC flag to avoid this (on Windows, this is mapped to O_NOINHERIT). * bw/mingw-avoid-inheriting-fd-to-lockfile: mingw: ensure temporary file handles are not inherited by child processes t6026-merge-attr: child processes must not inherit index.lock handles
2016-09-08Merge branch 'jk/difftool-command-not-found' into maintLibravatar Junio C Hamano1-0/+6
"git difftool" by default ignores the error exit from the backend commands it spawns, because often they signal that they found differences by exiting with a non-zero status code just like "diff" does; the exit status codes 126 and above however are special in that they are used to signal that the command is not executable, does not exist, or killed by a signal. "git difftool" has been taught to notice these exit status codes. * jk/difftool-command-not-found: difftool: always honor fatal error exit codes
2016-09-08Merge branch 'sb/checkout-explit-detach-no-advice' into maintLibravatar Junio C Hamano1-0/+23
"git checkout --detach <branch>" used to give the same advice message as that is issued when "git checkout <tag>" (or anything that is not a branch name) is given, but asking with "--detach" is an explicit enough sign that the user knows what is going on. The advice message has been squelched in this case. * sb/checkout-explit-detach-no-advice: checkout: do not mention detach advice for explicit --detach option
2016-09-08Merge branch 'rs/pull-signed-tag' into maintLibravatar Junio C Hamano1-0/+18
When "git merge-recursive" works on history with many criss-cross merges in "verbose" mode, the names the command assigns to the virtual merge bases could have overwritten each other by unintended reuse of the same piece of memory. * rs/pull-signed-tag: commit: use FLEX_ARRAY in struct merge_remote_desc merge-recursive: fix verbose output for multiple base trees commit: factor out set_merge_remote_desc() commit: use xstrdup() in get_merge_parent()
2016-09-08Merge branch 'js/test-lint-pathname' into maintLibravatar Junio C Hamano1-1/+10
The "t/" hierarchy is prone to get an unusual pathname; "make test" has been taught to make sure they do not contain paths that cannot be checked out on Windows (and the mechanism can be reusable to catch pathnames that are not portable to other platforms as need arises). * js/test-lint-pathname: t/Makefile: ensure that paths are valid on platforms we care
2016-09-08Merge branch 'jk/push-force-with-lease-creation' into maintLibravatar Junio C Hamano1-0/+38
"git push --force-with-lease" already had enough logic to allow ensuring that such a push results in creation of a ref (i.e. the receiving end did not have another push from sideways that would be discarded by our force-pushing), but didn't expose this possibility to the users. It does so now. * jk/push-force-with-lease-creation: t5533: make it pass on case-sensitive filesystems push: allow pushing new branches with --force-with-lease push: add shorthand for --force-with-lease branch creation Documentation/git-push: fix placeholder formatting
2016-09-08Merge branch 'jk/reflog-date' into maintLibravatar Junio C Hamano1-0/+3
The reflog output format is documented better, and a new format --date=unix to report the seconds-since-epoch (without timezone) has been added. * jk/reflog-date: date: clarify --date=raw description date: add "unix" format date: document and test "raw-local" mode doc/pretty-formats: explain shortening of %gd doc/pretty-formats: describe index/time formats for %gd doc/rev-list-options: explain "-g" output formats doc/rev-list-options: clarify "commit@{Nth}" for "-g" option
2016-09-08Merge branch 'jc/renormalize-merge-kill-safer-crlf' into maintLibravatar Junio C Hamano3-48/+59
"git merge" with renormalization did not work well with merge-recursive, due to "safer crlf" conversion kicking in when it shouldn't. * jc/renormalize-merge-kill-safer-crlf: merge: avoid "safer crlf" during recording of merge results convert: unify the "auto" handling of CRLF
2016-09-08Merge branch 'jk/common-main' into maintLibravatar Junio C Hamano33-43/+43
There are certain house-keeping tasks that need to be performed at the very beginning of any Git program, and programs that are not built-in commands had to do them exactly the same way as "git" potty does. It was easy to make mistakes in one-off standalone programs (like test helpers). A common "main()" function that calls cmd_main() of individual program has been introduced to make it harder to make mistakes. * jk/common-main: mingw: declare main()'s argv as const common-main: call git_setup_gettext() common-main: call restore_sigpipe_to_default() common-main: call sanitize_stdfds() common-main: call git_extract_argv0_path() add an extra level of indirection to main()
2016-08-23mingw: ensure temporary file handles are not inherited by child processesLibravatar Ben Wijen1-1/+1
When the index is locked and child processes inherit the handle to said lock and the parent process wants to remove the lock before the child process exits, on Windows there is a problem: it won't work because files cannot be deleted if a process holds a handle on them. The symptom: Rename from 'xxx/.git/index.lock' to 'xxx/.git/index' failed. Should I try again? (y/n) Spawning child processes with bInheritHandles==FALSE would not work because no file handles would be inherited, not even the hStdXxx handles in STARTUPINFO (stdin/stdout/stderr). Opening every file with O_NOINHERIT does not work, either, as e.g. git-upload-pack expects inherited file handles. This leaves us with the only way out: creating temp files with the O_NOINHERIT flag. This flag is Windows-specific, however. For our purposes, it is equivalent to O_CLOEXEC (which does not exist on Windows), so let's just open temporary files with the O_CLOEXEC flag and map that flag to O_NOINHERIT on Windows. As Eric Wong pointed out, we need to be careful to handle the case where the Linux headers used to compile Git support O_CLOEXEC but the Linux kernel used to run Git does not: it returns an EINVAL. This fixes the test that we just introduced to demonstrate the problem. Signed-off-by: Ben Wijen <ben@wijen.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-18t6026-merge-attr: child processes must not inherit index.lock handlesLibravatar Ben Wijen1-0/+13
On Windows, a file cannot be removed unless all file handles to it have been released. Hence it is particularly important to close handles when spawning children (which would probably not even know that they hold on to those handles). The example chosen for this test is a custom merge driver that indeed has no idea that it blocks the deletion of index.lock. The full use case is a daemon that lives on after the merge, with subsequent invocations handing off to the daemon, thereby avoiding hefty start-up costs. We simulate this behavior by simply sleeping one second. Note that the test only fails on Windows, due to the file locking issue. Since we have no way to say "expect failure with MINGW, success otherwise", we simply skip this test on Windows for now. Signed-off-by: Ben Wijen <ben@wijen.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-16t/Makefile: ensure that paths are valid on platforms we careLibravatar Johannes Schindelin1-1/+10
Some pathnames that are okay on ext4 and on HFS+ cannot be checked out on Windows. Tests that want to see operations on such paths on filesystems that support them must do so behind appropriate test prerequisites, and must not include them in the source tree (instead they should create them when they run). Otherwise, the source tree cannot even be checked out. Make sure that double-quotes, asterisk, colon, greater/less-than, question-mark, backslash, tab, vertical-bar, as well as any non-ASCII characters never appear in the pathnames with a new test-lint-* target as part of a `make test`. To that end, we call `git ls-files` (ensuring that the paths are quoted properly), relying on the fact that paths containing non-ASCII characters are quoted within double-quotes. In case that the source code does not actually live in a Git repository (e.g. when extracted from a .zip file), or that the `git` executable cannot be executed, we simply ignore the error for now; In that case, our trusty Continuous Integration will be the last line of defense and catch any problematic file name. Noticed when a topic wanted to add a pathname with '>' in it. A check like this will prevent a similar problems from happening in the future. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-15difftool: always honor fatal error exit codesLibravatar John Keeping1-0/+6
At the moment difftool's "trust exit code" logic always suppresses the exit status of the diff utility we invoke. This is useful because we don't want to exit just because diff returned "1" because the files differ, but it's confusing if the shell returns an error because the selected diff utility is not found. POSIX specifies 127 as the exit status for "command not found", 126 for "command found but is not executable" and values greater than 128 if the command terminated because it received a signal [1] and at least bash and dash follow this specification, while diff utilities generally use "1" for the exit status we want to ignore. Handle any value of 126 or greater as a special value indicating that some form of fatal error occurred. [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_02 Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-15checkout: do not mention detach advice for explicit --detach optionLibravatar Stefan Beller1-0/+23
When a user asked for a detached HEAD specifically with `--detach`, we do not need to give advice on what a detached HEAD state entails as we can assume they know what they're getting into as they asked for it. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-15t1410: remove superfluous 'git reflog' from the 'walk past root' testLibravatar SZEDER Gábor1-1/+0
The test added in 71abeb753fa8 (reflog: continue walking the reflog past root commits, 2016-06-03) contains an unnecessary 'git reflog' execution, which was part of my debug/tracing instrumentation that I somehow didn't manage to remove before submitting. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-13merge-recursive: fix verbose output for multiple base treesLibravatar René Scharfe1-0/+18
One of the indirect callers of make_virtual_commit() passes the result of oid_to_hex() as the name, i.e. a pointer to a static buffer. Since the function uses that string pointer directly in building a struct merge_remote_desc, multiple entries can end up sharing the same name inadvertently. Fix that by calling set_merge_remote_desc(), which creates a copy of the string, instead of building the struct by hand. Signed-off-by: Rene Scharfe <l.s.r@web.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-12Merge branch 'jk/difftool-in-subdir' into maintLibravatar Junio C Hamano1-0/+14
"git difftool <paths>..." started in a subdirectory failed to interpret the paths relative to that directory, which has been fixed. * jk/difftool-in-subdir: difftool: use Git::* functions instead of passing around state difftool: avoid $GIT_DIR and $GIT_WORK_TREE difftool: fix argument handling in subdirs
2016-08-10Merge branch 'rs/use-strbuf-addstr' into maintLibravatar Junio C Hamano1-3/+3
* rs/use-strbuf-addstr: use strbuf_addstr() instead of strbuf_addf() with "%s" use strbuf_addstr() for adding constant strings to a strbuf
2016-08-10Merge branch 'jk/t4205-cleanup' into maintLibravatar Junio C Hamano1-198/+200
Test modernization. * jk/t4205-cleanup: t4205: indent here documents t4205: drop top-level &&-chaining
2016-08-10Merge branch 'nd/fbsd-lazy-mtime' into maintLibravatar Junio C Hamano1-1/+16
FreeBSD can lie when asked mtime of a directory, which made the untracked cache code to fall back to a slow-path, which in turn caused tests in t7063 to fail because it wanted to verify the behaviour of the fast-path. * nd/fbsd-lazy-mtime: t7063: work around FreeBSD's lazy mtime update feature
2016-08-10Merge branch 'js/t4130-rename-without-ino' into maintLibravatar Junio C Hamano1-3/+7
Windows port was failing some tests in t4130, due to the lack of inum in the returned values by its lstat(2) emulation. * js/t4130-rename-without-ino: t4130: work around Windows limitation
2016-08-10Merge branch 'jc/grep-commandline-vs-configuration' into maintLibravatar Junio C Hamano1-0/+14
"git -c grep.patternType=extended log --basic-regexp" misbehaved because the internal API to access the grep machinery was not designed well. * jc/grep-commandline-vs-configuration: grep: further simplify setting the pattern type
2016-08-10Merge branch 'jk/diff-do-not-reuse-wtf-needs-cleaning' into maintLibravatar Junio C Hamano1-0/+11
There is an optimization used in "git diff $treeA $treeB" to borrow an already checked-out copy in the working tree when it is known to be the same as the blob being compared, expecting that open/mmap of such a file is faster than reading it from the object store, which involves inflating and applying delta. This however kicked in even when the checked-out copy needs to go through the convert-to-git conversion (including the clean filter), which defeats the whole point of the optimization. The optimization has been disabled when the conversion is necessary. * jk/diff-do-not-reuse-wtf-needs-cleaning: diff: do not reuse worktree files that need "clean" conversion
2016-08-10Merge branch 'mm/status-suggest-merge-abort' into maintLibravatar Junio C Hamano2-0/+5
"git status" learned to suggest "merge --abort" during a conflicted merge, just like it already suggests "rebase --abort" during a conflicted rebase. * mm/status-suggest-merge-abort: status: suggest 'git merge --abort' when appropriate
2016-08-08Merge branch 'rs/submodule-config-code-cleanup' into maintLibravatar Junio C Hamano2-1/+12
Code cleanup. * rs/submodule-config-code-cleanup: submodule-config: fix test binary crashing when no arguments given submodule-config: combine early return code into one goto submodule-config: passing name reference for .gitmodule blobs submodule-config: use explicit empty string instead of strbuf in config_from()
2016-08-08Merge branch 'nd/test-helpers' into maintLibravatar Junio C Hamano1-1/+1
Build clean-up. * nd/test-helpers: t/test-lib.sh: fix running tests with --valgrind Makefile: use VCSSVN_LIB to refer to svn library Makefile: drop extra dependencies for test helpers
2016-08-08Merge branch 'ah/unpack-trees-advice-messages' into maintLibravatar Junio C Hamano3-7/+7
Grammofix. * ah/unpack-trees-advice-messages: unpack-trees: fix English grammar in do-this-before-that messages
2016-08-08Merge branch 'nd/pack-ofs-4gb-limit' into maintLibravatar Junio C Hamano1-4/+3
"git pack-objects" and "git index-pack" mostly operate with off_t when talking about the offset of objects in a packfile, but there were a handful of places that used "unsigned long" to hold that value, leading to an unintended truncation. * nd/pack-ofs-4gb-limit: fsck: use streaming interface for large blobs in pack pack-objects: do not truncate result in-pack object size on 32-bit systems index-pack: correct "offset" type in unpack_entry_data() index-pack: report correct bad object offsets even if they are large index-pack: correct "len" type in unpack_data() sha1_file.c: use type off_t* for object_info->disk_sizep pack-objects: pass length to check_pack_crc() without truncation
2016-08-08Merge branch 'js/ignore-space-at-eol' into maintLibravatar Junio C Hamano1-0/+8
An age old bug that caused "git diff --ignore-space-at-eol" misbehave has been fixed. * js/ignore-space-at-eol: diff: fix a double off-by-one with --ignore-space-at-eol diff: demonstrate a bug with --patience and --ignore-space-at-eol
2016-08-08Merge branch 'jk/push-scrub-url' into maintLibravatar Junio C Hamano1-0/+9
"git fetch http://user:pass@host/repo..." scrubbed the userinfo part, but "git push" didn't. * jk/push-scrub-url: t5541: fix url scrubbing test when GPG is not set push: anonymize URL in status output
2016-08-08Merge branch 'nd/cache-tree-ita' into maintLibravatar Junio C Hamano14-50/+76
"git add -N dir/file && git write-tree" produced an incorrect tree when there are other paths in the same directory that sorts after "file". * nd/cache-tree-ita: cache-tree: do not generate empty trees as a result of all i-t-a subentries cache-tree.c: fix i-t-a entry skipping directory updates sometimes test-lib.sh: introduce and use $EMPTY_BLOB test-lib.sh: introduce and use $EMPTY_TREE
2016-08-08Merge branch 'mh/blame-worktree' into maintLibravatar Junio C Hamano1-17/+62
"git blame file" allowed the lineage of lines in the uncommitted, unadded contents of "file" to be inspected, but it refused when "file" did not appear in the current commit. When "file" was created by renaming an existing file (but the change has not been committed), this restriction was unnecessarily tight. * mh/blame-worktree: t/t8003-blame-corner-cases.sh: Use here documents blame: allow to blame paths freshly added to the index
2016-08-04t5533: make it pass on case-sensitive filesystemsLibravatar Johannes Schindelin1-1/+1
The newly-added test case wants to commit a file "c.t" (note the lower case) when a previous test case already committed a file "C.t". This confuses Git to the point that it thinks "c.t" was not staged when "git add c.t" was called. Simply make the naming of the test commits consistent with the previous test cases: use upper-case, and advance in the alphabet. This came up in local work to rebase the Windows-specific patches to the current `next` branch. An identical fix was suggested by John Keeping. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-04t7063: work around FreeBSD's lazy mtime update featureLibravatar Nguyễn Thái Ngọc Duy1-1/+16
Let's start with the commit message of [1] from freebsd.git [2] Sync timestamp changes for inodes of special files to disk as late as possible (when the inode is reclaimed). Temporarily only do this if option UFS_LAZYMOD configured and softupdates aren't enabled. UFS_LAZYMOD is intentionally left out of /sys/conf/options. This is mainly to avoid almost useless disk i/o on battery powered machines. It's silly to write to disk (on the next sync or when the inode becomes inactive) just because someone hit a key or something wrote to the screen or /dev/null. PR: 5577 [3] The short version of that, in the context of t7063, is that when a directory is updated, its mtime may be updated later, not immediately. This can be shown with a simple command sequence date; sleep 1; touch abc; rm abc; sleep 10; ls -lTd . One would expect that the date shown in `ls` would be one second from `date`, but it's 10 seconds later. If we put another `ls -lTd .` in front of `sleep 10`, then the date of the last `ls` comes as expected. The first `ls` somehow forces mtime to be updated. t7063 is really sensitive to directory mtime. When mtime is too "new", git code suspects racy timestamps and will not trigger the shortcut in untracked cache, in t7063.24 and eventually be detected in t7063.27 We have two options thanks to this special FreeBSD feature: 1) Stop supporting untracked cache on FreeBSD. Skip t7063 entirely when running on FreeBSD 2) Work around this problem (using the same 'ls' trick) and continue to support untracked cache on FreeBSD I initially wanted to go with 1) because I didn't know the exact nature of this feature and feared that it would make untracked cache work unreliably, using the cached version when it should not. Since the behavior of this thing is clearer now. The picture is not that bad. If this indeed happens often, untracked cache would assume racy condition more often and _fall back_ to non-untracked cache code paths. Which means it may be less effective, but it will not show wrong things. This patch goes with option 2. PS. For those who want to look further in FreeBSD source code, this flag is now called IN_LAZYMOD. I can see it's effective in ext2 and ufs. zfs is not affected. [1] 660e6408e6df99a20dacb070c5e7f9739efdf96d [2] git://github.com/freebsd/freebsd.git [3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=5577 Reported-by: Eric Wong <e@80x24.org> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-03t4130: work around Windows limitationLibravatar Johannes Sixt1-3/+7
On Windows, it is already pretty expensive to try to recreate the stat() data that Git assumes is cheap to obtain. To make things halfway decent in performance, we even have to skip emulating the inode and to determine the number of hard links. This is not a huge problem, usually, as either the size or the mtime or the ctime are tell-tale enough to say when a file has changed, and even if not, those changes are typically made after the index file was written, triggering a rehashing of the files' contents. The t4130-apply-criss-cross-rename test case, however, requires the inode to determine that files of equal size were swapped, as renaming files does not update their mtime. Every once in a while, t4130 fails on Windows because of this missing piece. Equal file sizes are not crucial for the test cases, however. Hence, generate files with different sizes so that there is some property that the swapped files can be discovered reliably even on Windows. Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-01use strbuf_addstr() for adding constant strings to a strbufLibravatar René Scharfe1-3/+3
Replace uses of strbuf_addf() for adding strings with more lightweight strbuf_addstr() calls. In http-push.c it becomes easier to see what's going on without having to verfiy that the definition of PROPFIND_ALL_REQUEST doesn't contain any format specifiers. Signed-off-by: Rene Scharfe <l.s.r@web.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-28difftool: avoid $GIT_DIR and $GIT_WORK_TREELibravatar David Aguilar1-0/+14
Environment variables are global and hard to reason about. Use the `--git-dir` and `--work-tree` arguments when invoking `git` instead of relying on the environment. Add a test to ensure that difftool's dir-diff feature works when these variables are present in the environment. Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-28submodule-config: passing name reference for .gitmodule blobsLibravatar Heiko Voigt1-0/+11
Commit 959b5455 (submodule: implement a config API for lookup of .gitmodules values, 2015-08-18) implemented the initial version of the submodule config cache. During development of that initial version we extracted the function gitmodule_sha1_from_commit(). During that process we missed that the strbuf rev was still used in config_from() and now is left empty. Lets fix this by also returning this string. This means that now when reading .gitmodules from revisions, the error messages also contain a reference to the blob they are from. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-28Merge branch 'ak/lazy-prereq-mktemp' into maintLibravatar Junio C Hamano1-1/+6
A test that unconditionally used "mktemp" learned that the command is not necessarily available everywhere. * ak/lazy-prereq-mktemp: t7610: test for mktemp before test execution
2016-07-28Merge branch 'nd/icase' into maintLibravatar Junio C Hamano4-3/+148
"git grep -i" has been taught to fold case in non-ascii locales correctly. * nd/icase: grep.c: reuse "icase" variable diffcore-pickaxe: support case insensitive match on non-ascii diffcore-pickaxe: Add regcomp_or_die() grep/pcre: support utf-8 gettext: add is_utf8_locale() grep/pcre: prepare locale-dependent tables for icase matching grep: rewrite an if/else condition to avoid duplicate expression grep/icase: avoid kwsset when -F is specified grep/icase: avoid kwsset on literal non-ascii strings test-regex: expose full regcomp() to the command line test-regex: isolate the bug test code grep: break down an "if" stmt in preparation for next changes
2016-07-28Merge branch 'jk/test-match-signal' into maintLibravatar Junio C Hamano3-11/+26
The test framework learned a new helper test_match_signal to check an exit code from getting killed by an expected signal. * jk/test-match-signal: t/lib-git-daemon: use test_match_signal test_must_fail: use test_match_signal t0005: use test_match_signal as appropriate tests: factor portable signal check out of t0005
2016-07-28Merge branch 'js/t3404-grammo-fix' into maintLibravatar Junio C Hamano1-1/+1
Grammofix. * js/t3404-grammo-fix: t3404: fix a grammo (commands are ran -> commands are run)
2016-07-28Merge branch 'ps/rebase-i-auto-unstash-upon-abort' into maintLibravatar Junio C Hamano1-0/+31
"git rebase -i --autostash" did not restore the auto-stashed change when the operation was aborted. * ps/rebase-i-auto-unstash-upon-abort: rebase -i: restore autostash on abort
2016-07-28Merge branch 'nd/ita-cleanup' into maintLibravatar Junio C Hamano1-1/+59
Git does not know what the contents in the index should be for a path added with "git add -N" yet, so "git grep --cached" should not show hits (or show lack of hits, with -L) in such a path, but that logic does not apply to "git grep", i.e. searching in the working tree files. But we did so by mistake, which has been corrected. * nd/ita-cleanup: grep: fix grepping for "intent to add" files t7810-grep.sh: fix a whitespace inconsistency t7810-grep.sh: fix duplicated test name
2016-07-28Merge branch 'js/find-commit-subject-ignore-leading-blanks' into maintLibravatar Junio C Hamano1-0/+17
A helper function that takes the contents of a commit object and finds its subject line did not ignore leading blank lines, as is commonly done by other codepaths. Make it ignore leading blank lines to match. * js/find-commit-subject-ignore-leading-blanks: reset --hard: skip blank lines when reporting the commit subject sequencer: use skip_blank_lines() to find the commit subject commit -C: skip blank lines at the beginning of the message commit.c: make find_commit_subject() more robust pretty: make the skip_blank_lines() function public
2016-07-28Merge branch 'dg/subtree-rebase-test' into maintLibravatar Junio C Hamano1-0/+119
Add a test to specify the desired behaviour that currently is not available in "git rebase -Xsubtree=...". * dg/subtree-rebase-test: contrib/subtree: Add a test for subtree rebase that loses commits
2016-07-27date: add "unix" formatLibravatar Jeff King1-0/+2
We already have "--date=raw", which is a Unix epoch timestamp plus a contextual timezone (either the author's or the local). But one may not care about the timezone and just want the epoch timestamp by itself. It's not hard to parse the two apart, but if you are using a pretty-print format, you may want git to show the "finished" form that the user will see. We can accomodate this by adding a new date format, "unix", which is basically "raw" without the timezone. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-27date: document and test "raw-local" modeLibravatar Jeff King1-0/+1
The "raw" format shows a Unix epoch timestamp, but with a timezone tacked on. The timestamp is not _in_ that zone, but it is extra information about the time (by default, the zone the author was in). The documentation claims that "raw-local" does not work. It does, but the end result is rather subtle. Let's describe it in better detail, and test to make sure it works (namely, the epoch time doesn't change, but the zone does). While we are rewording the documentation in this area, let's not use the phrase "does not work" for the remaining option, "--date=relative". It's vague; do we accept it or not? We do accept it, but it has no effect (which is a reasonable outcome). We should also refer to the option not as "--relative" (which is the historical synonym, and does not take "-local" at all), but as "--date=relative". Helped-by: Jakub Narębski <jnareb@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-27t4205: indent here documentsLibravatar Jeff King1-196/+196
Our usual style in the test scripts is to indent here documents with tabs, and use "<<-" to strip the tabs. The result is easier to read. This old test script did not do so in its inception, and further tests added onto it followed the local style. Let's bring it in line with our usual style. Some of the tests actually care quite a bit about whitespace, but none of them do so at the beginning of the line (because they use things like qz_to_tab_space to avoid depending on the literal whitespace), so we can do a fairly mechanical conversion. Most of the here-docs also use interpolation, so they have been left as "<<-EOF". In a few cases, though, where interpolation was not in use, I've converted them to "<<-\EOF" to match our usual "don't interpolate unless you need to" style. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>