summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-10-17l10n: ko.po: Update Korean translationChangwoo Ryu
Signed-off-by: Changwoo Ryu <cwryu@debian.org>
2017-10-17l10n: git.pot: v2.15.0 round 2 (2 new, 2 removed)Jiang Xin
Generate po/git.pot from v2.15.0-rc1 for git v2.15.0 l10n round 2. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2017-10-17Merge branch 'master' of git://github.com/git-l10n/git-poJiang Xin
* 'master' of git://github.com/git-l10n/git-po: l10n: ru.po: update Russian translation l10n: bg.po: Updated Bulgarian translation (3245t) l10n: sv.po: Update Swedish translation (3245t0f0u) l10n: vi.po(3245t): Updated Vietnamese translation for v2.15.0 l10n: es.po: Update translation v2.15.0 round 1 l10n: git.pot: v2.15.0 round 1 (68 new, 36 removed) l10n: es.po: spanish added to TEAMS l10n: es.po: initial Spanish version git 2.14.0
2017-10-15l10n: ru.po: update Russian translationDimitriy Ryazantcev
Signed-off-by: Dimitriy Ryazantcev <dimitriy.ryazantcev@gmail.com>
2017-10-14Merge branch 'master' of git://github.com/alshopov/git-poJiang Xin
* 'master' of git://github.com/alshopov/git-po: l10n: bg.po: Updated Bulgarian translation (3245t)
2017-10-14l10n: bg.po: Updated Bulgarian translation (3245t)Alexander Shopov
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
2017-10-11l10n: sv.po: Update Swedish translation (3245t0f0u)Peter Krefting
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
2017-10-11Git 2.15-rc1v2.15.0-rc1Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-11Merge branch 'ls/filter-process-delayed'Junio C Hamano
Bugfixes to an already graduated series. * ls/filter-process-delayed: write_entry: untangle symlink and regular-file cases write_entry: avoid reading blobs in CE_RETRY case write_entry: fix leak when retrying delayed filter entry.c: check if file exists after checkout entry.c: update cache entry only for existing files
2017-10-11Merge branch 'ds/avoid-overflow-in-midpoint-computation'Junio C Hamano
Code clean-up. * ds/avoid-overflow-in-midpoint-computation: cleanup: fix possible overflow errors in binary search
2017-10-11Merge branch 'tb/complete-describe'Junio C Hamano
Docfix. * tb/complete-describe: completion: add --broken and --dirty to describe
2017-10-11Merge branch 'sb/test-cmp-expect-actual'Junio C Hamano
Test tweak. * sb/test-cmp-expect-actual: tests: fix diff order arguments in test_cmp
2017-10-11Merge branch 'jk/refs-df-conflict'Junio C Hamano
An ancient bug that made Git misbehave with creation/renaming of refs has been fixed. * jk/refs-df-conflict: refs_resolve_ref_unsafe: handle d/f conflicts for writes t3308: create a real ref directory/file conflict
2017-10-11Merge branch 'rs/rs-mailmap'Junio C Hamano
* rs/rs-mailmap: .mailmap: normalize name for René Scharfe
2017-10-11Merge branch 'rs/fsck-null-return-from-lookup'Junio C Hamano
Improve behaviour of "git fsck" upon finding a missing object. * rs/fsck-null-return-from-lookup: fsck: handle NULL return of lookup_blob() and lookup_tree()
2017-10-11Merge branch 'jk/sha1-loose-object-info-fix'Junio C Hamano
Leakfix and futureproofing. * jk/sha1-loose-object-info-fix: sha1_loose_object_info: handle errors from unpack_sha1_rest
2017-10-11Merge branch 'hn/string-list-doc'Junio C Hamano
Docfix. * hn/string-list-doc: api-argv-array.txt: remove broken link to string-list API
2017-10-11Merge branch 'tb/show-trailers-in-ref-filter'Junio C Hamano
"git for-each-ref --format=..." learned a new format element, %(trailers), to show only the commit log trailer part of the log message. * tb/show-trailers-in-ref-filter: ref-filter.c: parse trailers arguments with %(contents) atom ref-filter.c: use trailer_opts to format trailers t6300: refactor %(trailers) tests doc: use "`<literal>`"-style quoting for literal strings doc: 'trailers' is the preferred way to format trailers t4205: unfold across multiple lines
2017-10-11Merge branch 'jt/oidmap'Junio C Hamano
Introduce a new "oidmap" API and rewrite oidset to use it. * jt/oidmap: oidmap: map with OID as key
2017-10-11Merge branch 'jr/hash-migration-plan-doc'Junio C Hamano
Lay out plans for weaning us off of SHA-1. * jr/hash-migration-plan-doc: technical doc: add a design doc for hash function transition
2017-10-11Merge branch 'master' of https://github.com/vnwildman/gitJiang Xin
* 'master' of https://github.com/vnwildman/git: l10n: vi.po(3245t): Updated Vietnamese translation for v2.15.0
2017-10-10write_entry: untangle symlink and regular-file casesJeff King
The write_entry() function switches on the mode of the entry we're going to write out. The cases for S_IFLNK and S_IFREG are lumped together. In earlier versions of the code, this made some sense. They have a shared preamble (which reads the blob content), a short type-specific body, and a shared conclusion (which writes out the file contents; always for S_IFREG and only sometimes for S_IFLNK). But over time this has grown to make less sense. The preamble now has conditional bits for each type, and the S_IFREG body has grown a lot more complicated. It's hard to follow the logic of which code is running for which mode. Let's give each mode its own case arm. We will still share the conclusion code, which means we now jump to it with a goto. Ideally we'd pull that shared code into its own function, but it touches so much internal state in the write_entry() function that the end result is actually harder to follow than the goto. While we're here, we'll touch up a few bits of whitespace to make the beginning and endings of the cases easier to read. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-09write_entry: avoid reading blobs in CE_RETRY caseJeff King
When retrying a delayed filter-process request, we don't need to send the blob to the filter a second time. However, we read it unconditionally into a buffer, only to later throw away that buffer. We can make this more efficient by skipping the read in the first place when it isn't necessary. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-09write_entry: fix leak when retrying delayed filterJeff King
When write_entry() retries a delayed filter request, we don't need to send the blob content to the filter again, and set the pointer to NULL. But doing so means we leak the contents we read earlier from read_blob_entry(). Let's make sure to free it before dropping the pointer. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-09cleanup: fix possible overflow errors in binary searchDerrick Stolee
A common mistake when writing binary search is to allow possible integer overflow by using the simple average: mid = (min + max) / 2; Instead, use the overflow-safe version: mid = min + (max - min) / 2; This translation is safe since the operation occurs inside a loop conditioned on "min < max". The included changes were found using the following git grep: git grep '/ *2;' '*.c' Making this cleanup will prevent future review friction when a new binary search is contructed based on existing code. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-09Merge branch 'js/rebase-i-final'Junio C Hamano
* js/rebase-i-final: i18n: add a missing space in message
2017-10-09i18n: add a missing space in messageJean-Noel Avila
The message spans over 2 lines but the C conconcatenation does not add the needed space between the two lines. Signed-off-by: Jean-Noel Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-09l10n: vi.po(3245t): Updated Vietnamese translation for v2.15.0Tran Ngoc Quan
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2017-10-08l10n: es.po: Update translation v2.15.0 round 1Christopher Díaz
Signed-off-by: Christopher Díaz <christopher.diaz.riv@gmail.com>
2017-10-08Merge branch 'maint' of git://github.com/git-l10n/git-poJiang Xin
* 'maint' of git://github.com/git-l10n/git-po: l10n: es.po: spanish added to TEAMS l10n: es.po: initial Spanish version git 2.14.0
2017-10-08l10n: git.pot: v2.15.0 round 1 (68 new, 36 removed)Jiang Xin
Generate po/git.pot from commit d35688db19 ("Prepare for -rc1", 2017-10-07) for git v2.15.0 l10n round 1. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2017-10-07Prepare for -rc1Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-07Merge branch 'tb/ref-filter-empty-modifier'Junio C Hamano
In the "--format=..." option of the "git for-each-ref" command (and its friends, i.e. the listing mode of "git branch/tag"), "%(atom:)" (e.g. "%(refname:)", "%(body:)" used to error out. Instead, treat them as if the colon and an empty string that follows it were not there. * tb/ref-filter-empty-modifier: ref-filter.c: pass empty-string as NULL to atom parsers
2017-10-07Merge branch 'ks/verify-filename-non-option-error-message-tweak'Junio C Hamano
Error message tweak. * ks/verify-filename-non-option-error-message-tweak: setup: update error message to be more meaningful
2017-10-07Merge branch 'ks/branch-tweak-error-message-for-extra-args'Junio C Hamano
Error message tweak. * ks/branch-tweak-error-message-for-extra-args: branch: change the error messages to be more meaningful
2017-10-07Merge branch 'jk/ui-color-always-to-auto'Junio C Hamano
Fix regression of "git add -p" for users with "color.ui = always" in their configuration, by merging the topic below and adjusting it for the 'master' front. * jk/ui-color-always-to-auto: t7301: use test_terminal to check color t4015: use --color with --color-moved color: make "always" the same as "auto" in config provide --color option for all ref-filter users t3205: use --color instead of color.branch=always t3203: drop "always" color test t6006: drop "always" color config tests t7502: use diff.noprefix for --verbose test t7508: use test_terminal for color output t3701: use test-terminal to collect color output t4015: prefer --color to -c color.diff=always test-terminal: set TERM=vt100
2017-10-07Merge branch 'ma/builtin-unleak'Junio C Hamano
Many variables that points at a region of memory that will live throughout the life of the program have been marked with UNLEAK marker to help the leak checkers concentrate on real leaks.. * ma/builtin-unleak: builtin/: add UNLEAKs
2017-10-07Merge branch 'rb/compat-poll-fix'Junio C Hamano
Backports a moral equivalent of 2015 fix to the poll emulation from the upstream gnulib to fix occasional breakages on HPE NonStop. * rb/compat-poll-fix: poll.c: always set revents, even if to zero
2017-10-07Merge branch 'tg/memfixes'Junio C Hamano
Fixes for a handful memory access issues identified by valgrind. * tg/memfixes: sub-process: use child_process.args instead of child_process.argv http-push: fix construction of hex value from path path.c: fix uninitialized memory access
2017-10-07Merge branch 'sb/branch-avoid-repeated-strbuf-release'Junio C Hamano
* sb/branch-avoid-repeated-strbuf-release: branch: reset instead of release a strbuf
2017-10-07Merge branch 'rs/qsort-s'Junio C Hamano
* rs/qsort-s: test-stringlist: avoid buffer underrun when sorting nothing
2017-10-07Merge branch 'jn/strbuf-doc-re-reuse'Junio C Hamano
* jn/strbuf-doc-re-reuse: strbuf doc: reuse after strbuf_release is fine
2017-10-07Merge branch 'tb/delimit-pretty-trailers-args-with-comma'Junio C Hamano
The feature that allows --pretty='%(trailers)' to take modifiers like "fold" and "only" used to separate these modifiers with a comma, i.e. "%(trailers:fold:only)", but we changed our mind and use a comma, i.e. "%(trailers:fold,only)". Fast track this change before this new feature becomes part of any official release. * tb/delimit-pretty-trailers-args-with-comma: pretty.c: delimit "%(trailers)" arguments with ","
2017-10-07completion: add --broken and --dirty to describeThomas Braun
When the flags for broken and dirty were implemented in b0176ce6b5 (builtin/describe: introduce --broken flag, 2017-03-21) and 9f67d2e827 (Teach "git describe" --dirty option, 2009-10-21) the completion was not updated, although these flags are useful completions. Add them. Signed-off-by: Thomas Braun <thomas.braun@virtuell-zuhause.de> Helped-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-07tests: fix diff order arguments in test_cmpStefan Beller
Fix the argument order for test_cmp. When given the expected result first the diff shows the actual output with '+' and the expectation with '-', which is the convention for our tests. Signed-off-by: Stefan Beller <sbeller@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-07refs_resolve_ref_unsafe: handle d/f conflicts for writesJeff King
If our call to refs_read_raw_ref() fails, we check errno to see if the ref is simply missing, or if we encountered a more serious error. If it's just missing, then in "write" mode (i.e., when RESOLVE_REFS_READING is not set), this is perfectly fine. However, checking for ENOENT isn't sufficient to catch all missing-ref cases. In the filesystem backend, we may also see EISDIR when we try to resolve "a" and "a/b" exists. Likewise, we may see ENOTDIR if we try to resolve "a/b" and "a" exists. In both of those cases, we know that our resolved ref doesn't exist, but we return an error (rather than reporting the refname and returning a null sha1). This has been broken for a long time, but nobody really noticed because the next step after resolving without the READING flag is usually to lock the ref and write it. But in both of those cases, the write will fail with the same errno due to the directory/file conflict. There are two cases where we can notice this, though: 1. If we try to write "a" and there's a leftover directory already at "a", even though there is no ref "a/b". The actual write is smart enough to move the empty "a" out of the way. This is reasonably rare, if only because the writing code has to do an independent resolution before trying its write (because the actual update_ref() code handles this case fine). The notes-merge code does this, and before the fix in the prior commit t3308 erroneously expected this case to fail. 2. When resolving symbolic refs, we typically do not use the READING flag because we want to resolve even symrefs that point to unborn refs. Even if those unborn refs could not actually be written because of d/f conflicts with existing refs. You can see this by asking "git symbolic-ref" to report the target of a symref pointing past a d/f conflict. We can fix the problem by recognizing the other "missing" errnos and treating them like ENOENT. This should be safe to do even for callers who are then going to actually write the ref, because the actual writing process will fail if the d/f conflict is a real one (and t1404 checks these cases). Arguably this should be the responsibility of the files-backend to normalize all "missing ref" errors into ENOENT (since something like EISDIR may not be meaningful at all to a database backend). However other callers of refs_read_raw_ref() may actually care about the distinction; putting this into resolve_ref() is the minimal fix for now. The new tests in t1401 use git-symbolic-ref, which is the most direct way to check the resolution by itself. Interestingly we actually had a test that setup this case already, but we only used it to verify that the funny state could be overwritten, not that it could be resolved. We also add a new test in t3200, as "branch -m" was the original motivation for looking into this. What happens is this: 0. HEAD is pointing to branch "a" 1. The user asks to rename "a" to "a/b". 2. We create "a/b" and delete "a". 3. We then try to update any worktree HEADs that point to the renamed ref (including the main repo HEAD). To do that, we have to resolve each HEAD. But now our HEAD is pointing at "a", and we get EISDIR due to the loose "a/b". As a result, we think there is no HEAD, and we do not update it. It now points to the bogus "a". Interestingly this case used to work, but only accidentally. Before 31824d180d (branch: fix branch renaming not updating HEADs correctly, 2017-08-24), we'd update any HEAD which we couldn't resolve. That was wrong, but it papered over the fact that we were incorrectly failing to resolve HEAD. So while the bug demonstrated by the git-symbolic-ref is quite old, the regression to "branch -m" is recent. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-07t3308: create a real ref directory/file conflictJeff King
A test in t3308 wants to make sure that we don't accidentally merge into "refs/notes/dir" when it exists as a directory, so it does: mkdir .git/refs/notes/dir git -c core.notesRef=refs/notes/dir merge ... and expects the second command to fail. But that understimates the refs code, which is smart enough to remove useless directories in the refs hierarchy. The test succeeded only because of a bug which prevented resolving refs/notes/dir for writing, even though an actual ref update would succeed. In preparation for fixing that bug, let's switch to creating a real ref in refs/notes/dir, which is a more realistic situation. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-06api-argv-array.txt: remove broken link to string-list APITodd Zullinger
In 4f665f2cf3 (string-list.h: move documentation from Documentation/api/ into header, 2017-09-26) the string-list API documentation was moved to string-list.h. The argv-array API documentation may follow a similar course in the future. Until then, prevent the broken link from making it to the end-user documentation. Signed-off-by: Todd Zullinger <tmz@pobox.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-06entry.c: check if file exists after checkoutLars Schneider
If we are checking out a file and somebody else racily deletes our file, then we would write garbage to the cache entry. Fix that by checking the result of the lstat() call on that file. Print an error to the user if the file does not exist. Reported-by: Jeff King <peff@peff.net> Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-06sha1_loose_object_info: handle errors from unpack_sha1_restJeff King
When a caller of sha1_object_info_extended() sets the "contentp" field in object_info, we call unpack_sha1_rest() but do not check whether it signaled an error. This causes two problems: 1. We pass back NULL to the caller via the contentp field, but the function returns "0" for success. A caller might reasonably expect after a successful return that it can access contentp without a NULL check and segfault. As it happens, this is impossible to trigger in the current code. There is exactly one caller which uses contentp, read_object(). And the only thing it does after a successful call is to return the content pointer to its caller, using NULL as a sentinel for errors. So in effect it converts the success code from sha1_object_info_extended() back into an error! But this is still worth addressing avoid problems for future users of "contentp". 2. Callers of unpack_sha1_rest() are expected to close the zlib stream themselves on error. Which means that we're leaking the stream. The problem in (1) comes from from c84a1f3ed4 (sha1_file: refactor read_object, 2017-06-21), which added the contentp field. Before that, we called unpack_sha1_rest() via unpack_sha1_file(), which directly used the NULL to signal an error. But note that the leak in (2) is actually older than that. The original unpack_sha1_file() directly returned the result of unpack_sha1_rest() to its caller, when it should have been closing the zlib stream itself on error. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>