Permalink
Commits on Aug 19, 2016
  1. Git 2.10-rc1

    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    committed Aug 19, 2016
  2. Merge branch 'lt/gpg-show-long-key-in-signature-verification'

    "git log --show-signature" and other commands that display the
    verification status of PGP signature now shows the longer key-id,
    as 32-bit key-id is so last century.
    
    * lt/gpg-show-long-key-in-signature-verification:
      gpg-interface: prefer "long" key format output when verifying pgp signatures
    committed Aug 19, 2016
  3. Merge branch 'ab/hooks'

    "git rev-parse --git-path hooks/<hook>" learned to take
    core.hooksPath configuration variable (introduced during 2.9 cycle)
    into account.
    
    * ab/hooks:
      rev-parse: respect core.hooksPath in --git-path
    committed Aug 19, 2016
  4. Merge branch 'jk/difftool-command-not-found'

    "git difftool" by default ignores the error exit from the backend
    commands it spawns, because often they signal that they found
    differences by exiting with a non-zero status code just like "diff"
    does; the exit status codes 126 and above however are special in
    that they are used to signal that the command is not executable,
    does not exist, or killed by a signal.  "git difftool" has been
    taught to notice these exit status codes.
    
    * jk/difftool-command-not-found:
      difftool: always honor fatal error exit codes
    committed Aug 19, 2016
  5. Merge branch 'sb/checkout-explit-detach-no-advice'

    "git checkout --detach <branch>" used to give the same advice
    message as that is issued when "git checkout <tag>" (or anything
    that is not a branch name) is given, but asking with "--detach" is
    an explicit enough sign that the user knows what is going on.  The
    advice message has been squelched in this case.
    
    * sb/checkout-explit-detach-no-advice:
      checkout: do not mention detach advice for explicit --detach option
    committed Aug 19, 2016
  6. Merge branch 'tb/t0027-raciness-fix'

    The t0027 test for CRLF conversion was timing dependent and flaky.
    
    * tb/t0027-raciness-fix:
      convert: Correct NNO tests and missing `LF will be replaced by CRLF`
    committed Aug 19, 2016
  7. Merge branch 'rs/pull-signed-tag'

    When "git merge-recursive" works on history with many criss-cross
    merges in "verbose" mode, the names the command assigns to the
    virtual merge bases could have overwritten each other by unintended
    reuse of the same piece of memory.
    
    * rs/pull-signed-tag:
      commit: use FLEX_ARRAY in struct merge_remote_desc
      merge-recursive: fix verbose output for multiple base trees
      commit: factor out set_merge_remote_desc()
      commit: use xstrdup() in get_merge_parent()
    committed Aug 19, 2016
Commits on Aug 17, 2016
  1. Merge branch 'js/test-lint-pathname'

    The "t/" hierarchy is prone to get an unusual pathname; "make test"
    has been taught to make sure they do not contain paths that cannot
    be checked out on Windows (and the mechanism can be reusable to
    catch pathnames that are not portable to other platforms as need
    arises).
    
    * js/test-lint-pathname:
      t/Makefile: ensure that paths are valid on platforms we care
    committed Aug 17, 2016
  2. Merge branch 'sg/reflog-past-root'

    A small test clean-up for a topic introduced in v2.9.1 and later.
    
    * sg/reflog-past-root:
      t1410: remove superfluous 'git reflog' from the 'walk past root' test
    committed Aug 17, 2016
  3. Merge branch 'rs/mailinfo-lib'

    Small code clean-up.
    
    * rs/mailinfo-lib:
      mailinfo: recycle strbuf in check_header()
    committed Aug 17, 2016
  4. Merge branch 'jk/tighten-alloc'

    Small code and comment clean-up.
    
    * jk/tighten-alloc:
      receive-pack: use FLEX_ALLOC_MEM in queue_command()
      correct FLEXPTR_* example in comment
    committed Aug 17, 2016
  5. Merge branch 'va/i18n'

    A handful of tests that were broken under gettext-poison build have
    been fixed.
    
    * va/i18n:
      t7411: become resilient to GETTEXT_POISON
      t5520: become resilient to GETTEXT_POISON
      t3404: become resilient to GETTEXT_POISON
    committed Aug 17, 2016
  6. @moy

    git-multimail: update to release 1.4.0

    Changes are described in CHANGES.
    
    Contributions-by: Matthieu Moy <Matthieu.Moy@imag.fr>
    Contributions-by: Irfan Adilovic <irfanadilovic@gmail.com>
    Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    moy committed with Aug 17, 2016
  7. relnotes: redo the description of text=auto fix

    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    committed Aug 17, 2016
