1. 24 Jan, 2018 1 commit
  2. 13 Dec, 2017 1 commit
    • Phillip Wood's avatar
      sequencer: improve config handling · 28d6daed
      Phillip Wood authored
      The previous config handling relied on global variables, called
      git_default_config() even when the key had already been handled by
      git_sequencer_config() and did not initialize the diff configuration
      variables. Improve this by: i) loading the default values for message
      cleanup and gpg signing of commits into struct replay_opts;
      ii) restructuring the code to return immediately once a key is
      handled; and iii) calling git_diff_basic_config(). Note that
      unfortunately it is not possible to return early if the key is handled
      by git_gpg_config() as it does not indicate to the caller if the key
      has been handled or not.
      
      The sequencer should probably have been calling
      git_diff_basic_config() before as it creates a patch when there are
      conflicts. The shell version uses 'diff-tree' to create the patch so
      calling git_diff_basic_config() should match that. Although 'git
      commit' calls git_diff_ui_config() I don't think the output of
      print_commit_summary() is affected by anything that is loaded by that
      as print_commit_summary() always turns on rename detection so would
      ignore the value in the user's configuration anyway. The other values
      loaded by git_diff_ui_config() are about the formatting of patches so
      are not relevant to print_commit_summary().
      Signed-off-by: Phillip Wood's avatarPhillip Wood <phillip.wood@dunelm.org.uk>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      28d6daed
  3. 05 Dec, 2017 4 commits
  4. 24 Nov, 2017 2 commits
    • Phillip Wood's avatar
      sequencer: load commit related config · b36c5908
      Phillip Wood authored
      Load default values for message cleanup and gpg signing of commits in
      preparation for committing without forking 'git commit'. Note that we
      interpret commit.cleanup=scissors to mean COMMIT_MSG_CLEANUP_SPACE to
      be consistent with 'git commit'
      Signed-off-by: Phillip Wood's avatarPhillip Wood <phillip.wood@dunelm.org.uk>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      b36c5908
    • Phillip Wood's avatar
      commit: move print_commit_summary() to libgit · e47c6caf
      Phillip Wood authored
      Move print_commit_summary() from builtin/commit.c to sequencer.c so it
      can be shared with other commands. The function is modified by
      changing the last argument to a flag so callers can specify whether
      they want to show the author date in addition to specifying if this is
      an initial commit.
      
      If the sequencer dies in print_commit_summary() (which can only happen
      when cherry-picking or reverting) then neither the todo list nor the
      abort safety file are updated to reflect the commit that was just
      made. print_commit_summary() can die if:
      
       - The commit that was just created cannot be found or parsed.
      
       - HEAD cannot be resolved either because some other process is
         updating it (which is bad news in the middle of a cherry-pick) or
         because it is corrupt.
      
       - log_tree_commit() cannot read some objects.
      
      In all those cases dying will leave the sequencer in a sane state for
      aborting; 'git cherry-pick --abort' will rewind HEAD to the last
      successful commit before there was a problem with HEAD or the object
      database. If the user somehow fixes the problem and runs 'git
      cherry-pick --continue' then the sequencer will try and pick the same
      commit again which may or may not be what the user wants depending on
      what caused print_commit_summary() to die. If print_commit_summary()
      returned an error instead then update_abort_safety_file() would try to
      resolve HEAD which may or may not be successful. If it is successful
      then running 'git rebase --abort' would not rewind HEAD to the last
      successful commit which is not what we want.
      Signed-off-by: Phillip Wood's avatarPhillip Wood <phillip.wood@dunelm.org.uk>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      e47c6caf
  5. 18 Nov, 2017 2 commits
  6. 10 Nov, 2017 1 commit
  7. 27 Jul, 2017 5 commits
    • Johannes Schindelin's avatar
      rebase -i: rearrange fixup/squash lines using the rebase--helper · c44a4c65
      Johannes Schindelin authored
      This operation has quadratic complexity, which is especially painful
      on Windows, where shell scripts are *already* slow (mainly due to the
      overhead of the POSIX emulation layer).
      
      Let's reimplement this with linear complexity (using a hash map to
      match the commits' subject lines) for the common case; Sadly, the
      fixup/squash feature's design neglected performance considerations,
      allowing arbitrary prefixes (read: `fixup! hell` will match the
      commit subject `hello world`), which means that we are stuck with
      quadratic performance in the worst case.
      
      The reimplemented logic also happens to fix a bug where commented-out
      lines (representing empty patches) were dropped by the previous code.
      
      While at it, clarify how the fixup/squash feature works in `git rebase
      -i`'s man page.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      c44a4c65
    • Johannes Schindelin's avatar
      rebase -i: skip unnecessary picks using the rebase--helper · cdac2b01
      Johannes Schindelin authored
      In particular on Windows, where shell scripts are even more expensive
      than on MacOSX or Linux, it makes sense to move a loop that forks
      Git at least once for every line in the todo list into a builtin.
      
      Note: The original code did not try to skip unnecessary picks of root
      commits but punts instead (probably --root was not considered common
      enough of a use case to bother optimizing). We do the same, for now.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      cdac2b01
    • Johannes Schindelin's avatar
      rebase -i: check for missing commits in the rebase--helper · 94399949
      Johannes Schindelin authored
      In particular on Windows, where shell scripts are even more expensive
      than on MacOSX or Linux, it makes sense to move a loop that forks
      Git at least once for every line in the todo list into a builtin.
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      94399949
    • Johannes Schindelin's avatar
      rebase -i: also expand/collapse the SHA-1s via the rebase--helper · 3546c8d9
      Johannes Schindelin authored
      This is crucial to improve performance on Windows, as the speed is now
      mostly dominated by the SHA-1 transformation (because it spawns a new
      rev-parse process for *every* line, and spawning processes is pretty
      slow from Git for Windows' MSYS2 Bash).
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      3546c8d9
    • Johannes Schindelin's avatar
      rebase -i: generate the script via rebase--helper · 62db5247
      Johannes Schindelin authored
      The first step of an interactive rebase is to generate the so-called "todo
      script", to be stored in the state directory as "git-rebase-todo" and to
      be edited by the user.
      
      Originally, we adjusted the output of `git log <options>` using a simple
      sed script. Over the course of the years, the code became more
      complicated. We now use shell scripting to edit the output of `git log`
      conditionally, depending whether to keep "empty" commits (i.e. commits
      that do not change any files).
      
      On platforms where shell scripting is not native, this can be a serious
      drag. And it opens the door for incompatibilities between platforms when
      it comes to shell scripting or to Unix-y commands.
      
      Let's just re-implement the todo script generation in plain C, using the
      revision machinery directly.
      
      This is substantially faster, improving the speed relative to the
      shell script version of the interactive rebase from 2x to 3x on Windows.
      
      Note that the rearrange_squash() function in git-rebase--interactive
      relied on the fact that we set the "format" variable to the config setting
      rebase.instructionFormat. Relying on a side effect like this is no good,
      hence we explicitly perform that assignment (possibly again) in
      rearrange_squash().
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      62db5247
  8. 09 Jan, 2017 2 commits
  9. 21 Oct, 2016 2 commits
  10. 17 Oct, 2016 2 commits
  11. 24 Oct, 2014 1 commit
  12. 27 Jan, 2014 1 commit
  13. 12 Feb, 2013 1 commit
  14. 16 Sep, 2012 1 commit
  15. 14 Sep, 2012 1 commit
    • Miklos Vajna's avatar
      cherry-pick: don't forget -s on failure · 5ed75e2a
      Miklos Vajna authored
      In case 'git cherry-pick -s <commit>' failed, the user had to use 'git
      commit -s' (i.e. state the -s option again), which is easy to forget
      about.  Instead, write the signed-off-by line early, so plain 'git
      commit' will have the same result.
      
      Also update 'git commit -s', so that in case there is already a relevant
      Signed-off-by line before the Conflicts: line, it won't add one more at
      the end of the message. If there is no such line, then add it before the
      the Conflicts: line.
      Signed-off-by: default avatarMiklos Vajna <vmiklos@suse.cz>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      5ed75e2a
  16. 06 Aug, 2012 1 commit
  17. 24 Apr, 2012 1 commit
    • Neil Horman (CI test user)'s avatar
      git-cherry-pick: Add keep-redundant-commits option · b27cfb0d
      Neil Horman (CI test user) authored
      The git-cherry-pick --allow-empty command by default only preserves empty
      commits that were originally empty, i.e only those commits for which
      <commit>^{tree} and <commit>^^{tree} are equal.  By default commits which are
      non-empty, but were made empty by the inclusion of a prior commit on the current
      history are filtered out.  This option allows us to override that behavior and
      include redundant commits as empty commits in the change history.
      
      Note that this patch changes the default behavior of git cherry-pick slightly.
      Prior to this patch all commits in a cherry-pick sequence were applied and git
      commit was run.  The implication here was that, if a commit was redundant, and
      the commit did not trigger the fast forward logic, the git commit operation, and
      therefore the git cherry-pick operation would fail, displaying the cherry pick
      advice (i.e. run git commit --allow-empty).  With this patch however, such
      redundant commits are automatically skipped without stopping, unless
      --keep-redundant-commits is specified, in which case, they are automatically
      applied as empty commits.
      Signed-off-by: Neil Horman (CI test user)'s avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      b27cfb0d
  18. 11 Apr, 2012 1 commit
  19. 12 Jan, 2012 1 commit
    • Ramkumar Ramachandra's avatar
      sequencer: factor code out of revert builtin · 043a4492
      Ramkumar Ramachandra authored
      Expose the cherry-picking machinery through a public
      sequencer_pick_revisions() (renamed from pick_revisions() in
      builtin/revert.c), so that cherry-picking and reverting are special
      cases of a general sequencer operation.  The cherry-pick builtin is
      now a thin wrapper that does command-line argument parsing before
      calling into sequencer_pick_revisions().  In the future, we can write
      a new "foo" builtin that calls into the sequencer like:
      
        memset(&opts, 0, sizeof(opts));
        opts.action = REPLAY_FOO;
        opts.revisions = xmalloc(sizeof(*opts.revs));
        parse_args_populate_opts(argc, argv, &opts);
        init_revisions(opts.revs);
        sequencer_pick_revisions(&opts);
      
      This patch does not intend to make any functional changes.  Check
      with:
      
        $ git blame -s -C HEAD^..HEAD -- sequencer.c | grep -C3 '^[^^]'
      Signed-off-by: default avatarRamkumar Ramachandra <artagnon@gmail.com>
      Reviewed-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      043a4492
  20. 12 Dec, 2011 1 commit
  21. 22 Nov, 2011 1 commit
    • Jonathan Nieder's avatar
      revert: rename --reset option to --quit · f80a8726
      Jonathan Nieder authored
      The option to "git cherry-pick" and "git revert" to discard the
      sequencer state introduced by v1.7.8-rc0~141^2~6 (revert: Introduce
      --reset to remove sequencer state, 2011-08-04) has a confusing name.
      Change it now, while we still have the time.
      
      The new name for "cherry-pick, please get out of my way, since I've
      long forgotten about the sequence of commits I was cherry-picking when
      you wrote that old .git/sequencer directory" is --quit.  Mnemonic:
      this is analagous to quiting a program the user is no longer using ---
      we just want to get out of the multiple-command cherry-pick procedure
      and not to reset HEAD or rewind any other old state.
      
      The "--reset" option is kept as a synonym to minimize the impact.  We
      might consider dropping it for simplicity in a separate patch, though.
      
      Adjust documentation and tests to use the newly preferred name (--quit)
      instead of --reset.  While at it, let's clarify the short descriptions
      of these operations in "-h" output.
      
      Before:
      
      	--reset		forget the current operation
      	--continue	continue the current operation
      
      After:
      
      	--quit		end revert or cherry-pick sequence
      	--continue	resume revert or cherry-pick sequence
      Noticed-by: Phil Hord's avatarPhil Hord <phil.hord@gmail.com>
      Signed-off-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      f80a8726
  22. 04 Aug, 2011 1 commit