summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2017-01-31Merge branch 'jk/blame-fixes' into maintLibravatar Junio C Hamano1-10/+17
"git blame --porcelain" misidentified the "previous" <commit, path> pair (aka "source") when contents came from two or more files. * jk/blame-fixes: blame: output porcelain "previous" header for each file blame: handle --no-abbrev blame: fix alignment with --abbrev=40
2017-01-31Merge branch 'dt/disable-bitmap-in-auto-gc' into maintLibravatar Junio C Hamano2-1/+17
It is natural that "git gc --auto" may not attempt to pack everything into a single pack, and there is no point in warning when the user has configured the system to use the pack bitmap, leading to disabling further "gc". * dt/disable-bitmap-in-auto-gc: repack: die on incremental + write-bitmap-index auto gc: don't write bitmaps for incremental repacks
2017-01-31Merge branch 'jc/compression-config' into maintLibravatar Junio C Hamano1-14/+0
Compression setting for producing packfiles were spread across three codepaths, one of which did not honor any configuration. Unify these so that all of them honor core.compression and pack.compression variables the same way. * jc/compression-config: compression: unify pack.compression configuration parsing
2017-01-17Merge branch 'jt/fetch-no-redundant-tag-fetch-map' into maintLibravatar Junio C Hamano1-3/+0
Code cleanup to avoid using redundant refspecs while fetching with the --tags option. * jt/fetch-no-redundant-tag-fetch-map: fetch: do not redundantly calculate tag refmap
2017-01-17Merge branch 'jc/push-default-explicit' into maintLibravatar Junio C Hamano1-2/+5
A lazy "git push" without refspec did not internally use a fully specified refspec to perform 'current', 'simple', or 'upstream' push, causing unnecessary "ambiguous ref" errors. * jc/push-default-explicit: push: test pushing ambiguously named branches push: do not use potentially ambiguous default refspec
2017-01-17Merge branch 'jk/index-pack-wo-repo-from-stdin' into maintLibravatar Junio C Hamano1-4/+8
"git index-pack --stdin" needs an access to an existing repository, but "git index-pack file.pack" to generate an .idx file that corresponds to a packfile does not. * jk/index-pack-wo-repo-from-stdin: index-pack: skip collision check when not in repository t: use nongit() function where applicable index-pack: complain when --stdin is used outside of a repo t5000: extract nongit function to test-lib-functions.sh
2017-01-17Merge branch 'sb/sequencer-abort-safety' into maintLibravatar Junio C Hamano1-2/+2
Unlike "git am --abort", "git cherry-pick --abort" moved HEAD back to where cherry-pick started while picking multiple changes, when the cherry-pick stopped to ask for help from the user, and the user did "git reset --hard" to a different commit in order to re-attempt the operation. * sb/sequencer-abort-safety: Revert "sequencer: remove useless get_dir() function" sequencer: remove useless get_dir() function sequencer: make sequencer abort safer t3510: test that cherry-pick --abort does not unsafely change HEAD am: change safe_to_abort()'s not rewinding error into a warning am: fix filename in safe_to_abort() error message
2017-01-17Merge branch 'jc/pull-rebase-ff' into maintLibravatar Junio C Hamano1-4/+18
"git pull --rebase", when there is no new commits on our side since we forked from the upstream, should be able to fast-forward without invoking "git rebase", but it didn't. * jc/pull-rebase-ff: pull: fast-forward "pull --rebase=true"
2017-01-17Merge branch 'ak/commit-only-allow-empty' into maintLibravatar Junio C Hamano1-3/+1
"git commit --allow-empty --only" (no pathspec) with dirty index ought to be an acceptable way to create a new commit that does not change any paths, but it was forbidden, perhaps because nobody needed it so far. * ak/commit-only-allow-empty: commit: remove 'Clever' message for --only --amend commit: make --only --allow-empty work without paths
2017-01-17Merge branch 'nd/worktree-list-fixup' into maintLibravatar Junio C Hamano2-7/+9
The output from "git worktree list" was made in readdir() order, and was unstable. * nd/worktree-list-fixup: worktree list: keep the list sorted worktree.c: get_worktrees() takes a new flag argument get_worktrees() must return main worktree as first item even on error worktree: reorder an if statement worktree.c: zero new 'struct worktree' on allocation
2017-01-17Merge branch 'jk/rev-parse-symbolic-parents-fix' into maintLibravatar Junio C Hamano1-1/+6
"git rev-parse --symbolic" failed with a more recent notation like "HEAD^-1" and "HEAD^!". * jk/rev-parse-symbolic-parents-fix: rev-parse: fix parent shorthands with --symbolic
2017-01-07blame: output porcelain "previous" header for each fileLibravatar Jeff King1-9/+14
It's possible for content currently found in one file to have originated in two separate files, each of which may have been modified in some single older commit. The --porcelain output generates an incorrect "previous" header in this case, whereas --line-porcelain gets it right. The problem is that the porcelain output tries to omit repeated details of commits, and treats "previous" as a property of the commit, when it is really a property of the blamed block of lines. Let's look at an example. In a case like this, you might see this output from --line-porcelain: SOME_SHA1 1 1 1 author ... committer ... previous SOME_SHA1^ file_one filename file_one ...some line content... SOME_SHA1 2 1 1 author ... committer ... previous SOME_SHA1^ file_two filename file_two ...some different content.... The "filename" fields tell us that the two lines are from two different files. But notice that the filename also appears in the "previous" field, which tells us where to start a re-blame. The second content line never appeared in file_one at all, so we would obviously need to re-blame from file_two (or possibly even some other file, if had just been renamed to file_two in SOME_SHA1). So far so good. Now here's what --porcelain looks like: SOME_SHA1 1 1 1 author ... committer ... previous SOME_SHA1^ file_one filename file_one ...some line content... SOME_SHA1 2 1 1 filename file_two ...some different content.... We've dropped the author and committer fields from the second line, as they would just be repeats. But we can't omit "filename", because it depends on the actual block of blamed lines, not just the commit. This is handled by emit_porcelain_details(), which will show the filename either if it is the first mention of the commit _or_ if the commit has multiple paths in it. But we don't give "previous" the same handling. It's written inside emit_one_suspect_detail(), which bails early if we've already seen that commit. And so the output above is wrong; a reader would assume that the correct place to re-blame line two is from file_one, but that's obviously nonsense. Let's treat "previous" the same as "filename", and show it fresh whenever we know we are in a confusing case like this. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-07blame: handle --no-abbrevLibravatar Jeff King1-0/+2
You can already ask blame for full sha1s with "-l" or with "--abbrev=40". But for consistency with other parts of Git, we should support "--no-abbrev". Worse, blame already accepts --no-abbrev, but it's totally broken. When we see --no-abbrev, the abbrev variable is set to 0, which is then used as a printf precision. For regular sha1s, that means we print nothing at all (which is very wrong). For boundary commits we decrement it to "-1", which printf interprets as "no limit" (which is almost correct, except it misses the 39-length magic explained in the previous commit). Let's detect --no-abbrev and behave as if --abbrev=40 was given. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-07blame: fix alignment with --abbrev=40Libravatar Jeff King1-1/+1
The blame command internally adds 1 to any requested sha1 abbreviation length, and then subtracts it when outputting a boundary commit. This lets regular and boundary sha1s line up visually, but it misses one corner case. When the requested length is 40, we bump the value to 41. But since we only have 40 characters, that's all we can show (fortunately the truncation is done by a printf precision field, so it never tries to read past the end of the buffer). So a normal sha1 shows 40 hex characters, and a boundary sha1 shows "^" plus 40 hex characters. The result is misaligned. The "-l" option to show long sha1s gets around this by skipping the "abbrev" variable entirely and just always using GIT_SHA1_HEXSZ. This avoids the "+1" issue, but it does mean that boundary commits only have 39 characters printed. This is somewhat odd, but it does look good visually: the results are aligned and left-justified. The alternative would be to allocate an extra column that would contain either an extra space or the "^" boundary marker. As this is by definition the human-readable view, it's probably not that big a deal either way (and of course --porcelain, etc, correctly produce correct 40-hex sha1s). But for consistency, this patch teaches --abbrev=40 to produce the same output as "-l" (always left-aligned, with 40-hex for normal sha1s, and "^" plus 39-hex for boundaries). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-29repack: die on incremental + write-bitmap-indexLibravatar David Turner1-0/+9
The bitmap index only works for single packs, so requesting an incremental repack with bitmap indexes makes no sense. Signed-off-by: David Turner <dturner@twosigma.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-29auto gc: don't write bitmaps for incremental repacksLibravatar David Turner1-1/+8
When git gc --auto does an incremental repack of loose objects, we do not expect to be able to write a bitmap; it is very likely that objects in the new pack will have references to objects outside of the pack. So we shouldn't try to write a bitmap, because doing so will likely issue a warning. This warning was making its way into gc.log. When the gc.log was present, future auto gc runs would refuse to run. Patch by Jeff King. Bug report, test, and commit message by David Turner. Signed-off-by: David Turner <dturner@twosigma.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-16index-pack: skip collision check when not in repositoryLibravatar Jeff King1-4/+6
You can run "git index-pack path/to/foo.pack" outside of a repository to generate an index file, or just to verify the contents. There's no point in doing a collision check, since we obviously do not have any objects to collide with. The current code will blindly look in .git/objects based on the result of setup_git_env(). That effectively gives us the right answer (since we won't find any objects), but it's a waste of time, and it conflicts with our desire to eventually get rid of the "fallback to .git" behavior of setup_git_env(). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-16index-pack: complain when --stdin is used outside of a repoLibravatar Jeff King1-0/+2
The index-pack builtin is marked as RUN_SETUP_GENTLY, because it's perfectly fine to index a pack in the filesystem outside of any repository. However, --stdin mode will write the result to the object database, which does not make sense outside of a repository. Doing so creates a bogus ".git" directory with nothing in it except the newly-created pack and its index. Instead, let's flag this as an error and abort. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-09commit: remove 'Clever' message for --only --amendLibravatar Andreas Krey1-2/+0
The behavior is now documented; more importantly, rewarding the user with a "Wow, you are clever" praise afterwards is not an effective way to advertise the feature--at that point the user already knows. Signed-off-by: Andreas Krey <a.krey@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-08am: change safe_to_abort()'s not rewinding error into a warningLibravatar Stephan Beyer1-1/+1
The error message tells the user that something went terribly wrong and the --abort could not be performed. But the --abort is performed, only without rewinding. By simply changing the error into a warning, we indicate the user that she must not try something like "git am --abort --force", instead she just has to check the HEAD. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-08am: fix filename in safe_to_abort() error messageLibravatar Stephan Beyer1-1/+1
Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-05commit: make --only --allow-empty work without pathsLibravatar Andreas Krey1-1/+1
--only is implied when paths are present, and required them unless --amend. But with --allow-empty it should be allowed as well - it is the only way to create an empty commit in the presence of staged changes. Signed-off-by: Andreas Krey <a.krey@gmx.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-29pull: fast-forward "pull --rebase=true"Libravatar Junio C Hamano1-4/+18
"git pull --rebase" always runs "git rebase" after fetching the commit to serve as the new base, even when the new base is a descendant of the current HEAD, i.e. we haven't done any work. In such a case, we can instead fast-forward to the new base without invoking the rebase process. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-29Merge branch 'jk/create-branch-remove-unused-param' into maintLibravatar Junio C Hamano2-3/+3
Code clean-up. * jk/create-branch-remove-unused-param: create_branch: drop unused "head" parameter
2016-11-29Merge branch 'rs/commit-pptr-simplify' into maintLibravatar Junio C Hamano1-8/+6
Code simplification. * rs/commit-pptr-simplify: commit: simplify building parents list
2016-11-29Merge branch 'jc/am-read-author-file' into maintLibravatar Junio C Hamano1-58/+45
Extract a small helper out of the function that reads the authors script file "git am" internally uses. This by itself is not useful until a second caller appears in the future for "rebase -i" helper. * jc/am-read-author-file: am: refactor read_author_script()
2016-11-28worktree list: keep the list sortedLibravatar Nguyễn Thái Ngọc Duy1-1/+1
It makes it easier to write tests for. But it should also be good for the user since locating a worktree by eye would be easier once they notice this. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-28worktree.c: get_worktrees() takes a new flag argumentLibravatar Nguyễn Thái Ngọc Duy2-4/+4
This is another no-op patch, in preparation for get_worktrees() to do optional things, like sorting. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-28get_worktrees() must return main worktree as first item even on errorLibravatar Nguyễn Thái Ngọc Duy1-2/+4
This is required by git-worktree.txt, stating that the main worktree is the first line (especially in --porcelain mode when we can't just change behavior at will). There's only one case when get_worktrees() may skip main worktree, when parse_ref() fails. Update the code so that we keep first item as main worktree and return something sensible in this case: - In user-friendly mode, since we're not constraint by anything, returning "(error)" should do the job (we already show "(detached HEAD)" which is not machine-friendly). Actually errors should be printed on stderr by parse_ref() (*) - In plumbing mode, we do not show neither 'bare', 'detached' or 'branch ...', which is possible by the format description if I read it right. Careful readers may realize that when the local variable "head_ref" in get_main_worktree() is emptied, add_head_info() will do nothing to wt->head_sha1. But that's ok because head_sha1 is zero-ized in the previous patch. (*) Well, it does not. But it's supposed to be a stop gap implementation until we can reuse refs code to parse "ref: " stuff in HEAD, from resolve_refs_unsafe(). Now may be the time since refs refactoring is mostly done. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-28worktree: reorder an if statementLibravatar Nguyễn Thái Ngọc Duy1-3/+3
This is no-op. But it helps reduce diff noise in the next patch. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-23Merge branch 'jc/setup-cleanup-fix'Libravatar Junio C Hamano3-8/+19
"git archive" and "git mailinfo" stopped reading from local configuration file with a recent update. * jc/setup-cleanup-fix: archive: read local configuration mailinfo: read local configuration
2016-11-23Merge branch 'js/rebase-i-commentchar-fix'Libravatar Junio C Hamano1-1/+3
"git rebase -i" did not work well with core.commentchar configuration variable for two reasons, both of which have been fixed. * js/rebase-i-commentchar-fix: rebase -i: handle core.commentChar=auto stripspace: respect repository config rebase -i: highlight problems with core.commentchar
2016-11-22archive: read local configurationLibravatar Junio C Hamano2-4/+4
Since b9605bc4f2 ("config: only read .git/config from configured repos", 2016-09-12), we do not read from ".git/config" unless we know we are in a repository. "git archive" however didn't do the repository discovery and instead relied on the old behaviour. Teach the command to run a "gentle" version of repository discovery so that local configuration variables are honoured. [jc: stole tests from peff] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-22mailinfo: read local configurationLibravatar Junio C Hamano1-4/+15
Since b9605bc4f2 ("config: only read .git/config from configured repos", 2016-09-12), we do not read from ".git/config" unless we know we are in a repository. "git mailinfo" however didn't do the repository discovery and instead relied on the old behaviour. This was mostly OK because it was merely run as a helper program by other porcelain scripts that first chdir's up to the root of the working tree. Teach the command to run a "gentle" version of repository discovery so that local configuration variables like mailinfo.scissors are honoured. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-21stripspace: respect repository configLibravatar Johannes Schindelin1-1/+3
The way "git stripspace" reads the configuration was not quite kosher, in that the code forgot to probe for a possibly existing repository (note: stripspace is designed to be usable outside the repository as well). It read .git/config only when it was run from the top-level of the working tree by accident. A recent change b9605bc4f2 ("config: only read .git/config from configured repos", 2016-09-12) stopped reading the repository-local configuration file ".git/config" unless the repository discovery process is done, so that .git/config is never read even when run from the top-level, exposing the old bug more. When rebasing interactively with a commentChar defined in the current repository's config, the help text at the bottom of the edit script potentially used an incorrect comment character. This was not only funny-looking, but also resulted in tons of warnings like this one: Warning: the command isn't recognized in the following line - # Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-17Merge branch 'jk/create-branch-remove-unused-param'Libravatar Junio C Hamano2-3/+3
Code clean-up. * jk/create-branch-remove-unused-param: create_branch: drop unused "head" parameter
2016-11-16rev-parse: fix parent shorthands with --symbolicLibravatar Jeff King1-1/+6
The try_parent_shorthands() function shows each parent via show_rev(). We pass the correct parent sha1, but our "name" parameter still points at the original refname. So asking for a regular rev-parse works fine (it prints the sha1s), but asking for the symbolic name gives nonsense like: $ git rev-parse --symbolic HEAD^-1 HEAD ^HEAD which is always an empty set of commits. Asking for "^!" is likewise broken, with the added bonus that its prints ^HEAD for _each_ parent. And "^@" just prints HEAD repeatedly. Arguably it would be correct to just pass NULL as the name here, and always get the parent expressed as a sha1. The "--symbolic" documentaton claims only "as close to the original input as possible", and we certainly fallback to sha1s where necessary. But it's pretty easy to generate a symbolic name on the fly from the original. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-15compression: unify pack.compression configuration parsingLibravatar Junio C Hamano1-14/+0
There are three codepaths that use a variable whose name is pack_compression_level to affect how objects and deltas sent to a packfile is compressed. Unlike zlib_compression_level that controls the loose object compression, however, this variable was static to each of these codepaths. Two of them read the pack.compression configuration variable, using core.compression as the default, and one of them also allowed overriding it from the command line. The other codepath in bulk-checkin did not pay any attention to the configuration. Unify the configuration parsing to git_default_config(), where we implement the parsing of core.loosecompression and core.compression and make the former override the latter, by moving code to parse pack.compression and also allow core.compression to give default to this variable. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-11fetch: do not redundantly calculate tag refmapLibravatar Jonathan Tan1-3/+0
builtin/fetch.c redundantly calculates refmaps for tags twice. Remove the first calculation. This is only a code simplification and slight performance improvement - the result is unchanged, as the redundant refmaps are subsequently removed by the invocation to "ref_remove_duplicates" anyway. This was introduced in commit c5a84e9 ("fetch --tags: fetch tags *in addition to* other stuff", 2013-10-29) when modifying the effect of the --tags parameter to "git fetch". The refmap-for-tag calculation was copied instead of moved. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-09create_branch: drop unused "head" parameterLibravatar Jeff King2-3/+3
This function used to have the caller pass in the current value of HEAD, in order to make sure we didn't clobber HEAD. In 55c4a6730, that logic moved to validate_new_branchname(), which just resolves HEAD itself. The parameter to create_branch is now unused. Since we have to update and re-wrap the docstring describing the parameters anyway, let's take this opportunity to break it out into a list, which makes it easier to find the parameters. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-31Merge branch 'rs/commit-pptr-simplify'Libravatar Junio C Hamano1-8/+6
Code simplification. * rs/commit-pptr-simplify: commit: simplify building parents list
2016-10-31Merge branch 'ls/filter-process'Libravatar Junio C Hamano4-8/+8
The smudge/clean filter API expect an external process is spawned to filter the contents for each path that has a filter defined. A new type of "process" filter API has been added to allow the first request to run the filter for a path to spawn a single process, and all filtering need is served by this single process for multiple paths, reducing the process creation overhead. * ls/filter-process: contrib/long-running-filter: add long running filter example convert: add filter.<driver>.process option convert: prepare filter.<driver>.process option convert: make apply_filter() adhere to standard Git error handling pkt-line: add functions to read/write flush terminated packet streams pkt-line: add packet_write_gently() pkt-line: add packet_flush_gently() pkt-line: add packet_write_fmt_gently() pkt-line: extract set_packet_header() pkt-line: rename packet_write() to packet_write_fmt() run-command: add clean_on_exit_handler run-command: move check_pipe() from write_or_die to run_command convert: modernize tests convert: quote filter names in error messages
2016-10-31Merge branch 'ls/git-open-cloexec'Libravatar Junio C Hamano1-1/+1
Git generally does not explicitly close file descriptors that were open in the parent process when spawning a child process, but most of the time the child does not want to access them. As Windows does not allow removing or renaming a file that has a file descriptor open, a slow-to-exit child can even break the parent process by holding onto them. Use O_CLOEXEC flag to open files in various codepaths. * ls/git-open-cloexec: read-cache: make sure file handles are not inherited by child processes sha1_file: open window into packfiles with O_CLOEXEC sha1_file: rename git_open_noatime() to git_open()
2016-10-30commit: simplify building parents listLibravatar René Scharfe1-8/+6
Push pptr down into the FROM_MERGE branch of the if/else statement, where it's actually used, and call commit_list_append() for appending elements instead of playing tricks with commit_list_insert(). Call copy_commit_list() in the amend branch instead of open-coding it. Don't bother setting pptr in the final branch as it's not used thereafter. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-28push: do not use potentially ambiguous default refspecLibravatar Junio C Hamano1-2/+5
When the user does the lazy "git push" with no parameters with push.default set to either "upstream", "simple" or "current", we internally generated a refspec that has the current branch name on the source side and used it to push. However, the branch name (say "test") may be an ambiguous refname in the context of the source repository---there may be a tag with the same name, for example. This would trigger an unnecessary error without any fault on the end-user's side. Be explicit and give a full refname as the source side to avoid the ambiguity. The destination side when pushing with the "current" sent only the name of the branch and forcing the receiving end to guess, which is the same issue. Be explicit there as well. Reported-by: Kannan Goundan <kannan@cakoose.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-28Merge branch 'rs/cocci' into maintLibravatar Junio C Hamano3-5/+6
Code cleanup. * rs/cocci: use strbuf_add_unique_abbrev() for adding short hashes, part 3 remove unnecessary NULL check before free(3) coccicheck: make transformation for strbuf_addf(sb, "...") more precise use strbuf_add_unique_abbrev() for adding short hashes, part 2 use strbuf_addstr() instead of strbuf_addf() with "%s", part 2 gitignore: ignore output files of coccicheck make target use strbuf_addstr() for adding constant strings to a strbuf, part 2 add coccicheck make target contrib/coccinelle: fix semantic patch for oid_to_hex_r()
2016-10-28Merge branch 'js/reset-usage' into maintLibravatar Junio C Hamano1-1/+1
Message fix-up. * js/reset-usage: reset: fix usage
2016-10-28Merge branch 'jk/fetch-quick-tag-following' into maintLibravatar Junio C Hamano1-4/+7
When fetching from a remote that has many tags that are irrelevant to branches we are following, we used to waste way too many cycles when checking if the object pointed at by a tag (that we are not going to fetch!) exists in our repository too carefully. * jk/fetch-quick-tag-following: fetch: use "quick" has_sha1_file for tag following
2016-10-28Merge branch 'jk/merge-base-fork-point-without-reflog' into maintLibravatar Junio C Hamano1-0/+3
"git rebase" immediately after "git clone" failed to find the fork point from the upstream. * jk/merge-base-fork-point-without-reflog: merge-base: handle --fork-point without reflog
2016-10-28Merge branch 'jk/clone-copy-alternates-fix' into maintLibravatar Junio C Hamano1-2/+5
"git clone" of a local repository can be done at the filesystem level, but the codepath did not check errors while copying and adjusting the file that lists alternate object stores. * jk/clone-copy-alternates-fix: clone: detect errors in normalize_path_copy