1. 29 Sep, 2016 1 commit
  2. 08 Jul, 2016 1 commit
    • Junio C Hamano's avatar
      commit.c: remove print_commit_list() · 54307ea7
      Junio C Hamano authored
      The helper function tries to offer a way to conveniently show the
      last one differently from others, presumably to allow you to say
      something like
      
      	A, B, and C.
      
      while iterating over a list that has these three elements.
      
      However, there is only one caller, and it passes the same format
      string "%s\n" for both the last one and the other ones.  Retire the
      helper function and update the caller with a simplified version.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      54307ea7
  3. 28 Jun, 2016 1 commit
  4. 17 Jun, 2016 2 commits
    • Vasco Almeida's avatar
      i18n: bisect: mark strings for translation · 14dc4899
      Vasco Almeida authored
      In the last message, involving Q_(), try to mark the message in such way
      that is suited for RTL (Right to Left) languages.
      
      Update test t6030-bisect-porcelain.sh to reflect the changes.
      Signed-off-by: default avatarVasco Almeida <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      14dc4899
    • Jeff King's avatar
      bisect: always call setup_revisions after init_revisions · 43ec5509
      Jeff King authored
      init_revisions() initializes the rev_info struct to default
      values, and setup_revisions() parses any command-line
      arguments and finalizes the struct.
      
      In e22278c0 (bisect: display first bad commit without forking
      a new process, 2009-05-28), a show_diff_tree() was added
      that calls the former but not the latter. It doesn't have
      any arguments to parse, but it still should do the
      finalizing step.
      
      This may have caused other minor bugs over the years, but it
      became much more prominent after fe37a9c5 (pretty: allow
      tweaking tabwidth in --expand-tabs, 2016-03-29). That leaves
      the expected tab width as "-1", rather than the true default
      of "8". When we see a commit with tabs to be expanded, we
      end up trying to add (size_t)-1 spaces to a strbuf, which
      complains about the integer overflow.
      
      The fix is easy: just call setup_revisions() with no
      arguments.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      43ec5509
  5. 09 May, 2016 1 commit
  6. 22 Feb, 2016 1 commit
  7. 15 Jan, 2016 1 commit
    • 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: default avatarJunio C Hamano <[email protected]>
      8f309aeb
  8. 20 Nov, 2015 3 commits
  9. 10 Aug, 2015 1 commit
    • Jeff King's avatar
      memoize common git-path "constant" files · f932729c
      Jeff King authored
      One of the most common uses of git_path() is to pass a
      constant, like git_path("MERGE_MSG"). This has two
      drawbacks:
      
        1. The return value is a static buffer, and the lifetime
           is dependent on other calls to git_path, etc.
      
        2. There's no compile-time checking of the pathname. This
           is OK for a one-off (after all, we have to spell it
           correctly at least once), but many of these constant
           strings appear throughout the code.
      
      This patch introduces a series of functions to "memoize"
      these strings, which are essentially globals for the
      lifetime of the program. We compute the value once, take
      ownership of the buffer, and return the cached value for
      subsequent calls.  cache.h provides a helper macro for
      defining these functions as one-liners, and defines a few
      common ones for global use.
      
      Using a macro is a little bit gross, but it does nicely
      document the purpose of the functions. If we need to touch
      them all later (e.g., because we learned how to change the
      git_dir variable at runtime, and need to invalidate all of
      the stored values), it will be much easier to have the
      complete list.
      
      Note that the shared-global functions have separate, manual
      declarations. We could do something clever with the macros
      (e.g., expand it to a declaration in some places, and a
      declaration _and_ a definition in path.c). But there aren't
      that many, and it's probably better to stay away from
      too-magical macros.
      
      Likewise, if we abandon the C preprocessor in favor of
      generating these with a script, we could get much fancier.
      E.g., normalizing "FOO/BAR-BAZ" into "git_path_foo_bar_baz".
      But the small amount of saved typing is probably not worth
      the resulting confusion to readers who want to grep for the
      function's definition.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      f932729c
  10. 03 Aug, 2015 2 commits
  11. 31 Jul, 2015 1 commit
  12. 29 Jun, 2015 1 commit
  13. 23 Jun, 2015 1 commit
  14. 25 May, 2015 2 commits
  15. 14 Mar, 2015 1 commit
  16. 30 Oct, 2014 2 commits
    • Junio C Hamano's avatar
      get_merge_bases(): always clean-up object flags · 2ce406cc
      Junio C Hamano authored
      The callers of get_merge_bases() can choose to leave object flags
      used during the merge-base traversal by passing cleanup=0 as a
      parameter, but in practice a very few callers can afford to do so
      (namely, "git merge-base"), as they need to compute merge base in
      preparation for other processing of their own and they need to see
      the object without contaminate flags.
      
      Change the function signature of get_merge_bases_many() and
      get_merge_bases() to drop the cleanup parameter, so that the
      majority of the callers do not have to say ", 1" at the end.
      
      Give a new get_merge_bases_many_dirty() API to support only a few
      callers that know they do not need to spend cycles cleaning up the
      object flags.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      2ce406cc
    • Junio C Hamano's avatar
      bisect: clean flags after checking merge bases · d76c9e95
      Junio C Hamano authored
      Unless there is a good reason to belieave that a particular
      invocation of a get_merge_bases*() is the last one that cares about
      the object flags the computation of merge bases leaves on the
      objects, the "cleanup" parameter should always be true, and I do not
      think there is one in this codepath.
      
      Found by code inspection.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      d76c9e95
  17. 26 Aug, 2014 1 commit
    • Jeff King's avatar
      log-tree: make add_name_decoration a public function · 662174d2
      Jeff King authored
      The log-tree code keeps a "struct decoration" hash to show
      text decorations for each commit during log traversals. It
      makes this available to other files by providing global
      access to the hash. This can result in other code adding
      entries that do not conform to what log-tree expects.
      
      For example, the bisect code adds its own "dist"
      decorations to be shown. Originally the bisect code was
      correct, but when the name_decoration code grew a new field
      in eb3005e2 (commit.h: add 'type' to struct name_decoration,
      2010-06-19), the bisect code was not updated. As a result,
      the log-tree code can access uninitialized memory and even
      segfault.
      
      We can fix this by making name_decoration's adding function
      public. If all callers use it, then any changes to struct
      initialization only need to happen in one place (and because
      the members come in as parameters, the compiler can notice a
      caller who does not supply enough information).
      
      As a bonus, this also means that the decoration hashes
      created by the bisect code will use less memory (previously
      we over-allocated space for the distance integer, but now we
      format it into a temporary buffer and copy it to the final
      flex-array).
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      662174d2
  18. 25 Mar, 2014 1 commit
  19. 31 Jan, 2014 1 commit
  20. 05 Dec, 2013 1 commit
    • Christian Couder's avatar
      replace {pre,suf}fixcmp() with {starts,ends}_with() · 59556548
      Christian Couder authored
      Leaving only the function definitions and declarations so that any
      new topic in flight can still make use of the old functions, replace
      existing uses of the prefixcmp() and suffixcmp() with new API
      functions.
      
      The change can be recreated by mechanically applying this:
      
          $ git grep -l -e prefixcmp -e suffixcmp -- \*.c |
            grep -v strbuf\\.c |
            xargs perl -pi -e '
              s|!prefixcmp\(|starts_with\(|g;
              s|prefixcmp\(|!starts_with\(|g;
              s|!suffixcmp\(|ends_with\(|g;
              s|suffixcmp\(|!ends_with\(|g;
            '
      
      on the result of preparatory changes in this series.
      Signed-off-by: Christian Couder's avatarChristian Couder <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      59556548
  21. 28 Aug, 2013 1 commit
  22. 02 Jun, 2013 1 commit
  23. 03 Apr, 2013 1 commit
  24. 29 Oct, 2012 1 commit
  25. 04 Sep, 2012 1 commit
  26. 03 May, 2012 1 commit
  27. 03 Oct, 2011 2 commits
  28. 14 Sep, 2011 1 commit
  29. 04 Aug, 2011 1 commit
  30. 20 May, 2011 1 commit
  31. 23 Jul, 2010 1 commit
  32. 01 Mar, 2010 1 commit
    • Christian Couder's avatar
      bisect: error out when passing bad path parameters · 8f69f72f
      Christian Couder authored
      As reported by Mark Lodato, "git bisect", when it was started with
      path parameters that match no commit was kind of working without
      taking account of path parameters and was reporting something like:
      
      Bisecting: -1 revisions left to test after this (roughly 0 steps)
      
      It is more correct and safer to just error out in this case, before
      displaying the revisions left, so this patch does just that.
      
      Note that this bug is very old, it exists at least since v1.5.5.
      And it is possible to detect that case earlier in the bisect
      algorithm, but it is not clear that it would be an improvement to
      error out earlier, on the contrary it may change the behavior of
      "git rev-list --bisect-all" for example, which is currently correct.
      Signed-off-by: Christian Couder's avatarChristian Couder <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      8f69f72f
  33. 19 Jan, 2010 1 commit