Commits on Aug 16, 2016
  1. Merge branch 'lt/gpg-show-long-key-in-signature-verification-maint' i…

    …nto lt/gpg-show-long-key-in-signature-verification
    
    Linus's original was rebased to apply to the maintenance track just
    in case binary distributors that are stuck in the past want to take
    it to their older codebase.  Let's merge it up to more modern
    codebase that has Peff's gpg-interface clean-up topic that appeared
    after Git 2.9 was tagged.
    
    * lt/gpg-show-long-key-in-signature-verification-maint:
      gpg-interface: prefer "long" key format output when verifying pgp signatures
    committed Aug 16, 2016
  2. @torvalds

    gpg-interface: prefer "long" key format output when verifying pgp sig…

    …natures
    
    Yes, gpg2 already uses the long format by default, but most
    distributions seem to still have "gpg" be the older 1.x version due to
    compatibility reasons.  And older versions of gpg only show the 32-bit
    short ID, which is quite insecure.
    
    This doesn't actually matter for the _verification_ itself: if the
    verification passes, the pgp signature is good.  But if you don't
    actually have the key yet, and want to fetch it, or you want to check
    exactly which key was used for verification and want to check it, we
    should specify the key with more precision.
    
    In fact, we should preferentially specify the whole key fingerprint, but
    gpg doesn't actually support that.  Which is really quite sad.
    
    Showing the "long" format improves things to at least show 64 bits of
    the fingerprint.  That's a lot better, even if it's not perfect.
    
    This change the log format for "git log --show-signature" from
    
        commit 2376d31
        merged tag 'v2.9.3'
        gpg: Signature made Fri 12 Aug 2016 09:17:59 AM PDT using RSA key ID 96AFE6CB
        gpg: Good signature from "Junio C Hamano <gitster@pobox.com>"
        gpg:                 aka "Junio C Hamano <jch@google.com>"
        gpg:                 aka "Junio C Hamano <junio@pobox.com>"
        Merge: 2807cd7 e0c1cea
        Author: Junio C Hamano <gitster@pobox.com>
        Date:   Fri Aug 12 10:02:18 2016 -0700
    
    to
    
        commit 2376d31
        merged tag 'v2.9.3'
        gpg: Signature made Fri 12 Aug 2016 09:17:59 AM PDT
        gpg:                using RSA key B0B5E88696AFE6CB
        gpg: Good signature from "Junio C Hamano <gitster@pobox.com>"
        gpg:                 aka "Junio C Hamano <jch@google.com>"
        gpg:                 aka "Junio C Hamano <junio@pobox.com>"
        Merge: 2807cd7 e0c1cea
        Author: Junio C Hamano <gitster@pobox.com>
        Date:   Fri Aug 12 10:02:18 2016 -0700
    
    (note the longer key ID, but also the reflowing of the text) and also
    changes the format in the merge messages when merging a signed
    tag.
    
    If you already use gpg2 (either because it's installed by default, or
    because you have set your gpg_program configuration to point to gpg2),
    that already used the long format, you'll also see a change: it will now
    have the same formatting as gpg 1.x, and the verification string looks
    something like
    
        gpg: Signature made Sun 24 Jul 2016 12:24:02 PM PDT
        gpg:                using RSA key 79BE3E4300411886
        gpg: Good signature from "Linus Torvalds <torvalds@linux-foundation.org>" [ultimate]
    
    where it used to be on one line:
    
        gpg: Signature made Sun 24 Jul 2016 12:24:02 PM PDT using RSA key ID 79BE3E4300411886
        gpg: Good signature from "Linus Torvalds <torvalds@linux-foundation.org>" [ultimate]
    
    so there is certainly a chance this could break some automated scripting.
    But the 32-bit key ID's really are broken. Also note that because of the
    differences between gpg-1.x and gpg-2.x, hopefully any scripted key ID
    parsing code (if such code exists) is already flexible enough to not care.
    
    This was triggered by the fact that the "evil32" project keys ended up
    leaking to the public key servers, so now there are 32-bit aliases for
    just about every open source developer that you can easily get by
    mistake if you use the 32-bit short ID format.
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    torvalds committed with Aug 16, 2016
  3. @dscho

    rev-parse: respect core.hooksPath in --git-path

    The idea of the --git-path option is not only to avoid having to
    prefix paths with the output of --git-dir all the time, but also to
    respect overrides for specific common paths inside the .git directory
    (e.g. `git rev-parse --git-path objects` will report the value of the
    environment variable GIT_OBJECT_DIRECTORY, if set).
    
    When introducing the core.hooksPath setting, we forgot to adjust
    git_path() accordingly. This patch fixes that.
    
    While at it, revert the special-casing of core.hooksPath in
    run-command.c, as it is now no longer needed.
    
    Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    dscho committed with Aug 16, 2016
  4. @dscho

    t/Makefile: ensure that paths are valid on platforms we care

    Some pathnames that are okay on ext4 and on HFS+ cannot be checked
    out on Windows. Tests that want to see operations on such paths on
    filesystems that support them must do so behind appropriate test
    prerequisites, and must not include them in the source tree (instead
    they should create them when they run). Otherwise, the source tree
    cannot even be checked out.
    
    Make sure that double-quotes, asterisk, colon, greater/less-than,
    question-mark, backslash, tab, vertical-bar, as well as any non-ASCII
    characters never appear in the pathnames with a new test-lint-* target
    as part of a `make test`. To that end, we call `git ls-files` (ensuring
    that the paths are quoted properly), relying on the fact that paths
    containing non-ASCII characters are quoted within double-quotes.
    
    In case that the source code does not actually live in a Git
    repository (e.g. when extracted from a .zip file), or that the `git`
    executable cannot be executed, we simply ignore the error for now; In
    that case, our trusty Continuous Integration will be the last line of
    defense and catch any problematic file name.
    
    Noticed when a topic wanted to add a pathname with '>' in it.  A
    check like this will prevent a similar problems from happening in the
    future.
    
    Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    dscho committed with Aug 16, 2016
