Permalink
Commits on Sep 27, 2018
  1. Git 2.19.1

    gitster committed Sep 27, 2018
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  2. Sync with 2.18.1

    gitster committed Sep 27, 2018
    * maint-2.18:
      Git 2.18.1
      Git 2.17.2
      fsck: detect submodule paths starting with dash
      fsck: detect submodule urls starting with dash
      Git 2.16.5
      Git 2.15.3
      Git 2.14.5
      submodule-config: ban submodule paths that start with a dash
      submodule-config: ban submodule urls that start with dash
      submodule--helper: use "--" to signal end of clone options
  3. Git 2.18.1

    gitster committed Sep 27, 2018
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  4. Sync with 2.17.2

    gitster committed Sep 27, 2018
    * maint-2.17:
      Git 2.17.2
      fsck: detect submodule paths starting with dash
      fsck: detect submodule urls starting with dash
      Git 2.16.5
      Git 2.15.3
      Git 2.14.5
      submodule-config: ban submodule paths that start with a dash
      submodule-config: ban submodule urls that start with dash
      submodule--helper: use "--" to signal end of clone options
  5. Git 2.17.2

    gitster committed Sep 27, 2018
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  6. fsck: detect submodule paths starting with dash

    peff authored and gitster committed Sep 24, 2018
    As with urls, submodule paths with dashes are ignored by
    git, but may end up confusing older versions. Detecting them
    via fsck lets us prevent modern versions of git from being a
    vector to spread broken .gitmodules to older versions.
    
    Compared to blocking leading-dash urls, though, this
    detection may be less of a good idea:
    
      1. While such paths provide confusing and broken results,
         they don't seem to actually work as option injections
         against anything except "cd". In particular, the
         submodule code seems to canonicalize to an absolute
         path before running "git clone" (so it passes
         /your/clone/-sub).
    
      2. It's more likely that we may one day make such names
         actually work correctly. Even after we revert this fsck
         check, it will continue to be a hassle until hosting
         servers are all updated.
    
    On the other hand, it's not entirely clear that the behavior
    in older versions is safe. And if we do want to eventually
    allow this, we may end up doing so with a special syntax
    anyway (e.g., writing "./-sub" in the .gitmodules file, and
    teaching the submodule code to canonicalize it when
    comparing).
    
    So on balance, this is probably a good protection.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  7. fsck: detect submodule urls starting with dash

    peff authored and gitster committed Sep 24, 2018
    Urls with leading dashes can cause mischief on older
    versions of Git. We should detect them so that they can be
    rejected by receive.fsckObjects, preventing modern versions
    of git from being a vector by which attacks can spread.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  8. Sync with 2.16.5

    gitster committed Sep 27, 2018
    * maint-2.16:
      Git 2.16.5
      Git 2.15.3
      Git 2.14.5
      submodule-config: ban submodule paths that start with a dash
      submodule-config: ban submodule urls that start with dash
      submodule--helper: use "--" to signal end of clone options
  9. Git 2.16.5

    gitster committed Sep 27, 2018
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  10. Sync with 2.15.3

    gitster committed Sep 27, 2018
    * maint-2.15:
      Git 2.15.3
      Git 2.14.5
      submodule-config: ban submodule paths that start with a dash
      submodule-config: ban submodule urls that start with dash
      submodule--helper: use "--" to signal end of clone options
  11. Git 2.15.3

    gitster committed Sep 27, 2018
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  12. Sync with Git 2.14.4

    gitster committed Sep 27, 2018
    * maint-2.14:
      Git 2.14.5
      submodule-config: ban submodule paths that start with a dash
      submodule-config: ban submodule urls that start with dash
      submodule--helper: use "--" to signal end of clone options
  13. Git 2.14.5

    gitster committed Sep 27, 2018
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  14. submodule-config: ban submodule paths that start with a dash

    peff authored and gitster committed Sep 24, 2018
    We recently banned submodule urls that look like
    command-line options. This is the matching change to ban
    leading-dash paths.
    
    As with the urls, this should not break any use cases that
    currently work. Even with our "--" separator passed to
    git-clone, git-submodule.sh gets confused. Without the code
    portion of this patch, the clone of "-sub" added in t7417
    would yield results like:
    
        /path/to/git-submodule: 410: cd: Illegal option -s
        /path/to/git-submodule: 417: cd: Illegal option -s
        /path/to/git-submodule: 410: cd: Illegal option -s
        /path/to/git-submodule: 417: cd: Illegal option -s
        Fetched in submodule path '-sub', but it did not contain b56243f8f4eb91b2f1f8109452e659f14dd3fbe4. Direct fetching of that commit failed.
    
    Moreover, naively adding such a submodule doesn't work:
    
      $ git submodule add $url -sub
      The following path is ignored by one of your .gitignore files:
      -sub
    
    even though there is no such ignore pattern (the test script
    hacks around this with a well-placed "git mv").
    
    Unlike leading-dash urls, though, it's possible that such a
    path _could_ be useful if we eventually made it work. So
    this commit should be seen not as recommending a particular
    policy, but rather temporarily closing off a broken and
    possibly dangerous code-path. We may revisit this decision
    later.
    
    There are two minor differences to the tests in t7416 (that
    covered urls):
    
      1. We don't have a "./-sub" escape hatch to make this
         work, since the submodule code expects to be able to
         match canonical index names to the path field (so you
         are free to add submodule config with that path, but we
         would never actually use it, since an index entry would
         never start with "./").
    
      2. After this patch, cloning actually succeeds. Since we
         ignore the submodule.*.path value, we fail to find a
         config stanza for our submodule at all, and simply
         treat it as inactive. We still check for the "ignoring"
         message.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  15. submodule-config: ban submodule urls that start with dash

    peff authored and gitster committed Sep 24, 2018
    The previous commit taught the submodule code to invoke our
    "git clone $url $path" with a "--" separator so that we
    aren't confused by urls or paths that start with dashes.
    
    However, that's just one code path. It's not clear if there
    are others, and it would be an easy mistake to add one in
    the future. Moreover, even with the fix in the previous
    commit, it's quite hard to actually do anything useful with
    such an entry. Any url starting with a dash must fall into
    one of three categories:
    
     - it's meant as a file url, like "-path". But then any
       clone is not going to have the matching path, since it's
       by definition relative inside the newly created clone. If
       you spell it as "./-path", the submodule code sees the
       "/" and translates this to an absolute path, so it at
       least works (assuming the receiver has the same
       filesystem layout as you). But that trick does not apply
       for a bare "-path".
    
     - it's meant as an ssh url, like "-host:path". But this
       already doesn't work, as we explicitly disallow ssh
       hostnames that begin with a dash (to avoid option
       injection against ssh).
    
     - it's a remote-helper scheme, like "-scheme::data". This
       _could_ work if the receiver bends over backwards and
       creates a funny-named helper like "git-remote--scheme".
       But normally there would not be any helper that matches.
    
    Since such a url does not work today and is not likely to do
    anything useful in the future, let's simply disallow them
    entirely. That protects the existing "git clone" path (in a
    belt-and-suspenders way), along with any others that might
    exist.
    
    Our tests cover two cases:
    
      1. A file url with "./" continues to work, showing that
         there's an escape hatch for people with truly silly
         repo names.
    
      2. A url starting with "-" is rejected.
    
    Note that we expect case (2) to fail, but it would have done
    so even without this commit, for the reasons given above.
    So instead of just expecting failure, let's also check for
    the magic word "ignoring" on stderr. That lets us know that
    we failed for the right reason.
    
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  16. submodule--helper: use "--" to signal end of clone options

    peff authored and gitster committed Sep 24, 2018
    When we clone a submodule, we call "git clone $url $path".
    But there's nothing to say that those components can't begin
    with a dash themselves, confusing git-clone into thinking
    they're options. Let's pass "--" to make it clear what we
    expect.
    
    There's no test here, because it's actually quite hard to
    make these names work, even with "git clone" parsing them
    correctly. And we're going to restrict these cases even
    further in future commits. So we'll leave off testing until
    then; this is just the minimal fix to prevent us from doing
    something stupid with a badly formed entry.
    
    Reported-by: joernchen <joernchen@phenoelit.de>
    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Sep 10, 2018
  1. Git 2.19

    gitster committed Sep 10, 2018
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  2. Merge tag 'l10n-2.19.0-rnd2' of git://github.com/git-l10n/git-po

    gitster committed Sep 10, 2018
    l10n for Git 2.19.0 round 2
    
    * tag 'l10n-2.19.0-rnd2' of git://github.com/git-l10n/git-po:
      l10n: zh_CN: for git v2.19.0 l10n round 1 to 2
      l10n: bg.po: Updated Bulgarian translation (3958t)
      l10n: vi.po(3958t): updated Vietnamese translation v2.19.0 round 2
      l10n: es.po v2.19.0 round 2
      l10n: fr.po v2.19.0 rnd 2
      l10n: fr.po v2.19.0 rnd 1
      l10n: fr: fix a message seen in git bisect
      l10n: sv.po: Update Swedish translation (3958t0f0u)
      l10n: git.pot: v2.19.0 round 2 (3 new, 5 removed)
      l10n: ru.po: update Russian translation
      l10n: git.pot: v2.19.0 round 1 (382 new, 30 removed)
      l10n: de.po: translate 108 new messages
      l10n: zh_CN: review for git 2.18.0
      l10n: sv.po: Update Swedish translation(3608t0f0u)
  3. Merge branch 'jn/submodule-core-worktree-revert'

    gitster committed Sep 10, 2018
    * jn/submodule-core-worktree-revert:
      Revert "Merge branch 'sb/submodule-core-worktree'"
  4. Merge branch 'mk/http-backend-content-length'

    gitster committed Sep 10, 2018
    The earlier attempt barfed when given a CONTENT_LENGTH that is
    set to an empty string.  RFC 3875 is fairly clear that in this
    case we should not read any message body, but we've been reading
    through to the EOF in previous versions (which did not even pay
    attention to the environment variable), so keep that behaviour for
    now in this late update.
    
    * mk/http-backend-content-length:
      http-backend: allow empty CONTENT_LENGTH
