summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2016-07-22submodule-helper: fix indexing in clone retry error reporting pathLibravatar Johannes Sixt2-4/+4
'git submodule--helper update-clone' has logic to retry failed clones a second time. For this purpose, there is a list of submodules to clone, and a second list that is filled with the submodules to retry. Within these lists, the submodules are identified by an index as if both lists were just appended. This works nicely except when the second clone attempt fails as well. To report an error, the identifying index must be adjusted by an offset so that it can be used as an index into the second list. However, the calculation uses the logical total length of the lists so that the result always points one past the end of the second list. Pick the correct index. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Acked-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-22git-submodule: forward exit code of git-submodule--helper more faithfullyLibravatar Johannes Sixt2-4/+4
git-submodule--helper is invoked as the upstream of a pipe in several places. Usually, the failure of a program in this position is not detected by the shell. For this reason, the code inserts a token in the output stream when git-submodule--helper fails that is detected downstream, where the shell script is quit with exit code 1. There happens to be a bug in git-submodule--helper that leads to a segmentation fault. The test suite triggers the crash in several places, all of which are protected by 'test_must_fail'. But due to the inspecific exit code 1, the crash remains undiagnosed. Extend the failure protocol such that git-submodule--helper's exit code is passed downstream (only in the case of failure). This enables the downstream to use it as its own exit code, and 'test_must_fail' to identify the segmentation fault as an unexpected failure. The bug itself is fixed in the next commit. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Acked-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-06Merge branch 'jc/t2300-setup'Libravatar Junio C Hamano1-1/+9
Portability fix for Windows. * jc/t2300-setup: t2300: "git --exec-path" is not usable in $PATH on Windows as-is
2016-07-06Merge branch 'cb/t7810-test-label-fix'Libravatar Junio C Hamano1-1/+1
Test clean-up. * cb/t7810-test-label-fix: t7810: fix duplicated test title
2016-07-06Merge branch 'sb/t5614-modernize'Libravatar Junio C Hamano1-50/+20
Test clean-up. * sb/t5614-modernize: t5614: don't use subshells
2016-07-06Merge branch 'js/perf-on-apple'Libravatar Junio C Hamano1-1/+5
t/perf needs /usr/bin/time with GNU extension; the invocation of it is updated to "gtime" on Darwin. * js/perf-on-apple: perf: accommodate for MacOSX
2016-07-06Merge branch 'ak/t7800-wo-readlink'Libravatar Junio C Hamano1-1/+1
One among four invocations of readlink(1) in our test suite has been rewritten so that the test can run on systems without the command (others are in valgrind test framework and t9802). * ak/t7800-wo-readlink: t7800: readlink may not be available
2016-07-06Merge branch 'jk/tzoffset-fix'Libravatar Junio C Hamano2-17/+69
The internal code used to show local timezone offset is not prepared to handle timestamps beyond year 2100, and gave a bogus offset value to the caller. Use a more benign looking +0000 instead and let "git log" going in such a case, instead of aborting. * jk/tzoffset-fix: local_tzoffset: detect errors from tm_to_time_t t0006: test various date formats t0006: rename test-date's "show" to "relative"
2016-07-06Merge branch 'sb/clone-shallow-passthru'Libravatar Junio C Hamano1-2/+17
Fix an unintended regression in v2.9 that breaks "clone --depth" that recurses down to submodules by forcing the submodules to also be cloned shallowly, which many server instances that host upstream of the submodules are not prepared for. * sb/clone-shallow-passthru: clone: do not let --depth imply --shallow-submodules
2016-07-06Merge branch 'jk/gpg-interface-cleanup'Libravatar Junio C Hamano1-1/+8
A new run-command API function pipe_command() is introduced to sanely feed data to the standard input while capturing data from the standard output and the standard error of an external process, which is cumbersome to hand-roll correctly without deadlocking. The codepath to sign data in a prepared buffer with GPG has been updated to use this API to read from the status-fd to check for errors (instead of relying on GPG's exit status). * jk/gpg-interface-cleanup: gpg-interface: check gpg signature creation status sign_buffer: use pipe_command verify_signed_buffer: use pipe_command run-command: add pipe_command helper verify_signed_buffer: use tempfile object verify_signed_buffer: drop pbuf variable gpg-interface: use child_process.args
2016-07-06Merge branch 'nd/graph-width-padded'Libravatar Junio C Hamano1-0/+57
"log --graph --format=" learned that "%>|(N)" specifies the width relative to the terminal's left edge, not relative to the area to draw text that is to the right of the ancestry-graph section. It also now accepts negative N that means the column limit is relative to the right border. * nd/graph-width-padded: pretty.c: support <direction>|(<negative number>) forms pretty: pass graph width to pretty formatting for use in '%>|(N)'
2016-07-06Merge branch 'jk/repack-keep-unreachable'Libravatar Junio C Hamano1-0/+28
"git repack" learned the "--keep-unreachable" option, which sends loose unreachable objects to a pack instead of leaving them loose. This helps heuristics based on the number of loose objects (e.g. "gc --auto"). * jk/repack-keep-unreachable: repack: extend --keep-unreachable to loose objects repack: add --keep-unreachable option repack: document --unpack-unreachable option
2016-07-06Merge branch 'ew/mboxrd-format-am'Libravatar Junio C Hamano6-0/+120
Teach format-patch and mailsplit (hence "am") how a line that happens to begin with "From " in the e-mail message is quoted with ">", so that these lines can be restored to their original shape. * ew/mboxrd-format-am: am: support --patch-format=mboxrd mailsplit: support unescaping mboxrd messages pretty: support "mboxrd" output format
2016-07-06Merge branch 'jk/upload-pack-hook'Libravatar Junio C Hamano3-0/+125
"upload-pack" allows a custom "git pack-objects" replacement when responding to "fetch/clone" via the uploadpack.packObjectsHook. * jk/upload-pack-hook: upload-pack: provide a hook for running pack-objects t1308: do not get fooled by symbolic links to the source tree config: add a notion of "scope" config: return configset value for current_config_ functions config: set up config_source for command-line config git_config_parse_parameter: refactor cleanup code git_config_with_options: drop "found" counting
2016-07-06Merge branch 'nd/test-lib-httpd-show-error-log-in-verbose'Libravatar Junio C Hamano1-0/+1
HTTPd tests learned to show the server error log to help diagnosing a failing tests. * nd/test-lib-httpd-show-error-log-in-verbose: lib-httpd.sh: print error.log on error
2016-07-06Merge branch 'jk/string-list-static-init'Libravatar Junio C Hamano1-1/+1
Instead of taking advantage of a struct string_list that is allocated with all NULs happens to be STRING_LIST_INIT_NODUP kind, initialize them explicitly as such, to document their behaviour better. * jk/string-list-static-init: use string_list initializer consistently blame,shortlog: don't make local option variables static interpret-trailers: don't duplicate option strings parse_opt_string_list: stop allocating new strings
2016-06-27Merge branch 'et/add-chmod-x'Libravatar Junio C Hamano1-0/+30
"git update-index --add --chmod=+x file" may be usable as an escape hatch, but not a friendly thing to force for people who do need to use it regularly. "git add --chmod=+x file" can be used instead. * et/add-chmod-x: add: add --chmod=+x / --chmod=-x options
2016-06-27Merge branch 'sg/reflog-past-root'Libravatar Junio C Hamano2-1/+23
"git reflog" stopped upon seeing an entry that denotes a branch creation event (aka "unborn"), which made it appear as if the reflog was truncated. * sg/reflog-past-root: reflog: continue walking the reflog past root commits
2016-06-22t2300: "git --exec-path" is not usable in $PATH on Windows as-isLibravatar Johannes Schindelin1-1/+9
The "git" command prepends the exec-path to the PATH environment variable for processes it spawns. That is how ". git-sh-setup" in our scripted Porcelains can find the dot-sourced file in the exec-path location that is not usually on user's PATH. When t2300 runs, because it is not spawned by the "git" command, the scriptlet being tested did not run with a realistic setting of PATH environment. It lacked the exec-path on the PATH, and failed to find the dot-sourced file. A recent update to t2300 attempted to fix this, with "PATH=$(git --exec-path):$PATH", which has been the recommended way around v1.6.0 days (a script whose original was written before that release that survives to this day is likely to have such a line). However, the "git --exec-path" command outputs C:\path\to\exec\dir (not /c/path/to/exec/dir) on Windows; the recent update failed to consider the problem that comes from it. Even though Git itself, when doing the equivalent internally, does so in a platform native way (i.e. on Windows, C:\path\to\exec\dir is prepended to the existing value of %PATH% using ';' as a component separator), the result is further massaged by bash and gets turned into $PATH that uses /c/path/to/exec/dir with ':' separating the components, which is the form understood by bash, so scripted Porcelains find commands from PATH correctly. An end user script written in shell, however, cannot prepend "C:\path\to\exec\dir:" to the existing value of $PATH and expect bash to magically turn it into the form it understands. In other words, "PATH=$(git --exec-path):$PATH" does not work as an emulation of what "Git" internally does to the PATH on Windows. To correctly emulate how exec-path is prepended to the PATH environment internally on Windows, we'd need to convert C:\git-sdk-64\usr\src\git to at least /c\git-sdk-64\usr\src\git ourselves before prepending it to PATH. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-21t7810: fix duplicated test titleLibravatar Charles Bailey1-1/+1
Signed-off-by: Charles Bailey <charles@hashpling.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-21t5614: don't use subshellsLibravatar Stefan Beller1-50/+20
Using a subshell for just one git command is both a waste in compute overhead (create a new process) as well as in line count. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-21t7800: readlink may not be availableLibravatar Armin Kunaschik1-1/+1
The readlink(1) command is not available on all platforms (notably not on AIX and HP-UX) and can be replaced in this test with the "workaround" ls -ld <name> | sed -e 's/.* -> //' This is no universal readlink replacement but works in the controlled test environment well enough. Signed-off-by: Armin Kunaschik <megabreit@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-21perf: accommodate for MacOSXLibravatar Johannes Schindelin1-1/+5
As this developer has no access to MacOSX developer setups anymore, Travis becomes the best bet to run performance tests on that OS. However, on MacOSX /usr/bin/time is that good old BSD executable that no Linux user cares about, as demonstrated by the perf-lib.sh's use of GNU-ish extensions. And by the hard-coded path. Let's just work around this issue by using gtime on MacOSX, the Homebrew-provided GNU implementation onto which pretty much every MacOSX power user falls back anyway. To help other developers use Travis to run performance tests on MacOSX, the .travis.yml file now sports a commented-out line that installs GNU time via Homebrew. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20local_tzoffset: detect errors from tm_to_time_tLibravatar Jeff King1-0/+5
When we want to know the local timezone offset at a given timestamp, we compute it by asking for localtime() at the given time, and comparing the offset to GMT at that time. However, there's some juggling between time_t and "struct tm" which happens, which involves calling our own tm_to_time_t(). If that function returns an error (e.g., because it only handles dates up to the year 2099), it returns "-1", which we treat as a time_t, and is clearly bogus, leading to bizarre timestamps (that seem to always adjust the time back to (time_t)(uint32_t)-1, in the year 2106). It's not a good idea for local_tzoffset() to simply die here; it would make it hard to run "git log" on a repository with funny timestamps. Instead, let's just treat such cases as "zero offset". Reported-by: Norbert Kiesel <nkiesel@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20t0006: test various date formatsLibravatar Jeff King1-0/+21
We ended up testing some of these date formats throughout the rest of the suite (e.g., via for-each-ref's "$(authordate:...)" format), but we never did so systematically. t0006 is the right place for unit-testing of our date-handling code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20t0006: rename test-date's "show" to "relative"Libravatar Jeff King1-13/+13
The "show" tests are really only checking relative formats; we should make that more clear. This also frees up the "show" name to later check other formats. We could later fold "relative" into a more generic "show" command, but it's not worth it. Relative times are a special case already because we have to munge the concept of "now" in our tests. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20clone: do not let --depth imply --shallow-submodulesLibravatar Junio C Hamano1-2/+17
In v2.9.0, we prematurely flipped the default to force cloning submodules shallowly, when the superproject is getting cloned shallowly. This is likely to fail when the upstream repositories submodules are cloned from a repository that is not prepared to serve histories that ends at a commit that is not at the tip of a branch, and we know the world is not yet ready. Use a safer default to clone the submodules fully, unless the user tells us that she knows that the upstream repository of the submodules are willing to cooperate with "--shallow-submodules" option. Noticed-by: Vadim Eisenberg <VADIME@il.ibm.com> Helped-by: Jeff King <peff@peff.net> Helped-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20Merge branch 'rs/xdiff-hunk-with-func-line'Libravatar Junio C Hamano7-77/+278
"git show -W" (extend hunks to cover the entire function, delimited by lines that match the "funcname" pattern) used to show the entire file when a change added an entire function at the end of the file, which has been fixed. * rs/xdiff-hunk-with-func-line: xdiff: fix merging of appended hunk with -W grep: -W: don't extend context to trailing empty lines t7810: add test for grep -W and trailing empty context lines xdiff: don't trim common tail with -W xdiff: -W: don't include common trailing empty lines in context xdiff: ignore empty lines before added functions with -W xdiff: handle appended chunks better with -W xdiff: factor out match_func_rec() t4051: rewrite, add more tests
2016-06-20Merge branch 'jk/rev-list-count-with-bitmap'Libravatar Junio C Hamano1-0/+6
"git rev-list --count" whose walk-length is limited with "-n" option did not work well with the counting optimized to look at the bitmap index. * jk/rev-list-count-with-bitmap: rev-list: disable bitmaps when "-n" is used with listing objects rev-list: "adjust" results of "--count --use-bitmap-index -n"
2016-06-20Merge branch 'wd/userdiff-css'Libravatar Junio C Hamano13-0/+76
Update the funcname definition to support css files. * wd/userdiff-css: userdiff: add built-in pattern for CSS
2016-06-20Merge branch 'jg/dash-is-last-branch-in-worktree-add'Libravatar Junio C Hamano1-0/+16
"git worktree add" learned that '-' can be used as a short-hand for "@{-1}", the previous branch. * jg/dash-is-last-branch-in-worktree-add: worktree: allow "-" short-hand for @{-1} in add command
2016-06-20Merge branch 'et/pretty-format-c-auto'Libravatar Junio C Hamano1-7/+19
The commands in `git log` family take %C(auto) in a custom format string. This unconditionally turned the color on, ignoring --no-color or with --color=auto when the output is not connected to a tty; this was corrected to make the format truly behave as "auto". * et/pretty-format-c-auto: format_commit_message: honor `color=auto` for `%C(auto)`
2016-06-20Merge branch 'sb/submodule-recommend-shallowness'Libravatar Junio C Hamano1-0/+52
An upstream project can make a recommendation to shallowly clone some submodules in the .gitmodules file it ships. * sb/submodule-recommend-shallowness: submodule update: learn `--[no-]recommend-shallow` option submodule-config: keep shallow recommendation around
2016-06-20Merge branch 'ah/no-verify-signature-with-pull-rebase'Libravatar Junio C Hamano1-0/+16
"git pull --rebase --verify-signature" learned to warn the user that "--verify-signature" is a no-op when rebasing. * ah/no-verify-signature-with-pull-rebase: pull: warn on --verify-signatures with --rebase
2016-06-20Merge branch 'ew/fast-import-unpack-limit'Libravatar Junio C Hamano2-0/+107
"git fast-import" learned the same performance trick to avoid creating too small a packfile as "git fetch" and "git push" have, using *.unpackLimit configuration. * ew/fast-import-unpack-limit: fast-import: invalidate pack_id references after loosening fast-import: implement unpack limit
2016-06-17gpg-interface: check gpg signature creation statusLibravatar Michael J Gruber1-1/+8
When we create a signature, it may happen that gpg returns with "success" but not with an actual detached signature on stdout. Check for the correct signature creation status to catch these cases better. Really, --status-fd parsing is the only way to check gpg status reliably. We do the same for verify already. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-16pretty.c: support <direction>|(<negative number>) formsLibravatar Nguyễn Thái Ngọc Duy1-0/+33
%>|(num), %><|(num) and %<|(num), where num is a positive number, sets a fixed column from the screen's left border. There is no way for us to specifiy a column relative to the right border, which is useful when you want to make use of all terminal space (on big screens). Use negative num for that. Inspired by Go's array syntax (*). (*) I know Python has this first (or before Go, at least) but the idea didn't occur to me until I learned Go. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-16pretty: pass graph width to pretty formatting for use in '%>|(N)'Libravatar Josef Kufner1-0/+24
Pass graph width to pretty formatting, to make N in '%>|(N)' include columns consumed by graph rendered when --graph option is in use. For example, in the output of git log --all --graph --pretty='format: [%>|(20)%h] %ar%d' this change will make all commit hashes align at 20th column from the edge of the terminal, not from the edge of the graph. Signed-off-by: Josef Kufner <josef@kufner.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-14repack: extend --keep-unreachable to loose objectsLibravatar Jeff King1-0/+13
If you use "repack -adk" currently, we will pack all objects that are already packed into the new pack, and then drop the old packs. However, loose unreachable objects will be left as-is. In theory these are meant to expire eventually with "git prune". But if you are using "repack -k", you probably want to keep things forever and therefore do not run "git prune" at all. Meaning those loose objects may build up over time and end up fooling any object-count heuristics (such as the one done by "gc --auto", though since git-gc does not support "repack -k", this really applies to whatever custom scripts people might have driving "repack -k"). With this patch, we instead stuff any loose unreachable objects into the pack along with the already-packed unreachable objects. This may seem wasteful, but it is really no more so than using "repack -k" in the first place. We are at a slight disadvantage, in that we have no useful ordering for the result, or names to hand to the delta code. However, this is again no worse than what "repack -k" is already doing for the packed objects. The packing of these objects doesn't matter much because they should not be accessed frequently (unless they actually _do_ become referenced, but then they would get moved to a different part of the packfile during the next repack). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-14repack: add --keep-unreachable optionLibravatar Jeff King1-0/+15
The usual way to do a full repack (and what is done by git-gc) is to run "repack -Ad --unpack-unreachable=<when>", which will loosen any unreachable objects newer than "<when>", and drop any older ones. This is a safer alternative to "repack -ad", because "<when>" becomes a grace period during which we will not drop any new objects that are about to be referenced. However, it isn't perfectly safe. It's always possible that a process is about to reference an old object. Even if that process were to take care to update the timestamp on the object, there is no atomicity with a simultaneously running "repack" process. So while unlikely, there is a small race wherein we may drop an object that is in the process of being referenced. If you do automated repacking on a large number of active repositories, you may hit it eventually, and the result is a corrupted repository. It would be nice to fix that race in the long run, but it's complicated. In the meantime, there is a much simpler strategy for automated repository maintenance: do not drop objects at all. We already have a "--keep-unreachable" option in pack-objects; we just need to plumb it through from git-repack. Note that this _isn't_ plumbed through from git-gc, so at this point it's strictly a tool for people doing their own advanced repository maintenance strategy. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-13lib-httpd.sh: print error.log on errorLibravatar Nguyễn Thái Ngọc Duy1-0/+1
Failure to bring up httpd for testing is not considered an error, so the trash directory, which contains this error.log file, is removed and we don't know what made httpd fail to start. Improve the situation a bit, print error.log but only in verbose mode. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-13use string_list initializer consistentlyLibravatar Jeff King1-1/+1
There are two types of string_lists: those that own the string memory, and those that don't. You can tell the difference by the strdup_strings flag, and one should use either STRING_LIST_INIT_DUP, or STRING_LIST_INIT_NODUP as an initializer. Historically, the normal all-zeros initialization has corresponded to the NODUP case. Many sites use no initializer at all, and that works as a shorthand for that case. But for a reader of the code, it can be hard to remember which is which. Let's be more explicit and actually have each site declare which type it means to use. This is a fairly mechanical conversion; I assumed each site was correct as-is, and just switched them all to NODUP. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-10Merge branch 'jk/shell-portability'Libravatar Junio C Hamano4-4/+25
test fixes. * jk/shell-portability: t5500 & t7403: lose bash-ism "local" test-lib: add in-shell "env" replacement
2016-06-10Merge branch 'jc/t2300-setup'Libravatar Junio C Hamano1-1/+2
A test fix. * jc/t2300-setup: t2300: run git-sh-setup in an environment that better mimics the real life
2016-06-09xdiff: fix merging of appended hunk with -WLibravatar René Scharfe1-1/+23
When -W is given we search the lines between the end of the current context and the next change for a function line. If there is none then we merge those two hunks as they must be part of the same function. If the next change is an appended chunk we abort the search early in get_func_line(), however, because its line number is out of range. Fix that by searching from the end of the pre-image in that case instead. Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-07add: add --chmod=+x / --chmod=-x optionsLibravatar Edward Thomson1-0/+30
The executable bit will not be detected (and therefore will not be set) for paths in a repository with `core.filemode` set to false, though the users may still wish to add files as executable for compatibility with other users who _do_ have `core.filemode` functionality. For example, Windows users adding shell scripts may wish to add them as executable for compatibility with users on non-Windows. Although this can be done with a plumbing command (`git update-index --add --chmod=+x foo`), teaching the `git-add` command allows users to set a file executable with a command that they're already familiar with. Signed-off-by: Edward Thomson <ethomson@edwardthomson.com> Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-06reflog: continue walking the reflog past root commitsLibravatar SZEDER Gábor2-1/+23
If a repository contains more than one root commit, then its HEAD reflog may contain multiple "creation events", i.e. entries whose "from" value is the null sha1. Listing such a reflog currently stops prematurely at the first such entry, even when the reflog still contains older entries. This can scare users into thinking that their reflog got truncated after 'git checkout --orphan'. Continue walking the reflog past such creation events based on the preceeding reflog entry's "new" value. The test 'symbolic-ref writes reflog entry' in t1401-symbolic-ref implicitly relies on the current behavior of the reflog walker to stop at a root commit and thus to list only the reflog entries that are relevant for that test. Adjust the test to explicitly specify the number of relevant reflog entries to be listed. Reported-by: Patrik Gustafsson <pvn@textalk.se> Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-06am: support --patch-format=mboxrdLibravatar Eric Wong1-0/+20
Combined with "git format-patch --pretty=mboxrd", this should allow us to round-trip commit messages with embedded mbox "From " lines without corruption. Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-06mailsplit: support unescaping mboxrd messagesLibravatar Eric Wong4-0/+59
This will allow us to parse the output of --pretty=mboxrd and the output of other mboxrd generators. Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-06pretty: support "mboxrd" output formatLibravatar Eric Wong1-0/+41
This output format prevents format-patch output from breaking readers if somebody copy+pasted an mbox into a commit message. Unlike the traditional "mboxo" format, "mboxrd" is designed to be fully-reversible. "mboxrd" also gracefully degrades to showing extra ">" in existing "mboxo" readers. This degradation is preferable to breaking message splitting completely, a problem I've seen in "mboxcl" due to having multiple, non-existent, or inaccurate Content-Length headers. "mboxcl2" is a non-starter since it's inherits the problems of "mboxcl" while being completely incompatible with existing tooling based around mailsplit. ref: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/mail-mbox-formats.html Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>