1. 28 Feb, 2019 2 commits
  2. 29 Jan, 2019 1 commit
  3. 06 Sep, 2018 1 commit
    • yohoho hahhahah's avatar
      builtin rebase: support --continue · f9573628
      yohoho hahhahah authored
      This commit adds the option `--continue` which is used to resume
      rebase after merge conflicts. The code tries to stay as close to
      the equivalent shell scripts found in `git-legacy-rebase.sh` as
      possible.
      
      When continuing a rebase, the state variables are read from state_dir.
      Some of the state variables are not actually stored there, such as
      `upstream`. The shell script version simply does not set them, but for
      consistency, we unset them in the builtin version.
      Signed-off-by: yohoho hahhahah's avatarPratik Karki <predatoramigo@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      f9573628
  4. 24 Jul, 2018 4 commits
  5. 16 Jul, 2018 1 commit
  6. 08 May, 2018 1 commit
  7. 06 May, 2018 1 commit
    • Johannes Schindelin's avatar
      Replace all die("BUG: ...") calls by BUG() ones · 033abf97
      Johannes Schindelin authored
      In d8193743 (usage.c: add BUG() function, 2017-05-12), a new macro
      was introduced to use for reporting bugs instead of die(). It was then
      subsequently used to convert one single caller in 588a538a
      (setup_git_env: convert die("BUG") to BUG(), 2017-05-12).
      
      The cover letter of the patch series containing this patch
      (cf 20170513032414.mfrwabt4hovujde2@sigill.intra.peff.net) is not
      terribly clear why only one call site was converted, or what the plan
      is for other, similar calls to die() to report bugs.
      
      Let's just convert all remaining ones in one fell swoop.
      
      This trick was performed by this invocation:
      
      	sed -i 's/die("BUG: /BUG("/g' $(git grep -l 'die("BUG' \*.c)
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      033abf97
  8. 11 Apr, 2018 1 commit
  9. 14 Mar, 2018 2 commits
  10. 09 Mar, 2018 1 commit
  11. 23 Feb, 2018 1 commit
  12. 15 Feb, 2018 2 commits
  13. 14 Feb, 2018 1 commit
  14. 12 Feb, 2018 1 commit
  15. 22 Dec, 2017 1 commit
  16. 12 Dec, 2017 1 commit
    • Christian Couder's avatar
      git-compat-util: introduce skip_to_optional_arg() · afaef55e
      Christian Couder authored
      We often accept both a "--key" option and a "--key=<val>" option.
      
      These options currently are parsed using something like:
      
      if (!strcmp(arg, "--key")) {
      	/* do something */
      } else if (skip_prefix(arg, "--key=", &arg)) {
      	/* do something with arg */
      }
      
      which is a bit cumbersome compared to just:
      
      if (skip_to_optional_arg(arg, "--key", &arg)) {
      	/* do something with arg */
      }
      
      This also introduces skip_to_optional_arg_default() for the few
      cases where something different should be done when the first
      argument is exactly "--key" than when it is exactly "--key=".
      
      In general it is better for UI consistency and simplicity if
      "--key" and "--key=" do the same thing though, so that using
      skip_to_optional_arg() should be encouraged compared to
      skip_to_optional_arg_default().
      
      Note that these functions can be used to parse any "key=value"
      string where "key" is also considered as valid, not just
      command line options.
      Signed-off-by: Christian Couder's avatarChristian Couder <chriscool@tuxfamily.org>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      afaef55e
  17. 07 Dec, 2017 1 commit
  18. 10 Aug, 2017 1 commit
  19. 01 Jul, 2017 1 commit
  20. 15 Jun, 2017 2 commits
  21. 27 Mar, 2017 1 commit
    • René Scharfe's avatar
      strbuf: support long paths w/o read rights in strbuf_getcwd() on FreeBSD · a54e938e
      René Scharfe authored
      FreeBSD implements getcwd(3) as a syscall, but falls back to a version
      based on readdir(3) if it fails for some reason.  The latter requires
      permissions to read and execute path components, while the former does
      not.  That means that if our buffer is too small and we're missing
      rights we could get EACCES, but we may succeed with a bigger buffer.
      
      Keep retrying if getcwd(3) indicates lack of permissions until our
      buffer can fit PATH_MAX bytes, as that's the maximum supported by the
      syscall on FreeBSD anyway.  This way we do what we can to be able to
      benefit from the syscall, but we also won't loop forever if there is a
      real permission issue.
      
      This fixes a regression introduced with 7333ed17 (setup: convert
      setup_git_directory_gently_1 et al. to strbuf, 2014-07-28) for paths
      longer than 127 bytes with components that miss read or execute
      permissions (e.g. 0711 on /home for privacy reasons); we used a fixed
      PATH_MAX-sized buffer before.
      Reported-by: 's avatarZenobiusz Kunegunda <zenobiusz.kunegunda@interia.pl>
      Signed-off-by: 's avatarRene Scharfe <l.s.r@web.de>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      a54e938e
  22. 27 Feb, 2017 1 commit
    • René Scharfe's avatar
      strbuf: add strbuf_add_real_path() · 33ad9ddd
      René Scharfe authored
      Add a function for appending the canonized absolute pathname of a given
      path to a strbuf.  It keeps the existing contents intact, as expected of
      a function of the strbuf_add() family, while avoiding copying the result
      if the given strbuf is empty.  It's more consistent with the rest of the
      strbuf API than strbuf_realpath(), which it's wrapping.
      
      Also add a semantic patch demonstrating its intended usage and apply it
      to the current tree.  Using strbuf_add_real_path() instead of calling
      strbuf_addstr() and real_path() avoids an extra copy to a static buffer.
      Signed-off-by: 's avatarRene Scharfe <l.s.r@web.de>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      33ad9ddd
  23. 10 Oct, 2016 1 commit
    • Jeff King's avatar
      link_alt_odb_entry: handle normalize_path errors · 670c359d
      Jeff King authored
      When we add a new alternate to the list, we try to normalize
      out any redundant "..", etc. However, we do not look at the
      return value of normalize_path_copy(), and will happily
      continue with a path that could not be normalized. Worse,
      the normalizing process is done in-place, so we are left
      with whatever half-finished working state the normalizing
      function was in.
      
      Fortunately, this cannot cause us to read past the end of
      our buffer, as that working state will always leave the
      NUL from the original path in place. And we do tend to
      notice problems when we check is_directory() on the path.
      But you can see the nonsense that we feed to is_directory
      with an entry like:
      
        this/../../is/../../way/../../too/../../deep/../../to/../../resolve
      
      in your objects/info/alternates, which yields:
      
        error: object directory
        /to/e/deep/too/way//ects/this/../../is/../../way/../../too/../../deep/../../to/../../resolve
        does not exist; check .git/objects/info/alternates.
      
      We can easily fix this just by checking the return value.
      But that makes it hard to generate a good error message,
      since we're normalizing in-place and our input value has
      been overwritten by cruft.
      
      Instead, let's provide a strbuf helper that does an in-place
      normalize, but restores the original contents on error. This
      uses a second buffer under the hood, which is slightly less
      efficient, but this is not a performance-critical code path.
      
      The strbuf helper can also properly set the "len" parameter
      of the strbuf before returning. Just doing:
      
        normalize_path_copy(buf.buf, buf.buf);
      
      will shorten the string, but leave buf.len at the original
      length. That may be confusing to later code which uses the
      strbuf.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      670c359d
  24. 13 Sep, 2016 1 commit
  25. 22 Jul, 2016 1 commit
  26. 05 Mar, 2016 1 commit
    • Jeff King's avatar
      strbuf_getwholeline: NUL-terminate getdelim buffer on error · b7090430
      Jeff King authored
      Commit 0cc30e0e (strbuf_getwholeline: use getdelim if it is
      available, 2015-04-16) tries to clean up after getdelim()
      returns EOF, but gets one case wrong, which can lead in some
      obscure cases to us reading uninitialized memory.
      
      After getdelim() returns -1, we re-initialize the strbuf
      only if sb->buf is NULL. The thinking was that either:
      
        1. We fed an existing allocated buffer to getdelim(), and
           at most it would have realloc'd, leaving our NUL in
           place.
      
        2. We didn't have a buffer to feed, so we gave getdelim()
           NULL; sb->buf will remain NULL, and we just want to
           restore the empty slopbuf.
      
      But that second case isn't quite right. getdelim() may
      allocate a buffer, write nothing into it, and then return
      EOF. The resulting strbuf rightfully has sb->len set to "0",
      but is missing the NUL terminator in the first byte.
      
      Most call-sites are fine with this. They see the EOF and
      don't bother looking at the strbuf. Or they notice that
      sb->len is empty, and don't look at the contents. But
      there's at least one case that does neither, and relies on
      parsing the resulting (possibly zero-length) string:
      fast-import. You can see this in action with the new test
      (though we probably only notice failure there when run with
      --valgrind or ASAN).
      
      We can fix this by unconditionally resetting the strbuf when
      we have a buffer after getdelim(). That fixes case 2 above.
      Case 1 is probably already fine in practice, but it does not
      hurt for us to re-assert our invariants (especially because
      we are relying on whatever getdelim() happens to do, which
      may vary from platform to platform). Our fix covers that
      case, too.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      b7090430
  27. 01 Mar, 2016 1 commit
  28. 22 Feb, 2016 1 commit
    • Jeff King's avatar
      use xmallocz to avoid size arithmetic · 3733e694
      Jeff King authored
      We frequently allocate strings as xmalloc(len + 1), where
      the extra 1 is for the NUL terminator. This can be done more
      simply with xmallocz, which also checks for integer
      overflow.
      
      There's no case where switching xmalloc(n+1) to xmallocz(n)
      is wrong; the result is the same length, and malloc made no
      guarantees about what was in the buffer anyway. But in some
      cases, we can stop manually placing NUL at the end of the
      allocated buffer. But that's only safe if it's clear that
      the contents will always fill the buffer.
      
      In each case where this patch does so, I manually examined
      the control flow, and I tried to err on the side of caution.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      3733e694
  29. 15 Jan, 2016 2 commits
    • Junio C Hamano's avatar
      strbuf: give strbuf_getline() to the "most text friendly" variant · 1a0c8dfd
      Junio C Hamano authored
      Now there is no direct caller to strbuf_getline(), we can demote it
      to file-scope static that is private to strbuf.c and rename it to
      strbuf_getdelim().  Rename strbuf_getline_crlf(), which is designed
      to be the most "text friendly" variant, and allow it to take over
      this simplest name, strbuf_getline(), so we can add more uses of it
      without having to type _crlf over and over again in the coming
      steps.
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      1a0c8dfd
    • Junio C Hamano's avatar
      strbuf: introduce strbuf_getline_{lf,nul}() · 8f309aeb
      Junio C Hamano authored
      The strbuf_getline() interface allows a byte other than LF or NUL as
      the line terminator, but this is only because I wrote these
      codepaths anticipating that there might be a value other than NUL
      and LF that could be useful when I introduced line_termination long
      time ago.  No useful caller that uses other value has emerged.
      
      By now, it is clear that the interface is overly broad without a
      good reason.  Many codepaths have hardcoded preference to read
      either LF terminated or NUL terminated records from their input, and
      then call strbuf_getline() with LF or NUL as the third parameter.
      
      This step introduces two thin wrappers around strbuf_getline(),
      namely, strbuf_getline_lf() and strbuf_getline_nul(), and
      mechanically rewrites these call sites to call either one of
      them.  The changes contained in this patch are:
      
       * introduction of these two functions in strbuf.[ch]
      
       * mechanical conversion of all callers to strbuf_getline() with
         either '\n' or '\0' as the third parameter to instead call the
         respective thin wrapper.
      
      After this step, output from "git grep 'strbuf_getline('" would
      become a lot smaller.  An interim goal of this series is to make
      this an empty set, so that we can have strbuf_getline_crlf() take
      over the shorter name strbuf_getline().
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      8f309aeb
  30. 14 Jan, 2016 2 commits
    • Junio C Hamano's avatar
      strbuf: make strbuf_getline_crlf() global · c8aa9fdf
      Junio C Hamano authored
      Often we read "text" files that are supplied by the end user
      (e.g. commit log message that was edited with $GIT_EDITOR upon 'git
      commit -e'), and in some environments lines in a text file are
      terminated with CRLF.  Existing strbuf_getline() knows to read a
      single line and then strip the terminating byte from the result, but
      it is handy to have a version that is more tailored for a "text"
      input that takes both '\n' and '\r\n' as line terminator (aka
      <newline> in POSIX lingo) and returns the body of the line after
      stripping <newline>.
      
      Recently reimplemented "git am" uses such a function implemented
      privately; move it to strbuf.[ch] and make it available for others.
      
      Note that we do not blindly replace calls to strbuf_getline() that
      uses LF as the line terminator with calls to strbuf_getline_crlf()
      and this is very much deliberate.  Some callers may want to treat an
      incoming line that ends with CR (and terminated with LF) to have a
      payload that includes the final CR, and such a blind replacement
      will result in misconversion when done without code audit.
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      c8aa9fdf
    • Junio C Hamano's avatar
      strbuf: miniscule style fix · dce80bd1
      Junio C Hamano authored
      We write one SP on each side of an operator, even inside an [] pair
      that computes the array index.
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      dce80bd1
  31. 16 Dec, 2015 1 commit