Commits on Aug 15, 2016
  1. @johnkeeping

    difftool: always honor fatal error exit codes

    At the moment difftool's "trust exit code" logic always suppresses the
    exit status of the diff utility we invoke.  This is useful because we
    don't want to exit just because diff returned "1" because the files
    differ, but it's confusing if the shell returns an error because the
    selected diff utility is not found.
    
    POSIX specifies 127 as the exit status for "command not found", 126 for
    "command found but is not executable" and values greater than 128 if the
    command terminated because it received a signal [1] and at least bash
    and dash follow this specification, while diff utilities generally use
    "1" for the exit status we want to ignore.
    
    Handle any value of 126 or greater as a special value indicating that
    some form of fatal error occurred.
    
    [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_02
    
    Signed-off-by: John Keeping <john@keeping.me.uk>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    johnkeeping committed with Aug 15, 2016
  2. @stefanbeller

    checkout: do not mention detach advice for explicit --detach option

    When a user asked for a detached HEAD specifically with `--detach`,
    we do not need to give advice on what a detached HEAD state entails as
    we can assume they know what they're getting into as they asked for it.
    
    Signed-off-by: Stefan Beller <sbeller@google.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    stefanbeller committed with Aug 15, 2016
  3. Relnotes: decribe the updates to the "text=auto" attribute

    Helped-by: Torsten Bögershausen <tboegi@web.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    committed Aug 15, 2016
  4. @szeder

    t1410: remove superfluous 'git reflog' from the 'walk past root' test

    The test added in 71abeb7 (reflog: continue walking the reflog
    past root commits, 2016-06-03) contains an unnecessary 'git reflog'
    execution, which was part of my debug/tracing instrumentation that I
    somehow didn't manage to remove before submitting.
    
    Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    szeder committed with Aug 14, 2016
Commits on Aug 14, 2016
  1. Git 2.10-rc0

    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    committed Aug 14, 2016
  2. @tboegi

    convert: Correct NNO tests and missing `LF will be replaced by CRLF`

    When a non-reversible CRLF conversion is done in "git add",
    a warning is printed on stderr (or Git dies, depending on checksafe)
    
    The function commit_chk_wrnNNO() in t0027 was written to test this,
    but did the wrong thing: Instead of looking at the warning
    from "git add", it looked at the warning from "git commit".
    
    This is racy because "git commit" may not have to do CRLF conversion
    at all if it can use the sha1 value from the index (which depends on
    whether "add" and "commit" run in a single second).
    
    Correct t0027 and replace the commit for each and every file with a commit
    of all files in one go.
    The function commit_chk_wrnNNO() should be renamed in a separate commit.
    
    Now that t0027 does the right thing, it detects a bug in covert.c:
    This sequence should generate the warning `LF will be replaced by CRLF`,
    but does not:
    
    $ git init
    $ git config core.autocrlf false
    $ printf "Line\r\n" >file
    $ git add file
    $ git commit -m "commit with CRLF"
    $ git config core.autocrlf true
    $ printf "Line\n" >file
    $ git add file
    
    "git add" calls crlf_to_git() in convert.c, which calls check_safe_crlf().
    When has_cr_in_index(path) is true, crlf_to_git() returns too early and
    check_safe_crlf() is not called at all.
    
    Factor out the code which determines if "git checkout" converts LF->CRLF
    into will_convert_lf_to_crlf().
    
    Update the logic around check_safe_crlf() and "simulate" the possible
    LF->CRLF conversion at "git checkout" with help of will_convert_lf_to_crlf().
    Thanks to Jeff King <peff@peff.net> for analyzing t0027.
    
    Reported-By: Johannes Schindelin <Johannes.Schindelin@gmx.de>
    Signed-off-by: Torsten Bögershausen <tboegi@web.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    tboegi committed with Aug 13, 2016
  3. receive-pack: use FLEX_ALLOC_MEM in queue_command()

    Use the macro FLEX_ALLOC_MEM instead of open-coding it.  This shortens
    and simplifies the code a bit.
    
    Signed-off-by: Rene Scharfe <l.s.r@web.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    René Scharfe committed with Aug 13, 2016
  4. commit: use FLEX_ARRAY in struct merge_remote_desc

    Convert the name member of struct merge_remote_desc to a FLEX_ARRAY and
    use FLEX_ALLOC_STR to build the struct.  This halves the number of
    memory allocations, saves the storage for a pointer and avoids an
    indirection when reading the name.
    
    Suggested-by: Jeff King <peff@peff.net>
    Signed-off-by: Rene Scharfe <l.s.r@web.de>
    Reviewed-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    René Scharfe committed with Aug 13, 2016
  5. merge-recursive: fix verbose output for multiple base trees

    One of the indirect callers of make_virtual_commit() passes the result of
    oid_to_hex() as the name, i.e. a pointer to a static buffer.  Since the
    function uses that string pointer directly in building a struct
    merge_remote_desc, multiple entries can end up sharing the same name
    inadvertently.
    
    Fix that by calling set_merge_remote_desc(), which creates a copy of the
    string, instead of building the struct by hand.
    
    Signed-off-by: Rene Scharfe <l.s.r@web.de>
    Reviewed-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    René Scharfe committed with Aug 13, 2016
  6. commit: factor out set_merge_remote_desc()

    Export a helper function for allocating, populating and attaching a
    merge_remote_desc to a commit.
    
    Signed-off-by: Rene Scharfe <l.s.r@web.de>
    Reviewed-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    René Scharfe committed with Aug 13, 2016
  7. commit: use xstrdup() in get_merge_parent()

    Handle allocation errors for the name member just like we already do
    for the struct merge_remote_desc itself.
    
    Signed-off-by: Rene Scharfe <l.s.r@web.de>
    Reviewed-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    René Scharfe committed with Aug 13, 2016
  8. mailinfo: recycle strbuf in check_header()

    handle_message_id() duplicates the contents of the strbuf that is passed
    to it.  Its only caller proceeds to release the strbuf immediately after
    that.  Reuse it instead and make that change of object ownership more
    obvious by inlining this short function.
    
    Signed-off-by: Rene Scharfe <l.s.r@web.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    René Scharfe committed with Aug 13, 2016
  9. correct FLEXPTR_* example in comment

    This section is about "The FLEXPTR_* variants", so use FLEXPTR_ALLOC_STR
    in the example.
    
    Signed-off-by: Rene Scharfe <l.s.r@web.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    René Scharfe committed with Aug 13, 2016
Commits on Aug 12, 2016
  1. @vascool

    t7411: become resilient to GETTEXT_POISON

    The concerned test greps the error message in git_parse_source() which
    contains "bad config line %d in submodule-blob %s".
    
    Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    vascool committed with Aug 12, 2016
  2. @vascool

    t5520: become resilient to GETTEXT_POISON

    Use test_i18ngrep function instead of grep for grepping strings.
    
    Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    vascool committed with Aug 12, 2016
  3. @vascool

    t3404: become resilient to GETTEXT_POISON

    The concerned test greps the output of exit_with_patch() in
    git-rebase--interactive.sh script.
    
    Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    vascool committed with Aug 12, 2016