Commits on Sep 9, 2018
  1. l10n: zh_CN: for git v2.19.0 l10n round 1 to 2

    jiangxin committed Aug 21, 2018
    Translate 382 new messages (3958t0f0u) for git 2.19.0.
    
    Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
  2. Merge branch 'master' of git://github.com/alshopov/git-po

    jiangxin committed Sep 9, 2018
    * 'master' of git://github.com/alshopov/git-po:
      l10n: bg.po: Updated Bulgarian translation (3958t)
  3. l10n: bg.po: Updated Bulgarian translation (3958t)

    alshopov committed Aug 9, 2018
    Signed-off-by: Alexander Shopov <ash@kambanaria.org>
Commits on Sep 8, 2018
  1. Revert "Merge branch 'sb/submodule-core-worktree'"

    jrn authored and gitster committed Sep 8, 2018
    This reverts commit 7e25437, reversing
    changes made to 00624d6.
    
    v2.19.0-rc0~165^2~1 (submodule: ensure core.worktree is set after
    update, 2018-06-18) assumes an "absorbed" submodule layout, where the
    submodule's Git directory is in the superproject's .git/modules/
    directory and .git in the submodule worktree is a .git file pointing
    there.  In particular, it uses $GIT_DIR/modules/$name to find the
    submodule to find out whether it already has core.worktree set, and it
    uses connect_work_tree_and_git_dir if not, resulting in
    
    	fatal: could not open sub/.git for writing
    
    The context behind that patch: v2.19.0-rc0~165^2~2 (submodule: unset
    core.worktree if no working tree is present, 2018-06-12) unsets
    core.worktree when running commands like "git checkout
    --recurse-submodules" to switch to a branch without the submodule.  If
    a user then uses "git checkout --no-recurse-submodules" to switch back
    to a branch with the submodule and runs "git submodule update", this
    patch is needed to ensure that commands using the submodule directly
    are aware of the path to the worktree.
    
    It is late in the release cycle, so revert the whole 3-patch series.
    We can try again later for 2.20.
    
    Reported-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
    Helped-by: Stefan Beller <sbeller@google.com>
    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Sep 7, 2018
  1. http-backend: allow empty CONTENT_LENGTH

    max630 authored and gitster committed Sep 7, 2018
    According to RFC3875, empty environment variable is equivalent to unset,
    and for CONTENT_LENGTH it should mean zero body to read.
    
    However, unset CONTENT_LENGTH is also used for chunked encoding to indicate
    reading until EOF. At least, the test "large fetch-pack requests can be split
    across POSTs" from t5551 starts faliing, if unset or empty CONTENT_LENGTH is
    treated as zero length body. So keep the existing behavior as much as possible.
    
    Add a test for the case.
    
    Reported-By: Jelmer Vernooij <jelmer@jelmer.uk>
    Signed-off-by: Max Kirillov <max@max630.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  2. l10n: vi.po(3958t): updated Vietnamese translation v2.19.0 round 2

    vnwildman committed Sep 7, 2018
    Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
