summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2016-09-08Merge branch 'jk/tighten-alloc' into maintLibravatar Junio C Hamano1-3/+1
Small code and comment clean-up. * jk/tighten-alloc: receive-pack: use FLEX_ALLOC_MEM in queue_command() correct FLEXPTR_* example in comment
2016-09-08Merge branch 'rs/use-strbuf-add-unique-abbrev' into maintLibravatar Junio C Hamano1-2/+1
A small code clean-up. * rs/use-strbuf-add-unique-abbrev: use strbuf_add_unique_abbrev() for adding short hashes
2016-09-08Merge branch 'rs/merge-add-strategies-simplification' into maintLibravatar Junio C Hamano1-34/+10
A small code clean-up. * rs/merge-add-strategies-simplification: merge: use string_list_split() in add_strategies()
2016-09-08Merge branch 'js/no-html-bypass-on-windows' into maintLibravatar Junio C Hamano1-7/+0
On Windows, help.browser configuration variable used to be ignored, which has been corrected. * js/no-html-bypass-on-windows: Revert "display HTML in default browser using Windows' shell API"
2016-09-08Merge branch 'sb/checkout-explit-detach-no-advice' into maintLibravatar Junio C Hamano1-1/+2
"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 'js/mv-dir-to-new-directory' into maintLibravatar Junio C Hamano1-4/+7
"git mv dir non-existing-dir/" did not work in some environments the same way as existing mainstream platforms. The code now moves "dir" to "non-existing-dir", without relying on rename("A", "B/") that strips the trailing slash of '/'. * js/mv-dir-to-new-directory: git mv: do not keep slash in `git mv dir non-existing-dir/`
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-08-19Revert "display HTML in default browser using Windows' shell API"Libravatar Johannes Schindelin1-7/+0
Since 4804aab (help (Windows): Display HTML in default browser using Windows' shell API, 2008-07-13), Git for Windows used to call `ShellExecute()` to launch the default Windows handler for `.html` files. The idea was to avoid going through a shell script, for performance reasons. However, this change ignores the `help.browser` config setting. Together with browsing help not being a performance-critical operation, let's just revert that patch. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-15checkout: do not mention detach advice for explicit --detach optionLibravatar Stefan Beller1-1/+2
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-13receive-pack: use FLEX_ALLOC_MEM in queue_command()Libravatar René Scharfe1-3/+1
Use the macro FLEX_ALLOC_MEM instead of open-coding it. This shortens and simplifies the code a bit. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-12Merge branch 'jk/reset-ident-time-per-commit' into maintLibravatar Junio C Hamano1-0/+2
Not-so-recent rewrite of "git am" that started making internal calls into the commit machinery had an unintended regression, in that no matter how many seconds it took to apply many patches, the resulting committer timestamp for the resulting commits were all the same. * jk/reset-ident-time-per-commit: am: reset cached ident date for each patch
2016-08-10Merge branch 'rs/use-strbuf-addstr' into maintLibravatar Junio C Hamano2-2/+2
* 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 'os/no-verify-skips-commit-msg-too' into maintLibravatar Junio C Hamano1-1/+1
"git commit --help" said "--no-verify" is only about skipping the pre-commit hook, and failed to say that it also skipped the commit-msg hook. * os/no-verify-skips-commit-msg-too: commit: describe that --no-verify skips the commit-msg hook in the help text
2016-08-10Merge branch 'rs/rm-strbuf-optim' into maintLibravatar Junio C Hamano1-2/+3
The use of strbuf in "git rm" to build filename to remove was a bit suboptimal, which has been fixed. * rs/rm-strbuf-optim: rm: reuse strbuf for all remove_dir_recursively() calls
2016-08-10Merge branch 'jk/parse-options-concat' into maintLibravatar Junio C Hamano1-9/+4
Users of the parse_options_concat() API function need to allocate extra slots in advance and fill them with OPT_END() when they want to decide the set of supported options dynamically, which makes the code error-prone and hard to read. This has been corrected by tweaking the API to allocate and return a new copy of "struct option" array. * jk/parse-options-concat: parse_options: allocate a new array when concatenating
2016-08-08Merge branch 'pb/commit-editmsg-path' into maintLibravatar Junio C Hamano1-7/+8
Code clean-up. * pb/commit-editmsg-path: builtin/commit.c: memoize git-path for COMMIT_EDITMSG
2016-08-08Merge branch 'nd/pack-ofs-4gb-limit' into maintLibravatar Junio C Hamano4-21/+27
"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 'mh/blame-worktree' into maintLibravatar Junio C Hamano1-1/+9
"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-08git mv: do not keep slash in `git mv dir non-existing-dir/`Libravatar Johannes Schindelin1-4/+7
When calling `rename("dir", "non-existing-dir/")` on Linux, it silently succeeds, stripping the trailing slash of the second argument. This is all good and dandy but this behavior disagrees with the specs at http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html that state clearly regarding the 2nd parameter (called `new`): If the `new` argument does not resolve to an existing directory entry for a file of type directory and the `new` argument contains at least one non- <slash> character and ends with one or more trailing <slash> characters after all symbolic links have been processed, `rename()` shall fail. Of course, we would like `git mv dir non-existing-dir/` to succeed (and rename the directory "dir" to "non-existing-dir"). Let's be extra careful to remove the trailing slash in that case. This lets t7001-mv.sh pass in Bash on Windows. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-06use strbuf_add_unique_abbrev() for adding short hashesLibravatar René Scharfe1-2/+1
Call strbuf_add_unique_abbrev() to add abbreviated hashes to strbufs instead of taking detours through find_unique_abbrev() and its static buffer. This is shorter and a bit more efficient. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-05merge: use string_list_split() in add_strategies()Libravatar René Scharfe1-34/+10
Call string_list_split() for cutting a space separated list into pieces instead of reimplementing it based on struct strategy. The attr member of struct strategy was not used split_merge_strategies(); it was a pure string operation. Also be nice and clean up once we're done splitting; the old code didn't bother freeing any of the allocated memory. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-05use strbuf_addstr() instead of strbuf_addf() with "%s"Libravatar René Scharfe1-1/+1
Call strbuf_addstr() for adding a simple string to a strbuf instead of using the heavier strbuf_addf(). This is shorter and documents the intent more clearly. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-01am: reset cached ident date for each patchLibravatar Jeff King1-0/+2
When we compute the date to go in author/committer lines of commits, or tagger lines of tags, we get the current date once and then cache it for the rest of the program. This is a good thing in some cases, like "git commit", because it means we do not racily assign different times to the author/committer fields of a single commit object. But as more programs start to make many commits in a single process (e.g., the recently builtin "git am"), it means that you'll get long strings of commits with identical committer timestamps (whereas before, we invoked "git commit" many times and got true timestamps). This patch addresses it by letting callers reset the cached time, which means they'll get a fresh time on their next call to git_committer_info() or git_author_info(). The first caller to do so is "git am", which resets the time for each patch it applies. It would be nice if we could just do this automatically before filling in the ident fields of commit and tag objects. Unfortunately, it's hard to know where a particular logical operation begins and ends. For instance, if commit_tree_extended() were to call reset_ident_date() before getting the committer/author ident, that doesn't quite work; sometimes the author info is passed in to us as a parameter, and it may or may not have come from a previous call to ident_default_date(). So in those cases, we lose the property that the committer and the author timestamp always match. You could similarly put a date-reset at the end of commit_tree_extended(). That actually works in the current code base, but it's fragile. It makes the assumption that after commit_tree_extended() finishes, the caller has no other operations that would logically want to fall into the same timestamp. So instead we provide the tool to easily do the reset, and let the high-level callers use it to annotate their own logical operations. There's no automated test, because it would be inherently racy (it depends on whether the program takes multiple seconds to run). But you can see the effect with something like: # make a fake 100-patch series top=$(git rev-parse HEAD) bottom=$(git rev-list --first-parent -100 HEAD | tail -n 1) git log --format=email --reverse --first-parent \ --binary -m -p $bottom..$top >patch # now apply it; this presumably takes multiple seconds git checkout --detach $bottom git am <patch # now count the number of distinct committer times; # prior to this patch, there would only be one, but # now we'd typically see several. git log --format=%ct $bottom.. | sort -u Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Helped-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-01use strbuf_addstr() for adding constant strings to a strbufLibravatar René Scharfe1-1/+1
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-28Merge branch 'dk/blame-move-no-reason-for-1-line-context' into maintLibravatar Junio C Hamano1-4/+3
"git blame -M" missed a single line that was moved within the file. * dk/blame-move-no-reason-for-1-line-context: blame: require 0 context lines while finding moved lines with -M
2016-07-28Merge branch 'js/am-call-theirs-theirs-in-fallback-3way' into maintLibravatar Junio C Hamano1-8/+8
One part of "git am" had an oddball helper function that called stuff from outside "his" as opposed to calling what we have "ours", which was not gender-neutral and also inconsistent with the rest of the system where outside stuff is usuall called "theirs" in contrast to "ours". * js/am-call-theirs-theirs-in-fallback-3way: am: counteract gender bias
2016-07-28Merge branch 'ew/gc-auto-pack-limit-fix' into maintLibravatar Junio C Hamano1-1/+1
"gc.autoPackLimit" when set to 1 should not trigger a repacking when there is only one pack, but the code counted poorly and did so. * ew/gc-auto-pack-limit-fix: gc: fix off-by-one error with gc.autoPackLimit
2016-07-28Merge branch 'nd/ita-cleanup' into maintLibravatar Junio C Hamano1-2/+2
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 Hamano2-2/+2
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-27date: add "unix" formatLibravatar Jeff King1-0/+3
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-26commit: describe that --no-verify skips the commit-msg hook in the help textLibravatar Orgad Shaneh1-1/+1
This brings the short help in line with the documentation. Signed-off-by: Orgad Shaneh <orgads@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-18blame: allow to blame paths freshly added to the indexLibravatar Mike Hommey1-1/+9
When blaming files, changes in the work tree are taken into account and displayed as being "Not Committed Yet". However, when blaming a file that is not known to the current HEAD, git blame fails with `no such path 'foo' in HEAD`, even when the file was git add'ed. Allowing such a blame is useful when the new file added to the index (not yet committed) was created by renaming an existing file. It also is useful when the new file was created from pieces already in HEAD, moved or copied from other files and blaming with copy detection (i.e. "-C"). Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-13fsck: use streaming interface for large blobs in packLibravatar Nguyễn Thái Ngọc Duy1-0/+4
For blobs, we want to make sure the on-disk data is not corrupted (i.e. can be inflated and produce the expected SHA-1). Blob content is opaque, there's nothing else inside to check for. For really large blobs, we may want to avoid unpacking the entire blob in memory, just to check whether it produces the same SHA-1. On 32-bit systems, we may not have enough virtual address space for such memory allocation. And even on 64-bit where it's not a problem, allocating a lot more memory could result in kicking other parts of systems to swap file, generating lots of I/O and slowing everything down. For this particular operation, not unpacking the blob and letting check_sha1_signature, which supports streaming interface, do the job is sufficient. check_sha1_signature() is not shown in the diff, unfortunately. But if will be called when "data_valid && !data" is false. We will call the callback function "fn" with NULL as "data". The only callback of this function is fsck_obj_buffer(), which does not touch "data" at all if it's a blob. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-13pack-objects: do not truncate result in-pack object size on 32-bit systemsLibravatar Nguyễn Thái Ngọc Duy1-7/+8
A typical diff will not show what's going on and you need to see full functions. The core code is like this, at the end of of write_one() e->idx.offset = *offset; size = write_object(f, e, *offset); if (!size) { e->idx.offset = recursing; return WRITE_ONE_BREAK; } written_list[nr_written++] = &e->idx; /* make sure off_t is sufficiently large not to wrap */ if (signed_add_overflows(*offset, size)) die("pack too large for current definition of off_t"); *offset += size; Here we can see that the in-pack object size is returned by write_object (or indirectly by write_reuse_object). And it's used to calculate object offsets, which end up in the pack index file, generated at the end. If "size" overflows (on 32-bit sytems, unsigned long is 32-bit while off_t can be 64-bit), we got wrong offsets and produce incorrect .idx file, which may make it look like the .pack file is corrupted. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-13index-pack: correct "offset" type in unpack_entry_data()Libravatar Nguyễn Thái Ngọc Duy1-1/+1
unpack_entry_data() receives an off_t value from unpack_raw_entry(), which could be larger than unsigned long on 32-bit systems with large file support. Correct the type so truncation does not happen. This only affects bad object reporting though. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-13index-pack: report correct bad object offsets even if they are largeLibravatar Nguyễn Thái Ngọc Duy1-3/+4
Use the right type for offsets in this case, off_t, which makes a difference on 32-bit systems with large file support, and change formatting code accordingly. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-13index-pack: correct "len" type in unpack_data()Libravatar Nguyễn Thái Ngọc Duy1-7/+7
On 32-bit systems with large file support, one entry could be larger than 4GB and overflow "len". Correct it so we can unpack a full entry. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-13sha1_file.c: use type off_t* for object_info->disk_sizepLibravatar Nguyễn Thái Ngọc Duy1-2/+2
This field, filled by sha1_object_info() contains the on-disk size of an object, which could go over 4GB limit of unsigned long on 32-bit systems. Use off_t for it instead and update all callers. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-12rm: reuse strbuf for all remove_dir_recursively() callsLibravatar René Scharfe1-2/+3
Don't throw the memory allocated for remove_dir_recursively() away after a single call, use it for the other entries as well instead. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-12pack-objects: pass length to check_pack_crc() without truncationLibravatar Nguyễn Thái Ngọc Duy1-1/+1
On 32 bit systems with large file support, unsigned long is 32-bit while the two offsets in the subtraction expression (pack-objects has the exact same expression as in sha1_file.c but not shown in diff) are in 64-bit. If an in-pack object is larger than 2^32 len/datalen is truncated and we get a misleading "error: bad packed object CRC for ..." as a result. Use off_t for len and datalen. check_pack_crc() already accepts this argument as off_t and can deal with 4+ GB. Noticed-by: Christoph Michelbach <michelbach94@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-11Merge branch 'sb/clone-shallow-passthru' into maintLibravatar Junio C Hamano1-3/+2
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-11Merge branch 'km/fetch-do-not-free-remote-name' into maintLibravatar Junio C Hamano1-4/+2
The ownership rule for the piece of memory that hold references to be fetched in "git fetch" was screwy, which has been cleaned up. * km/fetch-do-not-free-remote-name: builtin/fetch.c: don't free remote->name after fetch
2016-07-08am: counteract gender biasLibravatar Johannes Schindelin1-8/+8
Since 47f0b6d5 (Fall back to three-way merge when applying a patch., 2005-10-06), i.e. for almost 11 years already, we used a male form to describe "the other tree". While it was unintended, this gave the erroneous impression as if the Git developers thought of users as male, and were unaware of the important role in software development played by female actors such as Ada Lovelace, Grace Hopper and Margaret Hamilton. In fact, the first professional software developers were all female. Let's change those unfortunate references to the gender neutral "their tree". Doing so also makes the fallback_merge_recursive(), which is an oddball, more in line with the other parts of the system where we contrast what we have vs what we obtain from others by saying "ours" vs "theirs". This inconsistency was also unintended. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-06Merge branch 'jc/deref-tag' into maintLibravatar Junio C Hamano1-4/+2
Code clean-up. * jc/deref-tag: blame, line-log: do not loop around deref_tag()
2016-07-06Merge branch 'et/add-chmod-x' into maintLibravatar Junio C Hamano3-11/+26
"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-07-06parse_options: allocate a new array when concatenatingLibravatar Jeff King1-9/+4
In exactly one callers (builtin/revert.c), we build up the options list dynamically from multiple arrays. We do so by manually inserting "filler" entries into one array, and then copying the other array into the allocated space. This is tedious and error-prone, as you have to adjust the filler any time the second array is modified (although we do at least check and die() when the counts do not match up). Instead, let's just allocate a new array. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-01grep: fix grepping for "intent to add" filesLibravatar Charles Bailey1-2/+2
This reverts commit 4d5520053 (grep: make it clear i-t-a entries are ignored, 2015-12-27) and adds an alternative fix to maintain the -L --cached behavior. 4d5520053 caused 'git grep' to no longer find matches in new files in the working tree where the corresponding index entry had the "intent to add" bit set, despite the fact that these files are tracked. The content in the index of a file for which the "intent to add" bit is set is considered indeterminate and not empty. For most grep queries we want these to behave the same, however for -L --cached (files without a match) we don't want to respond positively for "intent to add" files as their contents are indeterminate. This is in contrast to files with empty contents in the index (no lines implies no matches for any grep query expression) which should be reported in the output of a grep -L --cached invocation. Add tests to cover this case and a few related cases which previously lacked coverage. Helped-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Charles Bailey <cbailey32@bloomberg.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-29reset --hard: skip blank lines when reporting the commit subjectLibravatar Johannes Schindelin1-1/+1
When there are blank lines at the beginning of a commit message, the pretty printing machinery already skips them when showing a commit subject (or the complete commit message). We shall henceforth do the same when reporting the commit subject after the user called git reset --hard <commit> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-29commit -C: skip blank lines at the beginning of the messageLibravatar Johannes Schindelin1-1/+1
Consistent with the pretty-printing machinery, we skip leading blank lines (if any) of existing commit messages. While Git itself only produces commit objects with a single empty line between commit header and commit message, it is legal to have more than one blank line (i.e. lines containing only white space, or no characters) at the beginning of the commit message, and the pretty-printing code already handles that. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-27Merge branch 'jk/rev-list-count-with-bitmap' into maintLibravatar Junio C Hamano1-1/+5
"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"