1. 10 Apr, 2019 1 commit
  2. 04 Apr, 2019 2 commits
  3. 21 Mar, 2019 1 commit
  4. 12 Mar, 2019 1 commit
  5. 20 Feb, 2019 1 commit
  6. 06 Feb, 2019 1 commit
  7. 28 Jan, 2019 1 commit
    • Gábor Szeder's avatar
      strbuf.cocci: suggest strbuf_addbuf() to add one strbuf to an other · 28c23cd4
      Gábor Szeder authored
      The best way to add one strbuf to an other is via:
        strbuf_addbuf(&sb, &sb2);
      This is a bit more idiomatic and efficient than:
        strbuf_addstr(&sb, sb2.buf);
      because the size of the second strbuf is known and thus it can spare a
      strlen() call, and much more so than:
        strbuf_addf(&sb, "%s", sb2.buf);
      because it can spare the whole vsnprintf() formatting magic.
      Add new semantic patches to 'contrib/coccinelle/strbuf.cocci' to catch
      these undesired patterns and to suggest strbuf_addbuf() instead.
      Luckily, our codebase is already clean from any such undesired
      patterns (but one of the in-flight topics just tried to sneak in such
      a strbuf_addf() call).
      Signed-off-by: Gábor Szeder's avatarSZEDER Gábor <szeder.dev@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  8. 15 Jan, 2019 1 commit
    • brian m. carlson's avatar
      cache: make oidcpy always copy GIT_MAX_RAWSZ bytes · 974e4a85
      brian m. carlson authored
      There are some situations in which we want to store an object ID into
      struct object_id without the_hash_algo necessarily being set correctly.
      One such case is when cloning a repository, where we must read refs from
      the remote side without having a repository from which to read the
      preferred algorithm.
      In this cases, we may have the_hash_algo set to SHA-1, which is the
      default, but read refs into struct object_id that are SHA-256. When
      copying these values, we will want to copy them completely, not just the
      first 20 bytes. Consequently, make sure that oidcpy copies the maximum
      number of bytes at all times, regardless of the setting of
      Since oidcpy and hashcpy are no longer functionally identical, remove
      the Cocinelle object_id transformations that convert from one into the
      Signed-off-by: brian m. carlson's avatarbrian m. carlson <sandals@crustytoothpaste.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  9. 08 Jan, 2019 2 commits
    • Jeff King's avatar
      sha1-file: drop has_sha1_file() · 5d3679ee
      Jeff King authored
      There are no callers left of has_sha1_file() or its with_flags()
      variant. Let's drop them, and convert has_object_file() from a wrapper
      into the "real" function. Ironically, the sha1 variant was just copying
      into an object_id internally, so the resulting code is actually shorter!
      We can also drop the coccinelle rules for catching has_sha1_file()
      callers. Since the function no longer exists, the compiler will do that
      for us.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      convert has_sha1_file() callers to has_object_file() · 98374a07
      Jeff King authored
      The only remaining callers of has_sha1_file() actually have an object_id
      already. They can use the "object" variant, rather than dereferencing
      the hash themselves.
      The code changes here were completely generated by the included
      coccinelle patch.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  10. 07 Jan, 2019 1 commit
  11. 03 Jan, 2019 3 commits
    • Chayoung You's avatar
    • Chayoung You's avatar
      completion: treat results of git ls-tree as file paths · 6d54f528
      Chayoung You authored
      Let's say there are files named 'foo bar.txt', and 'abc def/test.txt' in
      repository. When following commands trigger a completion:
          git show HEAD:fo<Tab>
          git show HEAD:ab<Tab>
      The completion results in bash/zsh:
          git show HEAD:foo bar.txt
          git show HEAD:abc def/
      Where the both of them have an unescaped space in paths, so they'll be
      misread by git. All entries of git ls-tree either a filename or a
      directory, so __gitcomp_file() is proper rather than __gitcomp_nl().
      Note the commit f12785a3, which handles quoted paths properly. Like this
      case, we should dequote $cur_ for ?*:* case. For example, let's say
      there is untracked directory 'abc deg', then trigger a completion:
          git show HEAD:abc\ de<Tab>
          git show HEAD:'abc de<Tab>
          git show HEAD:"abc de<Tab>
      should uniquely complete 'abc def', but bash completes 'abc def' and
      'abc deg' instead. In zsh, triggering a completion:
          git show HEAD:abc\ def/<Tab>
      should complete 'test.txt', but nothing comes. The both problems will be
      resolved by dequoting paths.
      __git_complete_revlist_file() passes arguments to __gitcomp_nl() where
      the first one is a list something like:
          abc def/Z
          foo bar.txt Z
      where Z is the mark of the EOL.
      - The trailing space of blob in __git ls-tree | sed.
        It makes the completion results become:
            git show HEAD:foo\ bar.txt\ <CURSOR>
        So git will try to find a file named 'foo bar.txt ' instead.
      - The trailing slash of tree in __git ls-tree | sed.
        It makes the completion results on zsh become:
            git show HEAD:abc\ def/ <CURSOR>
        So that the last space on command like should be removed on zsh to
        complete filenames under 'abc def/'.
      Signed-off-by: Chayoung You's avatarChayoung You <yousbe@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
    • Chayoung You's avatar
      zsh: complete unquoted paths with spaces correctly · 7a478b36
      Chayoung You authored
      The following is the description of -Q flag of zsh compadd [1]:
          This flag instructs the completion code not to quote any
          metacharacters in the words when inserting them into the command
      Let's say there is a file named 'foo bar.txt' in repository, but it's
      not yet added to the repository. Then the following command triggers a
          git add fo<Tab>
          git add 'fo<Tab>
          git add "fo<Tab>
      The completion results in bash:
          git add foo\ bar.txt
          git add 'foo bar.txt'
          git add "foo bar.txt"
      While them in zsh:
          git add foo bar.txt
          git add 'foo bar.txt'
          git add "foo bar.txt"
      The first one, where the pathname is not enclosed in quotes, should
      escape the space with a backslash, just like bash completion does.
      Otherwise, this leads git to think there are two files; foo, and
      The main cause of this behavior is __gitcomp_file_direct(). The both
      implementions of bash and zsh are called with an argument 'foo bar.txt',
      but only bash adds a backslash before a space on command line.
      [1]: http://zsh.sourceforge.net/Doc/Release/Completion-Widgets.htmlSigned-off-by: Chayoung You's avatarChayoung You <yousbe@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  12. 14 Nov, 2018 10 commits
  13. 06 Nov, 2018 1 commit
    • Duy Nguyen's avatar
      completion: use __gitcomp_builtin for format-patch · 13374987
      Duy Nguyen authored
      This helps format-patch gain completion for a couple new options,
      notably --range-diff.
      Since send-email completion relies on $__git_format_patch_options
      which is now reduced, we need to do something not to regress
      send-email completion.
      The workaround here is implement --git-completion-helper in
      send-email.perl just as a bridge to "format-patch --git-completion-helper".
      This is enough to use __gitcomp_builtin on send-email (to take
      advantage of caching).
      In the end, send-email.perl can probably reuse the same info it passes
      to GetOptions() to generate full --git-completion-helper output so
      that we don't need to keep track of its options in git-completion.bash
      anymore. But that's something for another boring day.
      Helped-by: Denton Liu's avatarDenton Liu <liu.denton@gmail.com>
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  14. 25 Oct, 2018 1 commit
  15. 24 Oct, 2018 2 commits
    • Johannes Schindelin's avatar
      mingw: load system libraries the recommended way · c6f050a4
      Johannes Schindelin authored
      When we access IPv6-related functions, we load the corresponding system
      library using the `LoadLibrary()` function, which is not the recommended
      way to load system libraries.
      In practice, it does not make a difference: the `ws2_32.dll` library
      containing the IPv6 functions is already loaded into memory, so
      LoadLibrary() simply reuses the already-loaded library.
      Still, recommended way is recommended way, so let's use that instead.
      While at it, also adjust the code in contrib/ that loads system libraries.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
    • Junio C Hamano's avatar
      cocci: simplify "if (++u > 1)" to "if (u++)" · 05b4ed61
      Junio C Hamano authored
      It is more common to use post-increment than pre-increment when the
      side effect is the primary thing we want in our code and in C in
      general (unlike C++).
      Initializing a variable to 0, incrementing it every time we do
      something, and checking if we have already done that thing to guard
      the code to do that thing, is easier to understand when written
      	if (u++)
      		; /* we've done that! */
      		do_it(); /* just once. */
      but if you try to use pre-increment, you end up with a less natural
      	if (++u > 1)
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  16. 22 Oct, 2018 1 commit
    • Duy Nguyen's avatar
      completion: fix __gitcomp_builtin no longer consider extra options · 276b49ff
      Duy Nguyen authored
      __gitcomp_builtin() has the main completion list provided by
          git xxx --git-completion-helper
      but the caller can also add extra options that is not provided by
      --git-completion-helper. The only call site that does this is "git
      difftool" completion.
      This support is broken by b221b5ab (completion: collapse extra
      --no-.. options - 2018-06-06), which adds a special value "--" to mark
      that the rest of the options can be hidden by default. The commit
      forgets the fact that extra options are appended after
      "$(git xxx --git-completion-helper)", i.e. after this "--", and will
      be incorrectly hidden as well.
      Prepend the extra options before "$(git xxx --git-completion-helper)"
      to avoid this.
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  17. 18 Oct, 2018 1 commit
  18. 16 Oct, 2018 1 commit
  19. 15 Oct, 2018 1 commit
  20. 12 Oct, 2018 1 commit
  21. 11 Oct, 2018 1 commit
  22. 10 Oct, 2018 2 commits
    • Christian Hesse's avatar
      subtree: add build targets 'man' and 'html' · 0f952b26
      Christian Hesse authored
      We have targets 'install-man' and 'install-html', let's add build
      targets as well.
      Signed-off-by: Christian Hesse's avatarChristian Hesse <mail@eworm.de>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
    • Derrick Stolee's avatar
      contrib: add coverage-diff script · 783faedd
      Derrick Stolee authored
      We have coverage targets in our Makefile for using gcov to display line
      coverage based on our test suite. The way I like to do it is to run:
          make coverage-test
          make coverage-report
      This leaves the repo in a state where every X.c file that was covered has
      an X.c.gcov file containing the coverage counts for every line, and "#####"
      at every uncovered line.
      There have been a few bugs in recent patches what would have been caught
      if the test suite covered those blocks (including a few of mine). I want
      to work towards a "sensible" amount of coverage on new topics. In my opinion,
      this means that any logic should be covered, but the 'die()' blocks covering
      very unlikely (or near-impossible) situations may not warrant coverage.
      It is important to not measure the coverage of the codebase by what old code
      is not covered. To help, I created the 'contrib/coverage-diff.sh' script.
      After creating the coverage statistics at a version (say, 'topic') you can
      then run
          contrib/coverage-diff.sh base topic
      to see the lines added between 'base' and 'topic' that are not covered by the
      test suite. The output uses 'git blame -s' format so you can find the commits
      responsible and view the line numbers for quick access to the context, but
      trims leading tabs in the file contents to reduce output width.
      Signed-off-by: 's avatarDerrick Stolee <dstolee@microsoft.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  23. 07 Oct, 2018 1 commit
  24. 06 Oct, 2018 2 commits
    • Strain, Roger L's avatar
      subtree: improve decision on merges kept in split · 68f8ff81
      Strain, Roger L authored
      When multiple identical parents are detected for a commit being considered
      for copying, explicitly check whether one is the common merge base between
      the commits. If so, the other commit can be used as the identical parent;
      if not, a merge must be performed to maintain history.
      In some situations two parents of a merge commit may appear to both have
      identical subtree content with each other and the current commit. However,
      those parents can potentially come from different commit graphs.
      Previous behavior would simply select one of the identical parents to
      serve as the replacement for this commit, based on the order in which they
      were processed.
      New behavior compares the merge base between the commits to determine if
      a new merge commit is necessary to maintain history despite the identical
      Signed-off-by: 's avatarStrain, Roger L <roger.strain@swri.org>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
    • Strain, Roger L's avatar
      subtree: use commits before rejoins for splits · 315a84f9
      Strain, Roger L authored
      Adds recursive evaluation of parent commits which were not part of the
      initial commit list when performing a split.
      Split expects all relevant commits to be reachable from the target commit
      but not reachable from any previous rejoins. However, a branch could be
      based on a commit prior to a rejoin, then later merged back into the
      current code. In this case, a parent to the commit will not be present in
      the initial list of commits, trigging an "incorrect order" warning.
      Previous behavior was to consider that commit to have no parent, creating
      an original commit containing all subtree content. This commit is not
      present in an existing subtree commit graph, changing commit hashes and
      making pushing to a subtree repo impossible.
      New behavior will recursively check these unexpected parent commits to
      track them back to either an earlier rejoin, or a true original commit.
      The generated synthetic commits will properly match previously-generated
      commits, allowing successful pushing to a prior subtree repo.
      Signed-off-by: 's avatarStrain, Roger L <roger.strain@swri.org>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>