Commits on Sep 6, 2018
  1. l10n: es.po v2.19.0 round 2

    ChrisADR committed Sep 6, 2018
    Signed-off-by: Christopher Diaz Riveros <chrisadr@gentoo.org>
  2. Merge branch 'fr_2.19.0_rnd1' of git://github.com/jnavila/git

    jiangxin committed Sep 6, 2018
    * 'fr_2.19.0_rnd1' of git://github.com/jnavila/git:
      l10n: fr.po v2.19.0 rnd 2
      l10n: fr.po v2.19.0 rnd 1
      l10n: fr: fix a message seen in git bisect
Commits on Sep 5, 2018
  1. l10n: fr.po v2.19.0 rnd 2

    jnavila committed Sep 5, 2018
    Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
  2. l10n: fr.po v2.19.0 rnd 1

    jnavila committed Aug 23, 2018
    Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
  3. l10n: fr: fix a message seen in git bisect

    rhertzog authored and jnavila committed Jul 4, 2018
    "cette" can be only be used before a word (like in "cette bouteille" for
    "this bottle"), but here "this" refers to the current step and we have
    to use "ceci" in French.
    
    Signed-off-by: Raphaël Hertzog <hertzog@debian.org>
Commits on Sep 4, 2018
  1. l10n: sv.po: Update Swedish translation (3958t0f0u)

    nafmo committed Sep 4, 2018
    Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
  2. Git 2.19-rc2

    gitster committed Sep 4, 2018
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  3. Merge branch 'es/chain-lint-more'

    gitster committed Sep 4, 2018
    The test linter code has learned that the end of here-doc mark
    "EOF" can be quoted in a double-quote pair, not just in a
    single-quote pair.
    
    * es/chain-lint-more:
      chainlint: match "quoted" here-doc tags
  4. Merge branch 'ab/portable-more'

    gitster committed Sep 4, 2018
    Portability fix.
    
    * ab/portable-more:
      tests: fix non-portable iconv invocation
      tests: fix non-portable "${var:-"str"}" construct
      tests: fix and add lint for non-portable grep --file
      tests: fix version-specific portability issue in Perl JSON
      tests: use shorter labels in chainlint.sed for AIX sed
      tests: fix comment syntax in chainlint.sed for AIX sed
      tests: fix and add lint for non-portable seq
      tests: fix and add lint for non-portable head -c N