summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-09-25init: call set_git_dir_init() from within init_db()Libravatar Nguyễn Thái Ngọc Duy3-17/+21
The next commit requires that set_git_dir_init() must be called before init_db(). Let's make sure nobody can do otherwise. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-25init: correct re-initialization from a linked worktreeLibravatar Nguyễn Thái Ngọc Duy2-1/+16
When 'git init' is called from a linked worktree, we treat '.git' dir (which is $GIT_COMMON_DIR/worktrees/something) as the main '.git' (i.e. $GIT_COMMON_DIR) and populate the whole repository skeleton in there. It does not harm anything (*) but it is still wrong. Since 'git init' calls set_git_dir() at preparation time, which indirectly calls get_common_dir() and correctly detects multiple worktree setup, all git_path_buf() calls in create_default_files() will return correct paths in both single and multiple worktree setups. The only thing left is copy_templates(), which targets $GIT_DIR, not $GIT_COMMON_DIR. Fix that with get_git_common_dir(). This function will return $GIT_DIR in single-worktree setup, so we don't have to make a special case for multiple-worktree here. (*) It does in fact, thanks to another bug. More on that later. Noticed-by: Max Nordlund <max.nordlund@sqore.com> Helped-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-13t1007: factor out repeated setupLibravatar Jeff King1-24/+8
We have a series of 3 CRLF tests that do exactly the same (long) setup sequence. Let's pull it out into a common setup test, which is shorter, more efficient, and will make it easier to add new tests. Note that we don't have to worry about cleaning up any of the setup which was previously per-test; we call pop_repo after the CRLF tests, which cleans up everything. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-13init: reset cached config when entering new repoLibravatar Jeff King4-0/+50
After we copy the templates into place, we re-read the config in case we copied in a default config file. But since git_config() is backed by a cache these days, it's possible that the call will not actually touch the filesystem at all; we need to tell it that something has changed behind the scenes. Note that we also need to reset the shared_repository config. At first glance, it seems like this should probably just be folded into git_config_clear(). But unfortunately that is not quite right. The shared repository value may come from config, _or_ it may have been set manually. So only the caller who knows whether or not they set it is the one who can clear it (and indeed, if you _do_ put it into git_config_clear(), then many tests fail, as we have to clear the config cache any time we set a new config variable). There are three tests here. The first two actually pass already, though it's largely luck: they just don't happen to actually read any config before we enter the new repo. But the third one does fail without this patch; we look at core.sharedrepository while creating the directory, but need to make sure the value from the template config overrides it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-13init: expand comments explaining config trickeryLibravatar Jeff King1-4/+7
git-init may copy "config" from the templates directory and then re-read it. There are some comments explaining what's going on here, but they are not grouped very well with the matching code. Let's rearrange and expand them. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-13config: only read .git/config from configured reposLibravatar Jeff King6-4/+33
When git_config() runs, it looks in the system, user-wide, and repo-level config files. It gets the latter by calling git_pathdup(), which in turn calls get_git_dir(). If we haven't set up the git repository yet, this may simply return ".git", and we will look at ".git/config". This seems like it would be helpful (presumably we haven't set up the repository yet, so it tries to find it), but it turns out to be a bad idea for a few reasons: - it's not sufficient, and therefore hides bugs in a confusing way. Config will be respected if commands are run from the top-level of the working tree, but not from a subdirectory. - it's not always true that we haven't set up the repository _yet_; we may not want to do it at all. For instance, if you run "git init /some/path" from inside another repository, it should not load config from the existing repository. - there might be a path ".git/config", but it is not the actual repository we would find via setup_git_directory(). This may happen, e.g., if you are storing a git repository inside another git repository, but have munged one of the files in such a way that the inner repository is not valid (e.g., by removing HEAD). We have at least two bugs of the second type in git-init, introduced by ae5f677 (lazily load core.sharedrepository, 2016-03-11). It causes init to use git_configset(), which loads all of the config, including values from the current repo (if any). This shows up in two ways: 1. If we happen to be in an existing repository directory, we'll read and respect core.sharedrepository from it, even though it should have no bearing on the new repository. A new test in t1301 covers this. 2. Similarly, if we're in an existing repo that sets core.logallrefupdates, that will cause init to fail to set it in a newly created repository (because it thinks that the user's templates already did so). A new test in t0001 covers this. We also need to adjust an existing test in t1302, which gives another example of why this patch is an improvement. That test creates an embedded repository with a bogus core.repositoryformatversion of "99". It wants to make sure that we actually stop at the bogus repo rather than continuing upward to find the outer repo. So it checks that "git config core.repositoryformatversion" returns 99. But that only works because we blindly read ".git/config", even though we _know_ we're in a repository whose vintage we do not understand. After this patch, we avoid reading config from the unknown vintage repository at all, which is a safer choice. But we need to tweak the test, since core.repositoryformatversion will not return 99; it will claim that it could not find the variable at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-13test-config: setup git directoryLibravatar Jeff King1-0/+3
The t1308 test script uses our test-config helper to read repository-level config, but never actually sets up the repository. This works because git_config() blindly reads ".git/config" even if we have not configured a repository. This means that test-config won't work from a subdirectory, though since it's just a helper for the test scripts, that's not a big deal. More important is that the behavior of git_config() is going to change, and we want to make sure that t1308 continues to work. We can just use setup_git_directory(), and not the gentle form; there's no point in being flexible, as it's just a helper for the tests. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-13t1302: use "git -C"Libravatar Jeff King1-24/+6
This is shorter, and saves a subshell. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-13pager: handle early configLibravatar Jeff King1-2/+33
The pager code is often run early in the git.c startup, before we have actually found the repository. When we ask git_config() to look for values like core.pager, it doesn't know where to find the repo-level config, and will blindly examine ".git/config" if it exists. That's why t7006 shows that many pager-related features happen to work from the top-level of a repository, but not from a subdirectory. This patch pulls that ".git/config" hack explicitly into the pager code. There are two reasons for this: 1. We'd like to clean up the git_config() behavior, as looking at ".git/config" when we do not have a configured repository is often the wrong thing to do. But we'd prefer not to break the pager config any worse than it already is. 2. It's one very tiny step on the road to ultimately making the pager config work consistently. If we eventually get an equivalent of setup_git_directory() that _just_ finds the directory and doesn't chdir() or set up any global state, we could plug it in here (instead of blindly looking at ".git/config"). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-13pager: use callbacks instead of configsetLibravatar Jeff King1-14/+33
While the cached configset interface is more pleasant to use, it is not appropriate for "early" config like pager setup, which must sometimes do tricky things like reading from ".git/config" even when we have not set up the repository. As a preparatory step to handling these cases better, let's switch back to using the callback interface, which gives us more control. Note that this is essentially a revert of 586f414 (pager.c: replace `git_config()` with `git_config_get_value()`, 2014-08-07), but with some minor style fixups and modernizations. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-13pager: make pager_program a file-local staticLibravatar Jeff King3-2/+1
This variable is only ever used by the routines in pager.c, and other parts of the code should always use those routines (like git_pager()) to make decisions about which pager to use. Let's reduce its scope to prevent accidents. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-13pager: stop loading git_default_config()Libravatar Jeff King2-4/+8
In git_pager(), we really only care about getting the value of core.pager. But to do so, we use the git_default_config() callback, which loads many other values. Ordinarily it isn't a big deal to load this config an extra time, as it simply overwrites the values from the previous run. But it's a bad idea here, for two reasons: 1. The pager setup may be called very early in the program, before we have found the git repository. As a result, we may fail to read the correct repo-level config file. This is a problem for core.pager, too, but we should at least try to minimize the pollution to other configured values. 2. Because we call setup_pager() from git.c, basically every builtin command _may_ end up reading this config and getting an implicit git_default_config() setup. Which doesn't sound like a terrible thing, except that we don't do it consistently; it triggers only when stdout is a tty. So if a command forgets to load the default config itself (but depends on it anyway), it may appear to work, and then mysteriously fail when the pager is not in use. We can improve this by loading _just_ the core.pager config from git_pager(). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-13pager: remove obsolete commentLibravatar Jeff King1-5/+0
The comment at the top of pager.c claims that we've split the code out so that Windows can do something different. This dates back to f67b45f (Introduce trivial new pager.c helper infrastructure, 2006-02-28), because the original implementation used fork(). Later, we ended up sticking the Windows #ifdefs into this file anyway. And then even later, in ea27a18 (spawn pager via run_command interface, 2008-07-22) we unified the implementations. So these days this comment is really saying nothing at all. Let's drop it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-13diff: always try to set up the repositoryLibravatar Jeff King2-2/+22
If we see an explicit "--no-index", we do not bother calling setup_git_directory_gently() at all. This means that we may miss out on reading repo-specific config. It's arguable whether this is correct or not. If we were designing from scratch, making "git diff --no-index" completely ignore the repository makes some sense. But we are nowhere near scratch, so let's look at the existing behavior: 1. If you're in the top-level of a repository and run an explicit "diff --no-index", the config subsystem falls back to reading ".git/config", and we will respect repo config. 2. If you're in a subdirectory of a repository, then we still try to read ".git/config", but it generally doesn't exist. So "diff --no-index" there does not respect repo config. 3. If you have $GIT_DIR set in the environment, we read and respect $GIT_DIR/config, 4. If you run "git diff /tmp/foo /tmp/bar" to get an implicit no-index, we _do_ run the repository setup, and set $GIT_DIR (or respect an existing $GIT_DIR variable). We find the repo config no matter where we started, and respect it. So we already respect the repository config in a number of common cases, and case (2) is the only one that does not. And at least one of our tests, t4034, depends on case (1) behaving as it does now (though it is just incidental, not an explicit test for this behavior). So let's bring case (2) in line with the others by always running the repository setup, even with an explicit "--no-index". We shouldn't need to change anything else, as the implicit case already handles the prefix. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-13diff: handle --no-index prefixes consistentlyLibravatar Jeff King2-0/+21
If we see an explicit "git diff --no-index ../foo ../bar", then we do not set up the git repository at all (we already know we are in --no-index mode, so do not have to check "are we in a repository?"), and hence have no "prefix" within the repository. A patch generated by this command will have the filenames "a/../foo" and "b/../bar", no matter which directory we are in with respect to any repository. However, in the implicit case, where we notice that the files are outside the repository, we will have chdir()'d to the top-level of the repository. We then feed the prefix back to the diff machinery. As a result, running the same diff from a subdirectory will result in paths that look like "a/subdir/../../foo". Besides being unnecessarily long, this may also be confusing to the user: they don't care about the subdir or the repository at all; it's just where they happened to be when running the command. We should treat this the same as the explicit --no-index case. One way to address this would be to chdir() back to the original path before running our diff. However, that's a bit hacky, as we would also need to adjust $GIT_DIR, which could be a relative path from our top-level. Instead, we can reuse the diff machinery's RELATIVE_NAME option, which automatically strips off the prefix. Note that this _also_ restricts the diff to this relative prefix, but that's OK for our purposes: we queue our own diff pairs manually, and do not rely on that part of the diff code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-13diff: skip implicit no-index check when given --no-indexLibravatar Jeff King1-12/+13
We can invoke no-index mode in two ways: by an explicit request from the user, or implicitly by noticing that we have two paths, and at least one is outside the repository. If the user already told us --no-index, there is no need for us to do the implicit test at all. However, we currently do, and downgrade our "explicit" to DIFF_NO_INDEX_IMPLICIT. This doesn't have any user-visible behavior, though it's not immediately obvious why. We only trigger the implicit check when we have exactly two non-option arguments. And the only code that cares about implicit versus explicit is an error message that we show when we _don't_ have two non-option arguments. However, it's worth fixing anyway. Besides being slightly more efficient, it makes the code easier to follow, which will help when we modify it in future patches. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-13patch-id: use RUN_SETUP_GENTLYLibravatar Jeff King2-1/+15
Patch-id does not require a repository because it is just processing the incoming diff on stdin, but it may look at git config for keys like patchid.stable. Even though we do not setup_git_directory(), this works from the top-level of a repository because we blindly look at ".git/config" in this case. But as the included test demonstrates, it does not work from a subdirectory. We can fix it by using RUN_SETUP_GENTLY. We do not take any filenames from the user on the command line, so there's no need to adjust them via prefix_filename(). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-13hash-object: always try to set up the git repositoryLibravatar Jeff King2-5/+19
When "hash-object" is run without "-w", we don't need to be in a git repository at all; we can just hash the object and write its sha1 to stdout. However, if we _are_ in a git repository, we would want to know that so we can follow the normal rules for respecting config, .gitattributes, etc. This happens to work at the top-level of a git repository because we blindly read ".git/config", but as the included test shows, it does not work when you are in a subdirectory. The solution is to just do a "gentle" setup in this case. We already take care to use prefix_filename() on any filename arguments we get (to handle the "-w" case), so we don't need to do anything extra to handle the side effects of repo setup. An alternative would be to specify RUN_SETUP_GENTLY for this command in git.c, and then die if "-w" is set but we are not in a repository. However, the error messages generated at the time of setup_git_directory() are more detailed, so it's better to find out which mode we are in, and then call the appropriate function. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-06Git 2.8.4Libravatar Junio C Hamano4-3/+18
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-06Merge branch 'kb/msys2-tty' into maintLibravatar Junio C Hamano2-5/+56
The "are we talking with TTY, doing an interactive session?" detection has been updated to work better for "Git for Windows". * kb/msys2-tty: mingw: make isatty() recognize MSYS2's pseudo terminals (/dev/pty*)
2016-06-06Merge branch 'da/difftool' into maintLibravatar Junio C Hamano2-2/+30
"git difftool" learned to handle unmerged paths correctly in dir-diff mode. * da/difftool: difftool: handle unmerged files in dir-diff mode difftool: initialize variables for readability
2016-06-06Merge branch 'tb/core-eol-fix' into maintLibravatar Junio C Hamano4-189/+141
A couple of bugs around core.autocrlf have been fixed. * tb/core-eol-fix: convert.c: ident + core.autocrlf didn't work t0027: test cases for combined attributes convert: allow core.autocrlf=input and core.eol=crlf t0027: make commit_chk_wrnNNO() reliable
2016-06-06Merge branch 'ar/diff-args-osx-precompose' into maintLibravatar Junio C Hamano5-0/+47
Many commands normalize command line arguments from NFD to NFC variant of UTF-8 on OSX, but commands in the "diff" family did not, causing "git diff $path" to complain that no such path is known to Git. They have been taught to do the normalization. * ar/diff-args-osx-precompose: diff: run arguments through precompose_argv
2016-05-31More topics for 2.8.4Libravatar Junio C Hamano1-0/+28
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-31Merge branch 'sb/submodule-deinit-all' into maintLibravatar Junio C Hamano3-10/+48
Correct faulty recommendation to use "git submodule deinit ." when de-initialising all submodules, which would result in a strange error message in a pathological corner case. * sb/submodule-deinit-all: submodule deinit: require '--all' instead of '.' for all submodules
2016-05-31Merge branch 'bn/http-cookiefile-config' into maintLibravatar Junio C Hamano2-3/+4
"http.cookieFile" configuration variable clearly wants a pathname, but we forgot to treat it as such by e.g. applying tilde expansion. * bn/http-cookiefile-config: http: expand http.cookieFile as a path Documentation: config: improve word ordering for http.cookieFile
2016-05-31Merge branch 'jk/test-send-sh-x-trace-elsewhere' into maintLibravatar Junio C Hamano2-3/+16
Running tests with '-x' option to trace the individual command executions is a useful way to debug test scripts, but some tests that capture the standard error stream and check what the command said can be broken with the trace output mixed in. When running our tests under "bash", however, we can redirect the trace output to another file descriptor to keep the standard error of programs being tested intact. * jk/test-send-sh-x-trace-elsewhere: test-lib: set BASH_XTRACEFD automatically
2016-05-31Merge branch 'js/name-rev-use-oldest-ref' into maintLibravatar Junio C Hamano2-7/+14
"git describe --contains" often made a hard-to-justify choice of tag to give name to a given commit, because it tried to come up with a name with smallest number of hops from a tag, causing an old commit whose close descendant that is recently tagged were not described with respect to an old tag but with a newer tag. It did not help that its computation of "hop" count was further tweaked to penalize being on a side branch of a merge. The logic has been updated to favor using the tag with the oldest tagger date, which is a lot easier to explain to the end users: "We describe a commit in terms of the (chronologically) oldest tag that contains the commit." * js/name-rev-use-oldest-ref: name-rev: include taggerdate in considering the best name
2016-05-26Start preparing for 2.8.4Libravatar Junio C Hamano1-0/+27
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-26Merge branch 'jc/linkgit-fix' into maintLibravatar Junio C Hamano8-10/+10
Many 'linkgit:<git documentation page>' references were broken, which are all fixed with this. * jc/linkgit-fix: Documentation: fix linkgit references
2016-05-26Merge branch 'ls/travis-build-doc' into maintLibravatar Junio C Hamano2-0/+29
CI test was taught to build documentation pages. * ls/travis-build-doc: travis-ci: build documentation
2016-05-26Merge branch 'jc/fsck-nul-in-commit' into maintLibravatar Junio C Hamano2-3/+31
"git fsck" learned to catch NUL byte in a commit object as potential error and warn. * jc/fsck-nul-in-commit: fsck: detect and warn a commit with embedded NUL fsck_commit_buffer(): do not special case the last validation
2016-05-26Merge branch 'jk/rebase-interative-eval-fix' into maintLibravatar Junio C Hamano1-0/+1
Portability enhancement for "rebase -i" to help platforms whose shell does not like "for i in <empty>" (which is not POSIX-kosher). * jk/rebase-interative-eval-fix: rebase--interactive: avoid empty list in shell for-loop
2016-05-26Merge branch 'js/windows-dotgit' into maintLibravatar Junio C Hamano8-3/+147
On Windows, .git and optionally any files whose name starts with a dot are now marked as hidden, with a core.hideDotFiles knob to customize this behaviour. * js/windows-dotgit: mingw: remove unnecessary definition mingw: introduce the 'core.hideDotFiles' setting
2016-05-26Merge branch 'kf/gpg-sig-verification-doc' into maintLibravatar Junio C Hamano2-4/+7
Documentation for "git merge --verify-signatures" has been updated to clarify that the signature of only the commit at the tip is verified. Also the phrasing used for signature and key validity is adjusted to align with that used by OpenPGP. * kf/gpg-sig-verification-doc: Documentation: clarify signature verification
2016-05-26Merge branch 'lp/typofixes' into maintLibravatar Junio C Hamano12-14/+14
Typofixes. * lp/typofixes: typofix: assorted typofixes in comments, documentation and messages
2016-05-26Merge branch 'sb/z-is-gnutar-ism' into maintLibravatar Junio C Hamano2-4/+4
Test fix. * sb/z-is-gnutar-ism: t6041: do not compress backup tar file t3513: do not compress backup tar file
2016-05-26Merge branch 'va/i18n-misc-updates' into maintLibravatar Junio C Hamano8-61/+111
Mark several messages for translation. * va/i18n-misc-updates: i18n: unpack-trees: avoid substituting only a verb in sentences i18n: builtin/pull.c: split strings marked for translation i18n: builtin/pull.c: mark placeholders for translation i18n: git-parse-remote.sh: mark strings for translation i18n: branch: move comment for translators i18n: branch: unmark string for translation i18n: builtin/rm.c: remove a comma ',' from string i18n: unpack-trees: mark strings for translation i18n: builtin/branch.c: mark option for translation i18n: index-pack: use plural string instead of normal one
2016-05-26Merge branch 'bn/config-doc-tt-varnames' into maintLibravatar Junio C Hamano1-21/+29
Doc formatting fixes. * bn/config-doc-tt-varnames: config: consistently format $variables in monospaced font config: describe 'pathname' value type
2016-05-26Merge branch 'nd/remote-plural-ours-plus-theirs' into maintLibravatar Junio C Hamano1-1/+1
Message fix. * nd/remote-plural-ours-plus-theirs: remote.c: specify correct plural form in "commit diverge" message
2016-05-26Merge branch 'ak/t4151-ls-files-could-be-empty' into maintLibravatar Junio C Hamano1-1/+1
Test fix. * ak/t4151-ls-files-could-be-empty: t4151: make sure argument to 'test -z' is given
2016-05-26Merge branch 'jc/test-seq' into maintLibravatar Junio C Hamano1-15/+13
Test fix. * jc/test-seq: test-lib-functions.sh: rewrite test_seq without Perl test-lib-functions.sh: remove misleading comment on test_seq
2016-05-26Merge branch 'tb/t5601-sed-fix' into maintLibravatar Junio C Hamano1-1/+1
Test fix. * tb/t5601-sed-fix: t5601: Remove trailing space in sed expression
2016-05-26Merge branch 'va/i18n-remote-comment-to-align' into maintLibravatar Junio C Hamano1-0/+2
Message fix. * va/i18n-remote-comment-to-align: i18n: remote: add comment for translators
2016-05-26Merge branch 'va/mailinfo-doc-typofix' into maintLibravatar Junio C Hamano1-1/+1
Typofix. * va/mailinfo-doc-typofix: Documentation/git-mailinfo: fix typo
2016-05-26Merge branch 'maint-2.7' into maintLibravatar Junio C Hamano1-1/+1
* maint-2.7: archive-tar: convert snprintf to xsnprintf
2016-05-26mingw: make isatty() recognize MSYS2's pseudo terminals (/dev/pty*)Libravatar Karsten Blees2-5/+56
MSYS2 emulates pseudo terminals via named pipes, and isatty() returns 0 for such file descriptors. Therefore, some interactive functionality (such as launching a pager, asking if a failed unlink should be repeated etc.) doesn't work when run in a terminal emulator that uses MSYS2's ptys (such as mintty). However, MSYS2 uses special names for its pty pipes ('msys-*-pty*'), which allows us to distinguish them from normal piped input / output. On startup, check if stdin / stdout / stderr are connected to such pipes using the NtQueryObject API from NTDll.dll. If the names match, adjust the flags in MSVCRT's ioinfo structure accordingly. Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-26Merge branch 'jk/war-on-sprintf' into maint-2.7Libravatar Junio C Hamano1-1/+1
* jk/war-on-sprintf: archive-tar: convert snprintf to xsnprintf
2016-05-26archive-tar: convert snprintf to xsnprintfLibravatar Jeff King1-1/+1
Commit f2f0267 (archive-tar: use xsnprintf for trivial formatting, 2015-09-24) converted cases of "sprintf" to "xsnprintf", but accidentally left one as just "snprintf". This meant that we could silently truncate the resulting buffer instead of flagging an error. In practice, this is impossible to achieve, as we are formatting a ustar checksum, which can be at most 7 characters. But the point of xsnprintf is to document and check for "should be impossible" conditions; this site was just accidentally mis-converted during f2f0267. Noticed-by: Paul Green <Paul.Green@stratus.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-18Git 2.8.3Libravatar Junio C Hamano4-5/+37
Signed-off-by: Junio C Hamano <gitster@pobox.com>