summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-06-16l10n: git.pot: v2.18.0 round 3 (1 new, 1 removed)Libravatar Jiang Xin1-17/+17
Generate po/git.pot from v2.18.0-rc2 for git v2.18.0 l10n round 3. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2018-06-16Merge branch 'master' of git://github.com/git-l10n/git-poLibravatar Jiang Xin8-12862/+18214
* 'master' of git://github.com/git-l10n/git-po: l10n: vi.po(3608t): Update Vietnamese translation for v2.18.0 round2 l10n: bg.po: Updated Bulgarian translation (3608t) l10n: es.po: Spanish update for v2.18.0 round 2 l10n: git.pot: v2.18.0 round 2 (144 new, 6 removed) l10n: fr.po v2.18 round 1 l10n: vi(3470t): Updated Vietnamese translation for v2.18.0 l10n: es.po: Spanish update for v2.18.0 round 1 l10n: git.pot: v2.18.0 round 1 (108 new, 14 removed) l10n: TEAMS: remove inactive de team members l10n: de.po: fix typos l10n: Update Catalan translation
2018-06-15Merge branch 'master' of https://github.com/vnwildman/gitLibravatar Jiang Xin1-430/+994
* 'master' of https://github.com/vnwildman/git: l10n: vi.po(3608t): Update Vietnamese translation for v2.18.0 round2
2018-06-14l10n: vi.po(3608t): Update Vietnamese translation for v2.18.0 round2Libravatar Tran Ngoc Quan1-430/+994
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2018-06-13Git 2.18-rc2Libravatar Junio C Hamano2-1/+7
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-13Merge branch 'jk/index-pack-maint'Libravatar Junio C Hamano4-2/+25
"index-pack --strict" has been taught to make sure that it runs the final object integrity checks after making the freshly indexed packfile available to itself. * jk/index-pack-maint: index-pack: correct install_packed_git() args index-pack: handle --strict checks of non-repo packs prepare_commit_graft: treat non-repository as a noop
2018-06-13Merge branch 'sg/completion-zsh-workaround'Libravatar Junio C Hamano2-2/+5
Work around zsh segfaulting when loading git-completion.zsh * sg/completion-zsh-workaround: completion: correct zsh detection when run from git-completion.zsh
2018-06-13Merge branch 'sb/submodule-merge-in-merge-recursive'Libravatar Junio C Hamano1-2/+2
Finishing touches to a topic that already is in 'master'. * sb/submodule-merge-in-merge-recursive: merge-submodule: reduce output verbosity
2018-06-13Merge branch 'jk/submodule-fsck-loose-fixup'Libravatar Junio C Hamano2-8/+24
Finishing touches to a topic that already is in 'maint'. * jk/submodule-fsck-loose-fixup: fsck: avoid looking at NULL blob->object t7415: don't bother creating commit for symlink test
2018-06-13RelNotes 2.18: clarify where directory rename detection appliesLibravatar Elijah Newren1-1/+1
Mention that this feature works with some commands (merge and cherry-pick, implying that it also works with commands that build on these like rebase -m and rebase -i). Explicitly mentioning two commands hopefully implies that it may not always work with other commands (am, and rebase without flags that imply either -m or -i). Also, since the directory rename detection from this cycle was specifically added in merge-recursive and not diffcore-rename, remove the 'in "diff" family" phrase from the note. (Folks have requested in the past that `git diff` detect directory renames and somehow simplify its output, so it may be helpful to avoid implying that diff has any new capability here.) Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-12completion: correct zsh detection when run from git-completion.zshLibravatar SZEDER Gábor2-2/+5
v2.18.0-rc0~90^2 (completion: reduce overhead of clearing cached --options, 2018-04-18) worked around a bug in bash's "set" builtin on MacOS by using compgen instead. It was careful to avoid breaking zsh by guarding this workaround with if [[ -n ${ZSH_VERSION-}} ]] Alas, this interacts poorly with git-completion.zsh's bash emulation: ZSH_VERSION='' . "$script" Correct it by instead using a new GIT_SOURCING_ZSH_COMPLETION shell variable to detect whether git-completion.bash is being sourced from git-completion.zsh. This way, the zsh variant is used both when run from zsh directly and when run via git-completion.zsh. Reproduction recipe: 1. cd git/contrib/completion && cp git-completion.zsh _git 2. Put the following in a new ~/.zshrc file: autoload -U compinit; compinit autoload -U bashcompinit; bashcompinit fpath=(~/src/git/contrib/completion $fpath) 3. Open zsh and "git <TAB>". With this patch: Triggers nice git-completion.bash based tab completion Without: contrib/completion/git-completion.bash:354: read-only variable: QISUFFIX zsh:12: command not found: ___main zsh:15: _default: function definition file not found _dispatch:70: bad math expression: operand expected at `/usr/bin/g...' Segmentation fault Reported-by: Rick van Hattem <wolph@wol.ph> Reported-by: Dave Borowitz <dborowitz@google.com> Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-12l10n: bg.po: Updated Bulgarian translation (3608t)Libravatar Alexander Shopov1-2463/+3598
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
2018-06-11index-pack: correct install_packed_git() argsLibravatar Junio C Hamano1-1/+1
The function does not start taking the repository object as a parameter before v2.18 track. Make the topic mergeable to v2.17 maintenance track by dropping it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-11merge-submodule: reduce output verbosityLibravatar Leif Middelschulte1-2/+2
The output shall behave more similar to ordinary file merges' output to provide a more consistent user experience. Signed-off-by: Leif Middelschulte <Leif.Middelschulte@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-11fsck: avoid looking at NULL blob->objectLibravatar Jeff King2-1/+20
Commit 159e7b080b (fsck: detect gitmodules files, 2018-05-02) taught fsck to look at the content of .gitmodules files. If the object turns out not to be a blob at all, we just complain and punt on checking the content. And since this was such an obvious and trivial code path, I didn't even bother to add a test. Except it _does_ do one non-trivial thing, which is call the report() function, which wants us to pass a pointer to a "struct object". Which we don't have (we have only a "struct object_id"). So we erroneously pass a NULL object to report(), which gets dereferenced and causes a segfault. It seems like we could refactor report() to just take the object_id itself. But we pass the object pointer along to a callback function, and indeed this ends up in builtin/fsck.c's objreport() which does want to look at other parts of the object (like the type). So instead, let's just use lookup_unknown_object() to get the real "struct object", and pass that. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-11t7415: don't bother creating commit for symlink testLibravatar Jeff King1-7/+4
Early versions of the fsck .gitmodules detection code actually required a tree to be at the root of a commit for it to be checked for .gitmodules. What we ended up with in 159e7b080b (fsck: detect gitmodules files, 2018-05-02), though, finds a .gitmodules file in _any_ tree (see that commit for more discussion). As a result, there's no need to create a commit in our tests. Let's drop it in the name of simplicity. And since that was the only thing referencing $tree, we can pull our tree creation out of a command substitution. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-11RelNotes 2.18: typofixesLibravatar Junio C Hamano1-2/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-10l10n: es.po: Spanish update for v2.18.0 round 2Libravatar Christopher Diaz Riveros1-422/+994
Signed-off-by: Christopher Diaz Riveros <chrisadr@gentoo.org>
2018-06-08l10n: git.pot: v2.18.0 round 2 (144 new, 6 removed)Libravatar Jiang Xin1-409/+962
Generate po/git.pot from v2.18.0-rc1 for git v2.18.0 l10n round 2. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2018-06-08Merge branch 'master' of git://github.com/git-l10n/git-poLibravatar Jiang Xin7-9951/+12479
* 'master' of git://github.com/git-l10n/git-po: l10n: fr.po v2.18 round 1 l10n: vi(3470t): Updated Vietnamese translation for v2.18.0 l10n: es.po: Spanish update for v2.18.0 round 1 l10n: git.pot: v2.18.0 round 1 (108 new, 14 removed) l10n: TEAMS: remove inactive de team members l10n: de.po: fix typos l10n: Update Catalan translation
2018-06-04Git 2.18-rc1Libravatar Junio C Hamano2-1/+13
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-04Merge branch 'bc/t3430-fixup'Libravatar Junio C Hamano1-3/+2
Test fix. * bc/t3430-fixup: t3430: test clean-up
2018-06-04Merge branch 'bw/refspec-api'Libravatar Junio C Hamano1-0/+2
Hotfix. * bw/refspec-api: refspec-api: avoid uninitialized field in refspec item
2018-06-04Merge branch 'tg/doc-sec-list'Libravatar Junio C Hamano2-4/+20
Doc update. * tg/doc-sec-list: note git-security@googlegroups.com in more places SubmittingPatches: replace numbered attributes with names
2018-06-04Merge branch 'rd/p4-doc-markup-env'Libravatar Junio C Hamano1-5/+5
Doc markup update. * rd/p4-doc-markup-env: p4.txt: Use backquotes for variable names
2018-06-04Merge branch 'nd/remote-update-doc'Libravatar Junio C Hamano1-2/+2
"git remote update" can take both a single remote nickname and a nickname for remote groups, but only one of them was documented. * nd/remote-update-doc: remote: doc typofix remote.txt: update documentation for 'update' command
2018-06-04Merge branch 'jt/submodule-pull-recurse-rebase'Libravatar Junio C Hamano3-3/+29
"git pull -recurse-submodules --rebase", when the submodule repository's history did not have anything common between ours and the upstream's, failed to execute. We need to fetch from them to continue even in such a case. * jt/submodule-pull-recurse-rebase: submodule: do not pass null OID to setup_revisions
2018-06-04remote: doc typofixLibravatar Duy Nguyen1-1/+1
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-04t3430: test clean-upLibravatar brian m. carlson1-3/+2
Remove unnecessary test_tick etc... Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-04Merge branch 'fr_2.18_round1' of git://github.com/jnavila/gitLibravatar Jiang Xin1-2317/+2889
* 'fr_2.18_round1' of git://github.com/jnavila/git: l10n: fr.po v2.18 round 1
2018-06-03l10n: fr.po v2.18 round 1Libravatar Jean-Noël Avila1-2317/+2889
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
2018-06-03l10n: vi(3470t): Updated Vietnamese translation for v2.18.0Libravatar Tran Ngoc Quan1-2298/+2863
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2018-06-02l10n: es.po: Spanish update for v2.18.0 round 1Libravatar Christopher Diaz Riveros1-2360/+2918
Signed-off-by: Christopher Diaz Riveros <chrisadr@gentoo.org>
2018-06-01A bit more topics before -rc1Libravatar Junio C Hamano1-0/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-01Merge branch 'bw/ref-prefix-for-configured-refspec'Libravatar Junio C Hamano3-0/+25
* bw/ref-prefix-for-configured-refspec: fetch: do not pass ref-prefixes for fetch by exact SHA1
2018-06-01fetch: do not pass ref-prefixes for fetch by exact SHA1Libravatar Jonathan Nieder3-0/+25
When v2.18.0-rc0~10^2~1 (refspec: consolidate ref-prefix generation logic, 2018-05-16) factored out the ref-prefix generation code for reuse, it left out the 'if (!item->exact_sha1)' test in the original ref-prefix generation code. As a result, fetches by SHA-1 generate ref-prefixes as though the SHA-1 being fetched were an abbreviated ref name: $ GIT_TRACE_PACKET=1 bin-wrappers/git -c protocol.version=2 \ fetch origin 12039e008f9a4e3394f3f94f8ea897785cb09448 [...] packet: fetch> ref-prefix 12039e008f9a4e3394f3f94f8ea897785cb09448 packet: fetch> ref-prefix refs/12039e008f9a4e3394f3f94f8ea897785cb09448 packet: fetch> ref-prefix refs/tags/12039e008f9a4e3394f3f94f8ea897785cb09448 packet: fetch> ref-prefix refs/heads/12039e008f9a4e3394f3f94f8ea897785cb09448 packet: fetch> ref-prefix refs/remotes/12039e008f9a4e3394f3f94f8ea897785cb09448 packet: fetch> ref-prefix refs/remotes/12039e008f9a4e3394f3f94f8ea897785cb09448/HEAD packet: fetch> 0000 If there is another ref name on the command line or the object being fetched is already available locally, then that's mostly harmless. But otherwise, we error out with fatal: no matching remote head since the server did not send any refs we are interested in. Filter out the exact_sha1 refspecs to avoid this. This patch adds a test to check this behavior that notices another behavior difference between protocol v0 and v2 in the process. Add a NEEDSWORK comment to clear it up. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-01Merge branch 'cc/tests-without-assuming-ref-files-backend'Libravatar Junio C Hamano11-27/+28
Quite a many tests assumed that newly created refs are made as loose refs using the files backend, which have been updated to use proper plumbing like rev-parse and update-ref, to avoid breakage once we start using different ref backends. * cc/tests-without-assuming-ref-files-backend: t990X: use '.git/objects' as 'deep inside .git' path t: make many tests depend less on the refs being files
2018-06-01Merge branch 'rd/init-typo'Libravatar Junio C Hamano1-1/+1
Message fix. * rd/init-typo: init: fix grammar in "templates not found" msg
2018-06-01Merge branch 'js/rebase-recreate-merge'Libravatar Junio C Hamano3-2/+19
Hotfixes. * js/rebase-recreate-merge: sequencer: ensure labels that are object IDs are rewritten git-rebase--interactive: fix copy-paste mistake
2018-06-01Merge branch 'rd/tag-doc-lightweight'Libravatar Junio C Hamano1-2/+2
Docfix. * rd/tag-doc-lightweight: tag: clarify in the doc that a tag can refer to a non-commit object
2018-06-01Merge branch 'rd/doc-options-placeholder'Libravatar Junio C Hamano19-38/+38
Docfix. * rd/doc-options-placeholder: Use proper syntax for replaceables in command docs
2018-06-01Merge branch 'en/rev-parse-invalid-range'Libravatar Junio C Hamano2-2/+14
"git rev-parse Y..." etc. misbehaved when given endpoints were not committishes. * en/rev-parse-invalid-range: rev-parse: check lookup'ed commit references for NULL
2018-06-01Merge branch 'ld/p4-unshelve'Libravatar Junio C Hamano3-36/+347
"git p4" learned to "unshelve" shelved commit from P4. * ld/p4-unshelve: git-p4: add unshelve command
2018-06-01Merge branch 'nd/use-opt-int-set-f'Libravatar Junio C Hamano11-50/+47
Code simplification. * nd/use-opt-int-set-f: Use OPT_SET_INT_F() for cmdline option specification
2018-06-01Merge branch 'pa/import-tars-long-names'Libravatar Junio C Hamano1-2/+29
The import-tars script (in contrib/) has been taught to handle tarballs with overly long paths that use PAX extended headers. * pa/import-tars-long-names: import-tars: read overlong names from pax extended header
2018-06-01Merge branch 'nd/command-list'Libravatar Junio C Hamano25-313/+589
The list of commands with their various attributes were spread across a few places in the build procedure, but it now is getting a bit more consolidated to allow more automation. * nd/command-list: completion: allow to customize the completable command list completion: add and use --list-cmds=alias completion: add and use --list-cmds=nohelpers Move declaration for alias.c to alias.h completion: reduce completable command list completion: let git provide the completable command list command-list.txt: documentation and guide line help: use command-list.txt for the source of guides help: add "-a --verbose" to list all commands with synopsis git: support --list-cmds=list-<category> completion: implement and use --list-cmds=main,others git --list-cmds: collect command list in a string_list git.c: convert --list-* to --list-cmds=* Remove common-cmds.h help: use command-list.h for common command list generate-cmds.sh: export all commands to command-list.h generate-cmds.sh: factor out synopsis extract code
2018-06-01index-pack: handle --strict checks of non-repo packsLibravatar Jeff King2-2/+16
Commit 73c3f0f704 (index-pack: check .gitmodules files with --strict, 2018-05-04) added a call to add_packed_git(), with the intent that the newly-indexed objects would be available to the process when we run fsck_finish(). But that's not what add_packed_git() does. It only allocates the struct, and you must install_packed_git() on the result. So that call was effectively doing nothing (except leaking a struct). But wait, we passed all of the tests! Does that mean we don't need the call at all? For normal cases, no. When we run "index-pack --stdin" inside a repository, we write the new pack into the object directory. If fsck_finish() needs to access one of the new objects, then our initial lookup will fail to find it, but we'll follow up by running reprepare_packed_git() and looking again. That logic was meant to handle somebody else repacking simultaneously, but it ends up working for us here. But there is a case that does need this, that we were not testing. You can run "git index-pack foo.pack" on any file, even when it is not inside the object directory. Or you may not even be in a repository at all! This case fails without doing the proper install_packed_git() call. We can make this work by adding the install call. Note that we should be prepared to handle add_packed_git() failing. We can just silently ignore this case, though. If fsck_finish() later needs the objects and they're not available, it will complain itself. And if it doesn't (because we were able to resolve the whole fsck in the first pass), then it actually isn't an interesting error at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-01prepare_commit_graft: treat non-repository as a noopLibravatar Jeff King2-0/+9
The parse_commit_buffer() function consults lookup_commit_graft() to see if we need to rewrite parents. The latter will look at $GIT_DIR/info/grafts. If you're outside of a repository, then this will trigger a BUG() as of b1ef400eec (setup_git_env: avoid blind fall-back to ".git", 2016-10-20). It's probably uncommon to actually parse a commit outside of a repository, but you can see it in action with: cd /not/a/git/repo git index-pack --strict /some/file.pack This works fine without --strict, but the fsck checks will try to parse any commits, triggering the BUG(). We can fix that by teaching the graft code to behave as if there are no grafts when we aren't in a repository. Arguably index-pack (and fsck) are wrong to consider grafts at all. So another solution is to disable grafts entirely for those commands. But given that the graft feature is deprecated anyway, it's not worth even thinking through the ramifications that might have. There is one other corner case I considered here. What should: cd /not/a/git/repo export GIT_GRAFT_FILE=/file/with/grafts git index-pack --strict /some/file.pack do? We don't have a repository, but the user has pointed us directly at a graft file, which we could respect. I believe this case did work that way prior to b1ef400eec. However, fixing it now would be pretty invasive. Back then we would just call into setup_git_env() even without a repository. But these days it actually takes a git_dir argument. So there would be a fair bit of refactoring of the setup code involved. Given the obscurity of this case, plus the fact that grafts are deprecated and probably shouldn't work under index-pack anyway, it's not worth pursuing further. This patch at least un-breaks the common case where you're _not_ using grafts, but we BUG() anyway trying to even find that out. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-01refspec-api: avoid uninitialized field in refspec itemLibravatar Junio C Hamano1-0/+2
When parse_refspec() function was created at 3eec3700 ("refspec: factor out parsing a single refspec", 2018-05-16) to take a caller supplied piece of memory to fill parsed refspec_item, it forgot that a refspec without colon must set item->dst to NULL to let the users of refspec know that the result of the fetch does not get stored in an ref on our side. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-01p4.txt: Use backquotes for variable namesLibravatar Robert P. J. Day1-5/+5
For consistency, use backquotes when referring to environment variables, as is done in other man pages. Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Junio C Hamano <gitster@pobox.com>