summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-05-24get_sha1_with_context: dynamically allocate oc->pathJeff King
When a sha1 lookup returns the tree path via "struct object_context", it just copies it into a fixed-size buffer. This means the result can be truncated, and it means our "struct object_context" consumes a lot of stack space. Instead, let's allocate a string on the heap. Because most callers don't care about this information, we'll avoid doing it by default (so they don't all have to start calling free() on the result). There are basically two options for the caller to signal to us that it's interested: 1. By setting a pointer to storage in the object_context. 2. By passing a flag in another parameter. Doing (1) would match the way that sha1_object_info_extended() works. But it would mean that every caller would have to initialize the object_context, which they don't currently have to do. This patch does (2), and adds a new bit to the function's flags field. All of the callers that look at the "path" field are updated to pass the new flag. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-24get_sha1_with_context: always initialize oc->symlink_pathJeff King
The get_sha1_with_context() function zeroes out the oc->symlink_path strbuf, but doesn't use strbuf_init() to set up the usual invariants (like pointing to the slopbuf). We don't actually write to the oc->symlink_path strbuf unless we call get_tree_entry_follow_symlinks(), and that function does initialize it. However, readers may still look at the zero'd strbuf. In practice this isn't a triggerable bug. The only caller that looks at it only does so when the mode we found is 0. This doesn't happen for non-tree-entries (where we return S_IFINVALID). A broken tree entry could have a mode of 0, but canon_mode() quietly rewrites that into S_IFGITLINK. So the "0" mode should only come up when we did indeed find a symlink. This is mostly just an accident of how the code happens to work, though. Let's future-proof ourselves to make sure the strbuf is properly initialized for all calls (it's only a few struct member assignments, not a heap allocation). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-24sha1_name: consistently refer to object_context as "oc"Jeff King
An early version of the patch to add object_context used the name object_resolve_context. This was later shortened to just object_context, but the "orc" variable name stuck in a few places. Let's use "oc", which is used elsewhere in the code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-24handle_revision_arg: add handle_dotdot() helperJeff King
The handle_revision_arg function is rather long, and a big chunk of it is handling the range operators. Let's pull that out to a separate helper. While we're doing so, we can clean up a few of the rough edges that made the flow hard to follow: - instead of manually restoring *dotdot (that we overwrote with a NUL), do the real work in a sub-helper, which makes it clear that the munge/restore lines are a matched pair - eliminate a goto which wasn't actually used for control flow, but only to avoid duplicating a few lines (instead, those lines are pushed into another helper function) - use early returns instead of deep nesting - consistently name all variables for the left-hand side of the range as "a" (rather than "this" or "from") and the right-hand side as "b" (rather than "next", or using the unadorned "sha1" or "flags" from the main function). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-24handle_revision_arg: hoist ".." check out of range parsingJeff King
Since 003c84f6d (specifying ranges: we did not mean to make ".." an empty set, 2011-05-02), we treat the argument ".." specially. We detect it by noticing that both sides of the range are empty, and that this is a non-symmetric two-dot range. While correct, this makes the code overly complicated. We can just detect ".." up front before we try to do further parsing. This avoids having to de-munge the NUL from dotdot, and lets us eliminate an extra const array (which we needed only to do direct pointer comparisons). It also removes the one code path from the range-parsing conditional that requires us to return -1. That will make it simpler to pull the dotdot parsing out into its own function. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-24handle_revision_arg: stop using "dotdot" as a generic pointerJeff King
The handle_revision_arg() function has a "dotdot" variable that it uses to find a ".." or "..." in the argument. If we don't find one, we look for other marks, like "^!". But we just keep re-using the "dotdot" variable, which is confusing. Let's introduce a separate "mark" variable that can be used for these other marks. They still reuse the same variable, but at least the name is no longer actively misleading. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-24handle_revision_arg: simplify commit reference lookupsJeff King
The "dotdot" range parser avoids calling lookup_commit_reference() if we are directly fed two commits. But its casts are unnecessarily complex; that function will just return a commit we pass into it. Just calling the function all the time is much simpler, and doesn't do any significant extra work (the object is already parsed, and deref_tag() on a non-tag is a noop; we do incur one extra lookup_object() call, but that's fairly trivial). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-24handle_revision_arg: reset "dotdot" consistentlyJeff King
When we are parsing a range like "a..b", we write a temporary NUL over the first ".", so that we can access the names "a" and "b" as C strings. But our restoration of the original "." is done at inconsistent times, which can lead to confusing results. For most calls, we restore the "." after we resolve the names, but before we call verify_non_filename(). This means that when we later call add_pending_object(), the name for the left-hand "a" has been re-expanded to "a..b". You can see this with: git log --source a...b where "b" will be correctly marked with "b", but "a" will be marked with "a...b". Likewise with "a..b" (though you need to use --boundary to even see "a" at all in that case). To top off the confusion, when the REVARG_CANNOT_BE_FILENAME flag is set, we skip the non-filename check, and leave the NUL in place. That means we do report the correct name for "a" in the pending array. But some code paths try to show the whole "a...b" name in error messages, and these erroneously show only "a" instead of "a...b". E.g.: $ git cherry-pick HEAD:foo...HEAD:foo error: object d95f3ad14dee633a758d2e331151e950dd13e4ed is a blob, not a commit error: object d95f3ad14dee633a758d2e331151e950dd13e4ed is a blob, not a commit fatal: Invalid symmetric difference expression HEAD:foo (That last message should be "HEAD:foo...HEAD:foo"; I used cherry-pick because it passes the CANNOT_BE_FILENAME flag). As an interesting side note, cherry-pick actually looks at and re-resolves the arguments from the pending->name fields. So it would have been visibly broken by the first bug, but the effect was canceled out by the second one. This patch makes the whole function consistent by re-writing the NUL immediately after calling verify_non_filename(), and then restoring the "." as appropriate in some error-printing and early-return code paths. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-09Git 2.13v2.13.0Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-09Merge tag 'l10n-2.13.0-rnd2.1' of git://github.com/git-l10n/git-poJunio C Hamano
l10n for Git 2.13.0 round 2.1 * tag 'l10n-2.13.0-rnd2.1' of git://github.com/git-l10n/git-po: l10n: zh_CN: for git v2.13.0 l10n round 2 l10n: sv.po: Update Swedish translation (3195t0f0u) l10n: zh_CN: review for git v2.13.0 l10n round 1 l10n: Update Catalan translation l10n: bg.po: Updated Bulgarian translation (3195t) l10n: fr.po v2.13 rnd 2 l10n: de.po: translate 4 new messages l10n: de.po: update German translation l10n: de.po: lower case after semi-colon l10n: vi.po(3195t): Update translation for v2.13.0 round 2 l10n: git.pot: v2.13.0 round 2 (4 new, 7 removed) l10n: zh_CN: for git v2.13.0 l10n round 1 l10n: fr.po v2.13 round 1 l10n: pt_PT: update Portuguese translation l10n: bg.po: Updated Bulgarian translation (3201t) l10n: vi.po(3198t): Updated Vietnamese translation for v2.13.0-rc0 l10n: sv.po: Update Swedish translation (3199t0f0u) l10n: git.pot: v2.13.0 round 1 (96 new, 37 removed)
2017-05-09Merge branch 'master' of git://github.com/nafmo/git-l10n-svJiang Xin
* 'master' of git://github.com/nafmo/git-l10n-sv: l10n: sv.po: Update Swedish translation (3195t0f0u)
2017-05-09l10n: zh_CN: for git v2.13.0 l10n round 2Jiang Xin
Translate 4 messages (3195t0f0u) for git v2.13.0-rc2. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2017-05-09l10n: sv.po: Update Swedish translation (3195t0f0u)Peter Krefting
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
2017-05-09Sync with v2.12.3Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-09Merge branch 'jh/verify-index-checksum-only-in-fsck'Junio C Hamano
* jh/verify-index-checksum-only-in-fsck: t1450: avoid use of "sed" on the index, which is a binary file
2017-05-08l10n: zh_CN: review for git v2.13.0 l10n round 1Ray Chen
Signed-off-by: Ray Chen <oldsharp@gmail.com>
2017-05-08Merge branch 'master' of https://github.com/vnwildman/gitJiang Xin
* 'master' of https://github.com/vnwildman/git: l10n: vi.po(3195t): Update translation for v2.13.0 round 2
2017-05-08l10n: Update Catalan translationJordi Mas
Signed-off-by: Jordi Mas <jmas@softcatala.org>
2017-05-08l10n: bg.po: Updated Bulgarian translation (3195t)Alexander Shopov
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
2017-05-08Merge branch 'fr_l10n_v2.13_rnd2' of git://github.com/jnavila/gitJiang Xin
* 'fr_l10n_v2.13_rnd2' of git://github.com/jnavila/git: l10n: fr.po v2.13 rnd 2
2017-05-06l10n: fr.po v2.13 rnd 2Jean-Noel Avila
Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>
2017-05-05l10n: de.po: translate 4 new messagesRalf Thielow
Translate 4 new messages came from git.pot update in 28e1aaa48 (l10n: git.pot: v2.13.0 round 2 (4 new, 7 removed)). Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Acked-by: Matthias Rüster <matthias.ruester@gmail.com>
2017-05-05l10n: de.po: update German translationRalf Thielow
Translate 96 new messages came from git.pot update in dfc182b (l10n: git.pot: v2.13.0 round 1 (96 new, 37 removed)). Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Acked-by: Matthias Rüster <matthias.ruester@gmail.com>
2017-05-05l10n: de.po: lower case after semi-colonMichael J Gruber
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
2017-05-05l10n: vi.po(3195t): Update translation for v2.13.0 round 2Tran Ngoc Quan
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2017-05-05Git 2.12.3v2.12.3Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Merge branch 'maint-2.11' into maintJunio C Hamano
2017-05-05Git 2.11.2v2.11.2Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Merge branch 'maint-2.10' into maint-2.11Junio C Hamano
2017-05-05Git 2.10.3v2.10.3Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Merge branch 'maint-2.9' into maint-2.10Junio C Hamano
2017-05-05Git 2.9.4v2.9.4Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Merge branch 'maint-2.8' into maint-2.9Junio C Hamano
2017-05-05Git 2.8.5v2.8.5Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Merge branch 'maint-2.7' into maint-2.8Junio C Hamano
2017-05-05Git 2.7.5v2.7.5Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Merge branch 'maint-2.6' into maint-2.7Junio C Hamano
2017-05-05Git 2.6.7v2.6.7Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Merge branch 'maint-2.5' into maint-2.6Junio C Hamano
2017-05-05Git 2.5.6v2.5.6Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Merge branch 'maint-2.4' into maint-2.5Junio C Hamano
2017-05-05Git 2.4.12v2.4.12Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05Merge branch 'jk/shell-no-repository-that-begins-with-dash' into maint-2.4Junio C Hamano
* jk/shell-no-repository-that-begins-with-dash: shell: disallow repo names beginning with dash
2017-05-05shell: disallow repo names beginning with dashJeff King
When a remote server uses git-shell, the client side will connect to it like: ssh server "git-upload-pack 'foo.git'" and we literally exec ("git-upload-pack", "foo.git"). In early versions of upload-pack and receive-pack, we took a repository argument and nothing else. But over time they learned to accept dashed options. If the user passes a repository name that starts with a dash, the results are confusing at best (we complain of a bogus option instead of a non-existent repository) and malicious at worst (the user can start an interactive pager via "--help"). We could pass "--" to the sub-process to make sure the user's argument is interpreted as a branch name. I.e.: git-upload-pack -- -foo.git But adding "--" automatically would make us inconsistent with a normal shell (i.e., when git-shell is not in use), where "-foo.git" would still be an error. For that case, the client would have to specify the "--", but they can't do so reliably, as existing versions of git-shell do not allow more than a single argument. The simplest thing is to simply disallow "-" at the start of the repo name argument. This hasn't worked either with or without git-shell since version 1.0.0, and nobody has complained. Note that this patch just applies to do_generic_cmd(), which runs upload-pack, receive-pack, and upload-archive. There are two other types of commands that git-shell runs: - do_cvs_cmd(), but this already restricts the argument to be the literal string "server" - admin-provided commands in the git-shell-commands directory. We'll pass along arbitrary arguments there, so these commands could have similar problems. But these commands might actually understand dashed arguments, so we cannot just block them here. It's up to the writer of the commands to make sure they are safe. With great power comes great responsibility. Reported-by: Timo Schmid <tschmid@ernw.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-05l10n: git.pot: v2.13.0 round 2 (4 new, 7 removed)Jiang Xin
Generate po/git.pot from v2.13.0-rc2 for git v2.13.0 l10n round 2. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2017-05-05Merge branch 'master' of git://github.com/git-l10n/git-poJiang Xin
* 'master' of git://github.com/git-l10n/git-po: l10n: zh_CN: for git v2.13.0 l10n round 1 l10n: fr.po v2.13 round 1 l10n: pt_PT: update Portuguese translation l10n: bg.po: Updated Bulgarian translation (3201t) l10n: vi.po(3198t): Updated Vietnamese translation for v2.13.0-rc0 l10n: sv.po: Update Swedish translation (3199t0f0u) l10n: git.pot: v2.13.0 round 1 (96 new, 37 removed)
2017-05-05l10n: zh_CN: for git v2.13.0 l10n round 1Jiang Xin
Translate 96 messages (3198t0f0u) for git v2.13.0-rc0. Reviewed-by: 依云 <lilydjwg@gmail.com> Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2017-05-05Merge branch 'fr_l10n_v2.13_rnd1' of git://github.com/jnavila/gitJiang Xin
* 'fr_l10n_v2.13_rnd1' of git://github.com/jnavila/git: l10n: fr.po v2.13 round 1
2017-05-04Git 2.13-rc2v2.13.0-rc2Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-04Merge branch 'rg/a-the-typo'Junio C Hamano
Typofix. * rg/a-the-typo: fix minor typos