1. 11 Feb, 2019 1 commit
  2. 14 Jan, 2019 4 commits
  3. 28 Dec, 2018 1 commit
    • Elijah Newren's avatar
      git-rebase, sequencer: extend --quiet option for the interactive machinery · 899b49c4
      Elijah Newren authored
      While 'quiet' and 'interactive' may sound like antonyms, the interactive
      machinery actually has logic that implements several
      interactive_rebase=implied cases (--exec, --keep-empty, --rebase-merges)
      which won't pop up an editor.  The rewrite of interactive rebase in C
      added a quiet option, though it only turns stats off.  Since we want to
      make the interactive machinery also take over for git-rebase--merge, it
      should fully implement the --quiet option.
      
      git-rebase--interactive was already somewhat quieter than
      git-rebase--merge and git-rebase--am, possibly because cherry-pick has
      just traditionally been quieter.  As such, we only drop a few
      informational messages -- "Rebasing (n/m)" and "Successfully rebased..."
      
      Also, for simplicity, remove the differences in how quiet and verbose
      options were recorded.  Having one be signalled by the presence of a
      "verbose" file in the state_dir, while the other was signalled by the
      contents of a "quiet" file was just weirdly inconsistent.  (This
      inconsistency pre-dated the rewrite into C.)  Make them consistent by
      having them both key off the presence of the file.
      Signed-off-by: Elijah Newren's avatarElijah Newren <newren@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      899b49c4
  4. 26 Dec, 2018 1 commit
  5. 11 Dec, 2018 1 commit
  6. 10 Dec, 2018 1 commit
  7. 13 Nov, 2018 2 commits
  8. 12 Nov, 2018 5 commits
  9. 06 Nov, 2018 1 commit
  10. 05 Nov, 2018 1 commit
  11. 01 Nov, 2018 2 commits
    • Phillip Wood's avatar
      sequencer: use read_author_script() · 4d010a75
      Phillip Wood authored
      Use the new function added in the last commit to read the author
      script, updating read_env_script() and read_author_ident(). We now
      have a single code path that reads the author script for am and all
      flavors of rebase. This changes the behavior of read_env_script() as
      previously it would set any environment variables that were in the
      author-script file. Now it is an error if the file contains other
      variables or any of GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL and
      GIT_AUTHOR_DATE are missing. This is what am and the non interactive
      version of rebase have been doing for several years so hopefully it
      will not cause a problem for interactive rebase users. The advantage
      is that we are reusing existing code from am which uses sq_dequote()
      to properly dequote variables. This fixes potential problems with user
      edited scripts as read_env_script() which did not track quotes
      properly.
      
      This commit also removes the fallback code for checking for a broken
      author script after git is upgraded when a rebase is stopped. Now that
      the parsing uses sq_dequote() it will reliably return an error if the
      quoting is broken and the user will have to abort the rebase and
      restart. This isn't ideal but it's a corner case and the detection of
      the broken quoting could be confused by user edited author scripts.
      Signed-off-by: Phillip Wood's avatarPhillip Wood <phillip.wood@dunelm.org.uk>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      4d010a75
    • Phillip Wood's avatar
      add read_author_script() to libgit · bcd33ec2
      Phillip Wood authored
      Add read_author_script() to sequencer.c based on the implementation in
      builtin/am.c and update read_am_author_script() to use
      read_author_script(). The sequencer code that reads the author script
      will be updated in the next commit.
      Signed-off-by: Phillip Wood's avatarPhillip Wood <phillip.wood@dunelm.org.uk>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      bcd33ec2
  12. 31 Oct, 2018 1 commit
  13. 27 Oct, 2018 1 commit
  14. 26 Oct, 2018 1 commit
  15. 12 Oct, 2018 1 commit
  16. 04 Oct, 2018 1 commit
  17. 21 Sep, 2018 3 commits
  18. 17 Sep, 2018 1 commit
    • Duy Nguyen's avatar
      status: show progress bar if refreshing the index takes too long · ae9af122
      Duy Nguyen authored
      Refreshing the index is usually very fast, but it can still take a
      long time sometimes. Cold cache is one. Or copying a repo to a new
      place (*). It's good to show something to let the user know "git
      status" is not hanging, it's just busy doing something.
      
      (*) In this case, all stat info in the index becomes invalid and git
          falls back to rehashing all file content to see if there's any
          difference between updating stat info in the index. This is quite
          expensive. Even with a repo as small as git.git, it takes 3
          seconds.
      Signed-off-by: Duy Nguyen's avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      ae9af122
  19. 13 Sep, 2018 1 commit
    • Elijah Newren's avatar
      sequencer: fix --allow-empty-message behavior, make it smarter · a3ec9eaf
      Elijah Newren authored
      In commit b00bf1c9 ("git-rebase: make --allow-empty-message the
      default", 2018-06-27), several arguments were given for transplanting
      empty commits without halting and asking the user for confirmation on
      each commit.  These arguments were incomplete because the logic clearly
      assumed the only cases under consideration were transplanting of commits
      with empty messages (see the comment about "There are two sources for
      commits with empty messages).  It didn't discuss or even consider
      rewords, squashes, etc. where the user is explicitly asked for a new
      commit message and provides an empty one.  (My bad, I totally should
      have thought about that at the time, but just didn't.)
      
      Rewords and squashes are significantly different, though, as described
      by SZEDER:
      
          Let's suppose you start an interactive rebase, choose a commit to
          squash, save the instruction sheet, rebase fires up your editor, and
          then you notice that you mistakenly chose the wrong commit to
          squash.  What do you do, how do you abort?
      
          Before [that commit] you could clear the commit message, exit the
          editor, and then rebase would say "Aborting commit due to empty
          commit message.", and you get to run 'git rebase --abort', and start
          over.
      
          But [since that commit, ...] saving the commit message as is would
          let rebase continue and create a bunch of unnecessary objects, and
          then you would have to use the reflog to return to the pre-rebase
          state.
      
      Also, he states:
      
          The instructions in the commit message template, which is shown for
          'reword' and 'squash', too, still say...
      
          # Please enter the commit message for your changes. Lines starting
          # with '#' will be ignored, and an empty message aborts the commit.
      
      These are sound arguments that when editing commit messages during a
      sequencer operation, that if the commit message is empty then the
      operation should halt and ask the user to correct.  The arguments in
      commit b00bf1c9 (referenced above) still apply when transplanting
      previously created commits with empty commit messages, so the sequencer
      should not halt for those.
      
      Furthermore, all rationale so far applies equally for cherry-pick as for
      rebase.  Therefore, make the code default to --allow-empty-message when
      transplanting an existing commit, and to default to halting when the
      user is asked to edit a commit message and provides an empty one -- for
      both rebase and cherry-pick.
      Signed-off-by: Elijah Newren's avatarElijah Newren <newren@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      a3ec9eaf
  20. 04 Sep, 2018 1 commit
    • Johannes Schindelin's avatar
      rebase -i: be careful to wrap up fixup/squash chains · 10d2f354
      Johannes Schindelin authored
      When an interactive rebase was stopped at the end of a fixup/squash
      chain, the user might have edited the commit manually before continuing
      (with either `git rebase --skip` or `git rebase --continue`, it does not
      really matter which).
      
      We need to be very careful to wrap up the fixup/squash chain also in
      this scenario: otherwise the next fixup/squash chain would try to pick
      up where the previous one was left.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      10d2f354
  21. 29 Aug, 2018 6 commits
    • Alban Gruin's avatar
      rebase -i: rewrite write_basic_state() in C · 65850686
      Alban Gruin authored
      This rewrites write_basic_state() from git-rebase.sh in C.  This is the
      first step in the conversion of init_basic_state(), hence the mode in
      rebase--helper.c is called INIT_BASIC_STATE.  init_basic_state() will be
      converted in the next commit.
      
      The part of read_strategy_opts() that parses the stategy options is
      moved to a new function to allow its use in rebase--helper.c.
      
      Finally, the call to write_basic_state() is removed from
      git-rebase--interactive.sh, replaced by a call to `--init-basic-state`.
      Signed-off-by: default avatarAlban Gruin <alban.gruin@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      65850686
    • Alban Gruin's avatar
      rebase -i: remove unused modes and functions · 91f0d95d
      Alban Gruin authored
      This removes the modes `--skip-unnecessary-picks`, `--append-todo-help`,
      and `--checkout-onto` from rebase--helper.c, the functions of
      git-rebase--interactive.sh that were rendered useless by the rewrite of
      complete_action(), and append_todo_help_to_file() from
      rebase-interactive.c.
      
      skip_unnecessary_picks() and checkout_onto() becomes static, as they are
      only used inside of the sequencer.
      Signed-off-by: default avatarAlban Gruin <alban.gruin@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      91f0d95d
    • Alban Gruin's avatar
      rebase -i: rewrite complete_action() in C · b97e1873
      Alban Gruin authored
      This rewrites complete_action() from shell to C.
      
      A new mode is added to rebase--helper (`--complete-action`), as well as
      a new flag (`--autosquash`).
      
      Finally, complete_action() is stripped from git-rebase--interactive.sh.
      
      The original complete_action() would return the code 2 when the todo
      list contained no actions.  This was a special case for rebase -i and
      -p; git-rebase.sh would then apply the autostash, delete the state
      directory, and die with the message "Nothing to do".  This cleanup is
      rewritten in C instead of returning 2.  As rebase -i no longer returns
      2, the comment describing this behaviour in git-rebase.sh is updated to
      reflect this change.
      
      The message "Nothing to do" is now printed with error(), and so becomes
      "error: nothing to do".  Some tests in t3404 check this value, so they
      are updated to fit this change.
      
      The first check might seem useless as we write "noop" to the todo list
      if it is empty.  Actually, the todo list might contain commented
      commands (ie. empty commits).  In this case, complete_action() won’t
      write "noop", and will abort without starting the editor.
      Signed-off-by: default avatarAlban Gruin <alban.gruin@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      b97e1873
    • Jeff King's avatar
      convert "oidcmp() != 0" to "!oideq()" · 9001dc2a
      Jeff King authored
      This is the flip side of the previous two patches: checking
      for a non-zero oidcmp() can be more strictly expressed as
      inequality. Like those patches, we write "!= 0" in the
      coccinelle transformation, which covers by isomorphism the
      more common:
      
        if (oidcmp(E1, E2))
      
      As with the previous two patches, this patch can be achieved
      almost entirely by running "make coccicheck"; the only
      differences are manual line-wrap fixes to match the original
      code.
      
      There is one thing to note for anybody replicating this,
      though: coccinelle 1.0.4 seems to miss the case in
      builtin/tag.c, even though it's basically the same as all
      the others. Running with 1.0.7 does catch this, so
      presumably it's just a coccinelle bug that was fixed in the
      interim.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      9001dc2a
    • Jeff King's avatar
      convert "oidcmp() == 0" to oideq() · 4a7e27e9
      Jeff King authored
      Using the more restrictive oideq() should, in the long run,
      give the compiler more opportunities to optimize these
      callsites. For now, this conversion should be a complete
      noop with respect to the generated code.
      
      The result is also perhaps a little more readable, as it
      avoids the "zero is equal" idiom. Since it's so prevalent in
      C, I think seasoned programmers tend not to even notice it
      anymore, but it can sometimes make for awkward double
      negations (e.g., we can drop a few !!oidcmp() instances
      here).
      
      This patch was generated almost entirely by the included
      coccinelle patch. This mechanical conversion should be
      completely safe, because we check explicitly for cases where
      oidcmp() is compared to 0, which is what oideq() is doing
      under the hood. Note that we don't have to catch "!oidcmp()"
      separately; coccinelle's standard isomorphisms make sure the
      two are treated equivalently.
      
      I say "almost" because I did hand-edit the coccinelle output
      to fix up a few style violations (it mostly keeps the
      original formatting, but sometimes unwraps long lines).
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      4a7e27e9
    • Jeff King's avatar
      coccinelle: use <...> for function exclusion · 4d168e74
      Jeff King authored
      Sometimes we want to suppress a coccinelle transformation
      inside a particular function. For example, in finding
      conversions of hashcmp() to oidcmp(), we should not convert
      the call in oidcmp() itself, since that would cause infinite
      recursion. We write that like this:
      
        @@
        identifier f != oidcmp;
        expression E1, E2;
        @@
          f(...) {...
        - hashcmp(E1->hash, E2->hash)
        + oidcmp(E1, E2)
          ...}
      
      to match the interior of any function _except_ oidcmp().
      
      Unfortunately, this doesn't catch all cases (e.g., the one
      in sequencer.c that this patch fixes). The problem, as
      explained by one of the Coccinelle developers in [1], is:
      
        For transformation, A ... B requires that B occur on every
        execution path starting with A, unless that execution path
        ends up in error handling code.  (eg, if (...) { ...
        return; }).  Here your A is the start of the function.  So
        you need a call to hashcmp on every path through the
        function, which fails when you add ifs.
      
        [...]
      
        Another issue with A ... B is that by default A and B
        should not appear in the matched region.  So your original
        rule matches only the case where every execution path
        contains exactly one call to hashcmp, not more than one.
      
      One way to solve this is to put the pattern inside an
      angle-bracket pattern like "<... P ...>", which allows zero
      or more matches of P. That works (and is what this patch
      does), but it has one drawback: it matches more than we care
      about, and Coccinelle uses extra CPU. Here are timings for
      "make coccicheck" before and after this patch:
      
        [before]
        real	1m27.122s
        user	7m34.451s
        sys	0m37.330s
      
        [after]
        real	2m18.040s
        user	10m58.310s
        sys	0m41.549s
      
      That's not ideal, but it's more important for this to be
      correct than to be fast. And coccicheck is already fairly
      slow (and people don't run it for every single patch). So
      it's an acceptable tradeoff.
      
      There _is_ a better way to do it, which is to record the
      position at which we find hashcmp(), and then check it
      against the forbidden function list. Like:
      
        @@
        position p : script:python() { p[0].current_element != "oidcmp" };
        expression E1,E2;
        @@
        - hashcmp@p(E1->hash, E2->hash)
        + oidcmp(E1, E2)
      
      This is only a little slower than the current code, and does
      the right thing in all cases. Unfortunately, not all builds
      of Coccinelle include python support (including the ones in
      Debian). Requiring it may mean that fewer people can easily
      run the tool, which is worse than it simply being a little
      slower.
      
      We may want to revisit this decision in the future if:
      
        - builds with python become more common
      
        - we find more uses for python support that tip the
          cost-benefit analysis
      
      But for now this patch sticks with the angle-bracket
      solution, and converts all existing cocci patches. This
      fixes only one missed case in the current code, though it
      makes a much better difference for some new rules I'm adding
      (converting "!hashcmp()" to "hasheq()" misses over half the
      possible conversions using the old form).
      
      [1] https://public-inbox.org/git/alpine.DEB.2.21.1808240652370.2344@hadrien/Helped-by: default avatarJulia Lawall <julia.lawall@lip6.fr>
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      4d168e74
  22. 23 Aug, 2018 3 commits
    • Jean-Noël Avila's avatar
      i18n: fix mistakes in translated strings · 27c929ed
      Jean-Noël Avila authored
      Fix typos and convert a question which does not expect to be replied
      to a simple advice.
      Signed-off-by: Jean-Noël Avila's avatarJean-Noël Avila <jn.avila@free.fr>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      27c929ed
    • Jeff King's avatar
      append_signoff: use size_t for string offsets · 66e83d9b
      Jeff King authored
      The append_signoff() function takes an "int" to specify the
      number of bytes to ignore. Most callers just pass 0, and the
      remainder use ignore_non_trailer() to skip over cruft.
      That function also returns an int, and uses them internally.
      
      On systems where size_t is larger than an int (i.e., most
      64-bit systems), dealing with a ridiculously large commit
      message could end up overflowing an int, producing
      surprising results (e.g., returning a negative offset, which
      would cause us to look outside the original string).
      
      Let's consistently use size_t for these offsets through this
      whole stack. As a bonus, this makes the meaning of
      "ignore_footer" as an offset (and not a boolean) more clear.
      But while we're here, let's also document the interface.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      66e83d9b
    • Jeff King's avatar
      sequencer: ignore "---" divider when parsing trailers · ffce7f59
      Jeff King authored
      When the sequencer code appends a signoff or cherry-pick
      origin, it uses the default trailer-parsing options, which
      treat "---" as the end of the commit message. As a result,
      it may be fooled by a commit message that contains that
      string and fail to find the existing trailer block. Even
      more confusing, the actual append code does not know about
      "---", and always appends to the end of the string. This can
      lead to bizarre results. E.g., appending a signoff to a
      commit message like this:
      
        subject
      
        body
        ---
        these dashes confuse the parser!
      
        Signed-off-by: A
      
      results in output with a final block like:
      
        Signed-off-by: A
      
        Signed-off-by: A
      
      The parser thinks the final line of the message is "body",
      and ignores everything else, claiming there are no trailers.
      So we output an extra newline separator (wrong) and add a
      duplicate signoff (also wrong).
      
      Since we know we are feeding a pure commit message, we can
      simply tell the parser to ignore the "---" divider.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      ffce7f59