From: Fabian Ruch <hidden> Date: 2016-06-15 23:01:41
Hi,
This patch series is part of the undertaking to add command line options
to to-do list commands. The goal is to be able to write something
similar to
pick --reset-author --signoff a Some changes
pick b Some more changes
squash --no-edit c Ack Some more changes.
The first submission to the mailing list adds options parsing to
`do_pick` and reimplements the current set of to-do list commands in
terms[1] of a parametrized `do_pick`. It neither adds new commands to
to-do lists nor exposes the command line options feature to the user.
Still it makes the implementation of `do_next` slightly more
straight-forward and the function `do_pick` behave more like an internal
git-cherry-pick.
The patches try to accomplish one thing at a time but are not standalone
in the sense that each of them constitutes a frame only in which a
subsequent patch can express its one thing. For instance, only
committing once and not dying in `do_pick` are things specific to
implementing `squash` in terms of `do_pick` but presented as separate
patches so that their correctness can be discussed independently.
The last patch contains some notes about when to run the post-rewrite
hook, something I could not figure out myself.
Thanks for your time,
Fabian
[1] pick, reword, squash, fixup
Fabian Ruch (7):
rebase -i: Make option handling in pick_one more flexible
rebase -i: Teach do_pick the option --edit
rebase -i: Stop on root commits with empty log messages
rebase -i: Commit only once when rewriting picks
rebase -i: Do not die in do_pick
rebase -i: Prepare for squash in terms of do_pick --amend
rebase -i: Teach do_pick the options --amend and --file
git-rebase--interactive.sh | 194 +++++++++++++++++++++++++++++++-----------
t/t3404-rebase-interactive.sh | 8 ++
t/t3412-rebase-root.sh | 39 +++++++++
3 files changed, 193 insertions(+), 48 deletions(-)
--
2.0.0
From: Fabian Ruch <hidden> Date: 2016-06-15 23:01:48
Hi,
this reroll applies the comments from Eric, Junio and Michael. In
particular,
* It turned out that `pick_one` does not need option handling at all
and the option-like argument `-n` determines whether `pick_one` or
`do_pick` creates the replay commit. The latter happens if the
task wants to rewrite the commit being picked (f.i., for the
purpose of editing the log message or resetting the authorship).
`do_pick` still seems to require a flexible parsing of options,
i.e. a relatively expensive loop, since it receives the
whitelisted user-supplied options. Unsupported and unknown options
are treated as an "unknown command" error.
* The `do_pick` options are documented in the same order they are
listed in the function signature. Moreover, it is mentioned which
options rewrite commits being picked.
* The test cases output differing actual values as changes to the
expected values and not the other way around. Moreover, the failed
rebases are not cleaned up until the respective test succeeds.
Two stages (and two sub-stages) can be identified in the rerolled
patch series:
1. Route primary to-do list commands through `do_pick`
a. Implement reword in terms of do_pick (5/19)
b. Implement squash in terms of do_pick (14/19)
2. Add user options to main commands
Enable options --signoff, --reset-author for pick, reword (19/19)
The last stage was added in this reroll. It enables the parsing of
line options for to-do list commands, which is still restricted to
options without arguments because it is unclear how spaces can be
parsed as characters rather than separators where needed. For
instance, if we were to support
pick --author="A U Thor" fa1afe1 Some changes
then read(1) would hand us the tokens `--author="A`, `U` and `Thor"`
instead of `--author=A U Thor`, which we would want to relay to
`do_pick`. Interpreting the shell quoting would help. However,
eval(1) seems to disqualify itself as an interpreter because the
to-do list entry could potentially contain any shell command line.
This could be both a security and a usability issue. For this reason,
the patch series still hasn't graduated from being RFC.
Fabian
Fabian Ruch (19):
rebase -i: Failed reword prints redundant error message
rebase -i: reword complains about empty commit despite --keep-empty
rebase -i: reword executes pre-commit hook on interim commit
rebase -i: Teach do_pick the option --edit
rebase -i: Implement reword in terms of do_pick
rebase -i: Stop on root commits with empty log messages
rebase -i: The replay of root commits is not shown with --verbose
rebase -i: Root commits are replayed with an unnecessary option
rebase -i: Commit only once when rewriting picks
rebase -i: Do not die in do_pick
rebase -i: Teach do_pick the option --amend
rebase -i: Teach do_pick the option --file
rebase -i: Prepare for squash in terms of do_pick --amend
rebase -i: Implement squash in terms of do_pick
rebase -i: Explicitly distinguish replay commands and exec tasks
rebase -i: Parse to-do list command line options
rebase -i: Teach do_pick the option --reset-author
rebase -i: Teach do_pick the option --signoff
rebase -i: Enable options --signoff, --reset-author for pick, reword
git-rebase--interactive.sh | 277 ++++++++++++++++++++++++++++++++++--------
t/t3404-rebase-interactive.sh | 8 ++
t/t3412-rebase-root.sh | 39 ++++++
3 files changed, 273 insertions(+), 51 deletions(-)
--
2.0.0
From: Fabian Ruch <hidden> Date: 2016-06-15 23:01:48
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. If the edited log
message is empty or is found ill-formatted by one of the commit
hooks, git-rebase--interactive prints three error messages to the
console.
1. The git-commit output, which contains all the output from hook
scripts.
2. A rebase diagnosis saying at which task on the to-do list it
got stuck.
3. Generic presumptions about what could have triggered the
error.
The third message contains redundant information and does not add any
enlightenment either, which makes the output unnecessarily longish
and different from the other command's output. For instance, this is
what the output looks like if the log message is empty (contains
duplicate Signed-off-by lines).
(1.) Aborting commit due to empty commit message. (Duplicate Signed-off-by lines.)
(2.) Could not amend commit after successfully picking fa1afe1... Some change
(3.) This is most likely due to an empty commit message, or the pre-commit hook
failed. If the pre-commit hook failed, you may need to resolve the issue before
you are able to reword the commit.
Discard the third message.
It is true that a failed hook script might not output any diagnosis
but then the generic message is not of much help either. Since this
lack of information affects the built-in git commands for commit,
merge and cherry-pick first, the solution would be to keep track of
the failed hooks in their output so that the user knows which of her
hooks require improvement.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 3 ---
1 file changed, 3 deletions(-)
@@ -506,9 +506,6 @@ do_next () {do_pick$sha1"$rest"gitcommit--amend--no-post-rewrite${gpg_sign_opt:+"$gpg_sign_opt"}||{warn"Could not amend commit after successfully picking $sha1... $rest"-warn"This is most likely due to an empty commit message, or the pre-commit hook"-warn"failed. If the pre-commit hook failed, you may need to resolve the issue before"-warn"you are able to reword the commit."exit_with_patch$sha11}record_in_rewritten$sha1
From: Fabian Ruch <hidden> Date: 2016-06-15 23:01:48
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. If `--keep-empty` is
passed as option to git-rebase--interactive, empty commits ought to
be replayed without complaints. However, if the users chooses to
reword an empty commit by changing the respective to-do list entry
from
pick fa1afe1 Empty commit
to
reword fa1afe1 Empty commit
, then git-rebase--interactive suddenly fails to replay the empty
commit. This is especially counterintuitive because `reword` is
thought of as a `pick` that alters the log message in some way but
nothing more and the unchanged to-do list entry would not fail.
Handle `reword` by cherry-picking the named commit and editing the
log message using
git commit --allow-empty --amend
instead of
git commit --amend.
Add test.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 2 +-
t/t3404-rebase-interactive.sh | 8 ++++++++
2 files changed, 9 insertions(+), 1 deletion(-)
From: Fabian Ruch <hidden> Date: 2016-06-15 23:01:48
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. This happens in two
steps. Firstly, the named commit is cherry-picked. Secondly, the
commit created in the first step is amended using an unchanged index
to edit the log message. The pre-commit hook is meant to verify the
changes introduced by a commit (for instance, catching inserted
trailing white space). Since the committed tree is not changed
between the two steps, do not execute the pre-commit hook in the
second step.
Specify the git-commit option `--no-verify` to disable the pre-commit
hook when editing the log message. Because `--no-verify` also skips
the commit-msg hook, execute the hook from within
git-rebase--interactive after the commit is created. Fortunately, the
commit message is still available in `$GIT_DIR/COMMIT_EDITMSG` after
git-commit terminates. Caveat: In case the commit-msg hook finds the
new log message ill-formatted, the user is only notified of the
failed commit-msg hook but the log message is used for the commit
anyway. git-commit ought to offer more fine-grained control over
which hooks are executed.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
@@ -504,10 +504,19 @@ do_next () {mark_action_donedo_pick$sha1"$rest"-gitcommit--allow-empty--amend--no-post-rewrite${gpg_sign_opt:+"$gpg_sign_opt"}||{-warn"Could not amend commit after successfully picking $sha1... $rest"-exit_with_patch$sha11-}+# TODO: Work around the fact that git-commit lets us+# disable either both the pre-commit and the commit-msg+# hook or none. Disable the pre-commit hook because the+# tree is left unchanged but run the commit-msg hook+# from here because the log message is altered.+gitcommit--allow-empty--amend--no-post-rewrite-n${gpg_sign_opt:+"$gpg_sign_opt"}&&+iftest-x"$GIT_DIR"/hooks/commit-msg+then+"$GIT_DIR"/hooks/commit-msg"$GIT_DIR"/COMMIT_EDITMSG+fi||{+warn"Could not amend commit after successfully picking $sha1... $rest"+exit_with_patch$sha11+}record_in_rewritten$sha1;;edit|e)
From: Fabian Ruch <hidden> Date: 2016-06-15 23:01:48
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement the to-do list command `pick`. To cater for
the different pick behaviours (like `reword`), `do_pick` accepts
several options not only from the git-cherry-pick but also the
git-commit interface. Add the common option `--edit` to let the user
edit the log message of the named commit.
Loop over `$@` to parse the `do_pick` arguments. Assign the local
variable `edit` if one of the options is `--edit` so that the
remainder of `do_pick` can easily check whether the client code asked
to edit the commit message. If one of the options is unknown, mention
it on the console and `die`. Break the loop on the first non-option
and do some sanity checking to ensure that there exactly two
non-options, which are interpreted by the remainder as `<commit>` and
`<title>` like before.
`do_pick` ought to act as a wrapper around `cherry-pick`.
Unfortunately, it cannot just forward `--edit` to the `cherry-pick`
command line. The assembled command line is executed within a command
substitution for controlling the verbosity of `rebase--interactive`.
Passing `--edit` would either hang the terminal or clutter the
substituted command output with control sequences. Execute the
`reword` code from `do_next` instead if the option `--edit` is
specified.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 52 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
@@ -461,7 +461,42 @@ record_in_rewritten() {esac}+# Apply the changes introduced by the given commit to the current head.+#+# do_pick [--edit] <commit> <title>+#+# Wrapper around git-cherry-pick.+#+# -e, --edit+# After picking <commit>, open an editor and let the user edit the+# commit message. The editor contents becomes the commit message of+# the new head. This creates a fresh commit.+#+# <commit>+# The commit to cherry-pick.+#+# <title>+# The commit message title of <commit>. Used for information+# purposes only. do_pick(){+edit=+whiletest$#-gt0+do+case"$1"in+-e|--edit)+edit=y+;;+-*)+die"do_pick: unrecognized option -- $1"+;;+*)+break+;;+esac+shift+done+test$#-ne2&&die"do_pick: wrong number of arguments"+iftest"$(gitrev-parseHEAD)"="$squash_onto"then# Set the correct commit message and author info on the
@@ -483,6 +518,23 @@ do_pick () {pick_one$1||die_with_patch$1"Could not apply $1... $2"fi++iftest-n"$edit"+then+# TODO: Work around the fact that git-commit lets us+# disable either both the pre-commit and the commit-msg+# hook or none. Disable the pre-commit hook because the+# tree is left unchanged but run the commit-msg hook+# from here because the log message is altered.+gitcommit--allow-empty--amend--no-post-rewrite-n${gpg_sign_opt:+"$gpg_sign_opt"}&&+iftest-x"$GIT_DIR"/hooks/commit-msg+then+"$GIT_DIR"/hooks/commit-msg"$GIT_DIR"/COMMIT_EDITMSG+fi||{+warn"Could not amend commit after successfully picking $1... $2"+exit_with_patch$11+}+fi} do_next(){
From: Fabian Ruch <hidden> Date: 2016-06-15 23:01:48
The options passed to `do_pick` determine whether the picked commit
will be rewritten or not. If the commit gets rewritten, because the
user requested to edit the commit message for instance, let
`pick_one` merely apply the changes introduced by the commit and do
not commit the resulting tree yet. If the commit is replayed as is,
leave it to `pick_one` to recreate the commit (possibly by
fast-forwarding the head). This makes it easier to combine git-commit
options like `--edit` and `--amend` in `do_pick` because
git-cherry-pick does not support `--amend`.
In the case of `--edit`, do not `exit_with_patch` but assign
`rewrite` to pick the changes with `-n`. If the pick conflicts, no
commit is created which we would have to amend when continuing the
rebase. To complete the pick after the conflicts are resolved the
user just resumes with `git rebase --continue`.
git-commit lets the user edit the commit log message by default. We
do not want that for the rewriting git-commit command line because
the default behaviour of git-cherry-pick is exactly the opposite.
Pass `--no-edit` when rewriting a picked commit. An explicit `--edit`
passed to `do_pick` (for instance, when reword is executed) enables
the editor launch again.
If `rebase--interactive` is used to rebase a complete branch onto
some head, `rebase` creates a sentinel commit that requires special
treatment by `do_pick`. Do not finalize the pick here either because
its commit message can be altered as for any other pick. Since the
orphaned root commit gets a temporary parent, it is always rewritten.
Safely use the rewrite infrastructure of `do_pick` to create the
final commit.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 55 +++++++++++++++++++++++++++-------------------
1 file changed, 33 insertions(+), 22 deletions(-)
@@ -63,7 +63,8 @@ msgnum="$state_dir"/msgnumauthor_script="$state_dir"/author-script# When an "edit" rebase command is being processed, the SHA1 of the-# commit to be edited is recorded in this file. When "git rebase+# commit to be edited is recorded in this file. The same happens when+# rewriting a commit fails, for instance "reword". When "git rebase# --continue" is executed, if there are any staged changes then they# will be amended to the HEAD commit, but only provided the HEAD# commit is still the commit to be edited. When any other rebase
@@ -479,12 +480,15 @@ record_in_rewritten() {# The commit message title of <commit>. Used for information# purposes only. do_pick(){-edit=+rewrite=+rewrite_amend=+rewrite_edit=whiletest$#-gt0docase"$1"in-e|--edit)-edit=y+rewrite=y+rewrite_edit=y;;-*)die"do_pick: unrecognized option -- $1"
@@ -499,6 +503,10 @@ do_pick () {iftest"$(gitrev-parseHEAD)"="$squash_onto"then+rewrite=y+rewrite_amend=y+gitrev-parse--verifyHEAD>"$amend"+# Set the correct commit message and author info on the# sentinel root before cherry-picking the original changes# without committing (-n). Finally, update the sentinel again
@@ -509,31 +517,34 @@ do_pick () {# rebase --continue.gitcommit--allow-empty--allow-empty-message--amend\--no-post-rewrite-n-q-C$1&&-pick_one-n$1&&-gitcommit--allow-empty\---amend--no-post-rewrite-n--no-edit\-${gpg_sign_opt:+"$gpg_sign_opt"}||+pick_one-n$1||die_with_patch$1"Could not apply $1... $2"else-pick_one$1||+pick_one${rewrite:+-n}$1||die_with_patch$1"Could not apply $1... $2"fi-iftest-n"$edit"+iftest-n"$rewrite"then-# TODO: Work around the fact that git-commit lets us-# disable either both the pre-commit and the commit-msg-# hook or none. Disable the pre-commit hook because the-# tree is left unchanged but run the commit-msg hook-# from here because the log message is altered.-gitcommit--allow-empty--amend--no-post-rewrite-n${gpg_sign_opt:+"$gpg_sign_opt"}&&-iftest-x"$GIT_DIR"/hooks/commit-msg-then-"$GIT_DIR"/hooks/commit-msg"$GIT_DIR"/COMMIT_EDITMSG-fi||{-warn"Could not amend commit after successfully picking $1... $2"-exit_with_patch$11-}+gitcommit--allow-empty--no-post-rewrite-n--no-edit\+${rewrite_amend:+--amend}\+${rewrite_edit:+--edit}\+${gpg_sign_opt:+"$gpg_sign_opt"}||+die_with_patch$1"Could not rewrite commit after successfully picking $1... $2"+fi++# TODO: Work around the fact that git-commit lets us+# disable either both the pre-commit and the commit-msg+# hook or none. Disable the pre-commit hook because the+# tree is left unchanged but run the commit-msg hook+# from here because the log message is altered.+iftest-n"$rewrite_edit"+then+iftest-x"$GIT_DIR"/hooks/commit-msg+then+"$GIT_DIR"/hooks/commit-msg"$GIT_DIR"/COMMIT_EDITMSG+fi||+die_with_patch$1"Could not rewrite commit after successfully picking $1... $2"fi}
From: Fabian Ruch <hidden> Date: 2016-06-15 23:01:48
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. If one thinks of `pick`
entries as scheduled `cherry-pick` command lines, then `reword`
becomes an alias for the command line `cherry-pick --edit`. The
porcelain `rebase--interactive` defines a function `do_pick` for
processing the `pick` entries on to-do lists. Reimplement `reword` in
terms of `do_pick --edit`.
If the user picks a commit using the to-do list line
reword fa1afe1 Some change
execute the command `do_pick --edit fa1afe1 "Some change"` which
carries out exactly the same steps as the case arm for `reword` in
`do_next` so far.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 15 +--------------
1 file changed, 1 insertion(+), 14 deletions(-)
@@ -555,20 +555,7 @@ do_next () {comment_for_reflogrewordmark_action_done-do_pick$sha1"$rest"-# TODO: Work around the fact that git-commit lets us-# disable either both the pre-commit and the commit-msg-# hook or none. Disable the pre-commit hook because the-# tree is left unchanged but run the commit-msg hook-# from here because the log message is altered.-gitcommit--allow-empty--amend--no-post-rewrite-n${gpg_sign_opt:+"$gpg_sign_opt"}&&-iftest-x"$GIT_DIR"/hooks/commit-msg-then-"$GIT_DIR"/hooks/commit-msg"$GIT_DIR"/COMMIT_EDITMSG-fi||{-warn"Could not amend commit after successfully picking $sha1... $rest"-exit_with_patch$sha11-}+do_pick--edit$sha1"$rest"record_in_rewritten$sha1;;edit|e)
From: Fabian Ruch <hidden> Date: 2016-06-15 23:01:48
The command line used to recreate root commits specifies the
erroneous option `--allow-empty-message`. If the root commit has an
empty log message, the replay of this commit should fail and the
rebase should be interrupted like for any other commit that is on the
to-do list and has an empty commit message. Remove the option.
The option might have been introduced by copy-and-paste of the first
part of the command line which initializes the authorship of the
sentinel commit. Indeed, the sentinel commit has an empty log message
and this should not trigger a failure, which is why the option
`--allow-empty-message` is correctly specified here.
Add test.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 2 +-
t/t3412-rebase-root.sh | 39 +++++++++++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+), 1 deletion(-)
@@ -278,4 +278,43 @@ test_expect_success 'rebase -i -p --root with conflict (second part)' 'test_cmpexpect-conflict-pout'+test_expect_success'stop rebase --root on empty root log message''+# create a root commit with a non-empty tree so that rebase does+# not fail because of an empty commit, and an empty log message+echoroot-commit>file&&+gitaddfile&&+tree=$(gitwrite-tree)&&+root=$(gitcommit-tree$tree</dev/null)&&+gitcheckout-bno-message-root-commit$root&&+# do not ff because otherwise neither the patch nor the message+# are looked at and checked for emptiness+test_when_finishedgitrebase--abort&&+test_must_failenvEDITOR=truegitrebase-i--force-rebase--root&&+echoroot-commit>file.expected&&+test_cmpfile.expectedfile+'++test_expect_success'stop rebase --root on empty child log message''+# create a root commit with a non-empty tree and provide a log+# message so that rebase does not fail until the root commit is+# successfully replayed+echoroot-commit>file&&+gitaddfile&&+tree=$(gitwrite-tree)&&+root=$(gitcommit-tree$tree-mroot-commit)&&+gitcheckout-bno-message-child-commit$root&&+# create a child commit with a non-empty patch so that rebase+# does not fail because of an empty commit, but an empty log+# message+echochild-commit>file&&+gitaddfile&&+gitcommit--allow-empty-message--no-edit&&+# do not ff because otherwise neither the patch nor the message+# are looked at and checked for emptiness+test_when_finishedgitrebase--abort&&+test_must_failenvEDITOR=truegitrebase-i--force-rebase--root&&+echochild-commit>file.expected&&+test_cmpfile.expectedfile+'+ test_done
From: Fabian Ruch <hidden> Date: 2016-06-15 23:01:48
Since `do_pick` might be executed in a sub-shell (a modified author
environment for instance), calling `die` in `do_pick` has no effect
but exiting the sub-shell with a failure exit status. The
git-rebase--interactive script is not terminated. Moreover, if
`do_pick` is called while a squash or fixup is in effect,
`die_with_patch` will discard `$squash_msg` as commit message.
Lastly, after a `die` in `do_pick` `do_next` has no chance to
reschedule tasks that failed before changes could be applied.
Indicate an error in `do_pick` using return statements and properly
kill the script at the call sites. Although possible in principle,
the issued error messages are no more indicating whether `do_pick`
failed while applying or while committing the changes. This reduces
code complexity at the call site and does not matter from a user's
point of view because a glance at the index reveals whether there are
conflicts or not and in-depth troubleshooting is still possible using
the `--verbose` option.
Remove the commit message title argument from `do_pick`'s interface,
which has become unused.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 37 ++++++++++++++++++++-----------------
1 file changed, 20 insertions(+), 17 deletions(-)
@@ -464,7 +464,7 @@ record_in_rewritten() {# Apply the changes introduced by the given commit to the current head.#-# do_pick [--edit] <commit> <title>+# do_pick [--edit] <commit>## Wrapper around git-cherry-pick.#
@@ -476,9 +476,11 @@ record_in_rewritten() {# <commit># The commit to cherry-pick.#-# <title>-# The commit message title of <commit>. Used for information-# purposes only.+# The return value is 1 if applying the changes resulted in a conflict+# and 2 if the specified arguments were incorrect. If the changes could+# be applied successfully but creating the commit failed, a value+# greater than 2 is returned. No commit is created in either case and+# the index is left with the (conflicting) changes in place. do_pick(){rewrite=rewrite_amend=
@@ -499,7 +502,11 @@ do_pick () {esacshiftdone-test$#-ne2&&die"do_pick: wrong number of arguments"+iftest$#-ne1+then+warn"do_pick: wrong number of arguments"+return2+fiiftest"$(gitrev-parseHEAD)"="$squash_onto"then
@@ -517,11 +524,9 @@ do_pick () {# rebase --continue.gitcommit--allow-empty--allow-empty-message--amend\--no-post-rewrite-n-q-C$1&&-pick_one-n$1||-die_with_patch$1"Could not apply $1... $2"+pick_one-n$1||return1else-pick_one${rewrite:+-n}$1||-die_with_patch$1"Could not apply $1... $2"+pick_one${rewrite:+-n}$1||return1fiiftest-n"$rewrite"
@@ -529,8 +534,7 @@ do_pick () {gitcommit--allow-empty--no-post-rewrite-n--no-edit\${rewrite_amend:+--amend}\${rewrite_edit:+--edit}\-${gpg_sign_opt:+"$gpg_sign_opt"}||-die_with_patch$1"Could not rewrite commit after successfully picking $1... $2"+${gpg_sign_opt:+"$gpg_sign_opt"}||return3fi# TODO: Work around the fact that git-commit lets us
@@ -543,8 +547,7 @@ do_pick () {iftest-x"$GIT_DIR"/hooks/commit-msgthen"$GIT_DIR"/hooks/commit-msg"$GIT_DIR"/COMMIT_EDITMSG-fi||-die_with_patch$1"Could not rewrite commit after successfully picking $1... $2"+fi||return3fi}
@@ -559,21 +562,21 @@ do_next () {comment_for_reflogpickmark_action_done-do_pick$sha1"$rest"+do_pick$sha1||die_with_patch$sha1"Could not apply $sha1... $rest"record_in_rewritten$sha1;;reword|r)comment_for_reflogrewordmark_action_done-do_pick--edit$sha1"$rest"+do_pick--edit$sha1||die_with_patch$sha1"Could not apply $sha1... $rest"record_in_rewritten$sha1;;edit|e)comment_for_reflogeditmark_action_done-do_pick$sha1"$rest"+do_pick$sha1||die_with_patch$sha1"Could not apply $sha1... $rest"warn"Stopped at $sha1... $rest"exit_with_patch$sha10;;
From: Fabian Ruch <hidden> Date: 2016-06-15 23:01:48
The command line used to recreate root commits specifies the
erroneous option `-q` which suppresses the commit summary message.
However, git-rebase--interactive tends to tell the user about the
commits it creates, if she wishes (cf. command line option
`--verbose`). The code parts handling non-root commits or squash
commits all output commit summary messages. Do not make the replay of
root commits an exception. Remove the option.
It is OK to suppress the commit summary when git-commit is used to
initialize the authorship of the sentinel commit because the
existence of this additional commit is a detail of
git-rebase--interactive's implementation. The option `-q` was
probably introduced as a copy-and-paste error stemming from that part
of the root commit handling code.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Fabian Ruch <hidden> Date: 2016-06-15 23:01:48
The command line used to recreate root commits specifies the
effectless option `-C`. It is used to reuse commit message and
authorship from the named commit but the commit being amended here,
which is the sentinel commit, already carries the authorship and log
message of the processed commit. Note that the committer email and
commit date fields do not match the root commit either way. Remove
the option. However, `-C` (other than `-c`) does not invoke the
editor and the `--amend` option invokes it by default. Disable editor
invocation again by specifying `--no-edit`.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Fabian Ruch <hidden> Date: 2016-06-15 23:01:48
There are two kinds of to-do list commands available. One kind
replays a commit (`pick`, `reword`, `edit`, `squash` and `fixup` that
is) and the other executes a shell command (`exec`). We will call the
first kind replay commands.
The two kinds of tasks are scheduled using different line formats.
Replay commands expect a commit hash argument following the command
name and exec concatenates all arguments to assemble a command line.
Adhere to the distinction of formats by not trying to parse the
`sha1` field unless we are dealing with a replay command. Move the
replay command handling code to a new function `do_replay` which
assumes the first argument to be a commit hash and make no more such
assumptions in `do_next`.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 42 ++++++++++++++++++++++++++++--------------
1 file changed, 28 insertions(+), 14 deletions(-)
@@ -656,6 +655,28 @@ do_next () {esacrecord_in_rewritten$sha1;;+*)+read-rcommand<"$todo"+warn"Unknown command: $command"+fixtodo="Please fix this using 'git rebase --edit-todo'."+ifgitrev-parse--verify-q"$sha1">/dev/null+then+die_with_patch$sha1"$fixtodo"+else+die"$fixtodo"+fi+;;+esac+}++do_next(){+rm-f"$msg""$author_script""$amend"||exit+read-rcommandsha1rest<"$todo"++case"$command"in+"$comment_char"*|''|noop)+mark_action_done+;;x|"exec")read-rcommandrest<"$todo"mark_action_done
@@ -695,14 +716,7 @@ do_next () {fi;;*)-warn"Unknown command: $command$sha1$rest"-fixtodo="Please fix this using 'git rebase --edit-todo'."-ifgitrev-parse--verify-q"$sha1">/dev/null-then-die_with_patch$sha1"$fixtodo"-else-die"$fixtodo"-fi+do_replay$command$sha1"$rest";;esactest-s"$todo"&&return
From: Fabian Ruch <hidden> Date: 2016-06-15 23:01:48
pick and reword are atomic to-do list commands in the sense that they
open a new task which is closed after the respective command is
completed. squash and fixup are not atomic. They create a new task
which is not completed until the last squash or fixup is processed.
Lift the general unknown option blockade for the pick and reword
commands. If `do_cmd` comes across one of the options `--signoff` and
`--reset-author` while parsing a to-do entry and the scheduled
command is either `pick` or `reword`, relay the option to `do_pick`.
The `do_pick` options `--gpg-sign` and `--file` are not yet supported
because `do_cmd` cannot handle option arguments and options with
spaces at the moment. It is true that edit is one of the atomic
commands but it displays hash information when the rebase is stopped
and some options rewrite the picked commit which alters that
information. squash and fixup still do not accept user options as the
interplay of `--reset-author` and the author script are yet to be
determined.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
@@ -644,21 +654,24 @@ do_replay () {comment_for_reflogpickmark_action_done-do_pick$sha1||die_with_patch$sha1"Could not apply $sha1... $rest"+evaldo_pick$opts$sha1\+||die_with_patch$sha1"Could not apply $sha1... $rest"record_in_rewritten$sha1;;reword|r)comment_for_reflogrewordmark_action_done-do_pick--edit$sha1||die_with_patch$sha1"Could not apply $sha1... $rest"+evaldo_pick--edit$opts$sha1\+||die_with_patch$sha1"Could not apply $sha1... $rest"record_in_rewritten$sha1;;edit|e)comment_for_reflogeditmark_action_done-do_pick$sha1||die_with_patch$sha1"Could not apply $sha1... $rest"+evaldo_pick$opts$sha1\+||die_with_patch$sha1"Could not apply $sha1... $rest"warn"Stopped at $sha1... $rest"exit_with_patch$sha10;;
From: Fabian Ruch <hidden> Date: 2016-06-15 23:01:48
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement many of the to-do list commands.
Eventually, the complete `do_pick` interface will be exposed to the
user in some form or another and those commands will become simple
aliases for the `do_pick` options now used to implement them.
Add the git-commit option `--reset-author` to the options pool of
`do_pick`. It rewrites the author date and name of the picked commit
to match the committer date and name.
If `--reset-author` is passed to `do_pick`, set the `rewrite` flag
and relay the option to the git-commit command line which creates the
final commit. If `--amend` is not passed as well, the fresh
authorship effect is achieved by the mere fact that we are creating a
new commit.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
@@ -464,10 +464,18 @@ record_in_rewritten() {# Apply the changes introduced by the given commit to the current head.#-# do_pick [--amend] [--file <file>] [--edit] <commit>+# do_pick [--reset-author] [--amend] [--file <file>] [--edit] <commit>## Wrapper around git-cherry-pick.#+# --reset-author+# Pretend the changes were made for the first time. Declare that the+# authorship of the resulting commit now belongs to the committer.+# This also renews the author timestamp. This creates a fresh+# commit.+#+# _This is not a git-cherry-pick option._+## --amend# After picking <commit>, replace the current head commit with a new# commit that also introduces the changes of <commit>.
@@ -562,12 +574,21 @@ do_pick () {pick_one${rewrite:+-n}$1||return1fi+iftest-n"$rewrite_author"&&test-z"$rewrite_amend"+then+# keep rewrite flag to create a new commit, rewrite+# without --reset-author though because it can only be+# used with -C, -c or --amend+rewrite_author=+fi+iftest-n"$rewrite"thengitcommit--allow-empty--no-post-rewrite-n--no-edit\${rewrite_amend:+--amend}\${rewrite_edit:+--edit}\${rewrite_message:+--file "$rewrite_message"}\+${rewrite_author:+--reset-author}\${gpg_sign_opt:+"$gpg_sign_opt"}||return3fi
From: Fabian Ruch <hidden> Date: 2016-06-15 23:01:48
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is currently used to implement most of the to-do list commands
and offers additional options that will eventually find their way
onto to-do lists.
To extend the repertoire of available options, add the git-commit and
git-cherry-pick option `--signoff` to the `do_pick` interface. It
appends a Signed-off-by: line using the committer identity to the log
message of the picked commit.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
@@ -464,10 +464,15 @@ record_in_rewritten() {# Apply the changes introduced by the given commit to the current head.#-# do_pick [--reset-author] [--amend] [--file <file>] [--edit] <commit>+# do_pick [--signoff] [--reset-author] [--amend] [--file <file>]+# [--edit] <commit>## Wrapper around git-cherry-pick.#+# -s, --signoff+# Insert a Signed-off-by: line using the committer identity at the+# end of the commit log message. This creates a fresh commit.+## --reset-author# Pretend the changes were made for the first time. Declare that the# authorship of the resulting commit now belongs to the committer.
From: Fabian Ruch <hidden> Date: 2016-06-15 23:01:48
Read in to-do list lines as
command args
instead of
command sha1 rest
so that to-do list command lines can specify additional arguments
apart from the commit hash and the log message title, which become
the non-options in `args`. Loop over `args`, put all options (an
argument beginning with a dash) in `opts`, stop the loop on the first
non-option and assign it to `sha1`. The loop does not know the
options it parses so that options that take an argument themselves
are not supported at the moment. Neither are options that contain
spaces because the shell expansion of `args` in `do_next` interprets
white space characters as argument separator, that is a command line
like
pick --author "A U Thor" fa1afe1 Some change
is parsed as the pick command
pick --author
and the commit hash
"A
which obviously results in an unknown revision error. For the sake of
completeness, in the example above the message title variable `rest`
is assigned the string 'U Thor" fa1afe1 Some change' (without the
single quotes).
Print an error message for unknown or unsupported command line
options, which means an error for all specified options at the
moment. Cleanly break the `do_next` loop by assigning the special
value 'unknown' to the local variable `command`, which triggers the
unknown command case in `do_cmd`.
The to-do list is also parsed when the commit hashes are translated
between long and short format before and after the to-do list is
edited. Apply the same procedure as in `do_cmd` with the exception
that we only care about where the options stop and the commit hash
begins. Do not reject any options when transforming the commit
hashes.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 49 ++++++++++++++++++++++++++++++++++++++--------
1 file changed, 41 insertions(+), 8 deletions(-)
@@ -796,19 +814,34 @@ skip_unnecessary_picks () {} transform_todo_ids(){-whileread-rcommandrest+whileread-rcommandargsdocase"$command"in"$comment_char"*|exec)# Be careful for oddball commands like 'exec'# that do not have a SHA-1 at the beginning of $rest.+newargs=\ $args;;*)-sha1=$(gitrev-parse--verify--quiet"$@"${rest%% *})&&-rest="$sha1${rest#* }"+newargs=+sha1=+forargin$args+do+case"$arg"in+-*)+newargs="$newargs$arg"+;;+*)+test-z"$sha1"&&+sha1=$(gitrev-parse--verify--quiet"$@"$arg)&&+arg=$sha1+newargs="$newargs$arg"+;;+esac+done;;esac-printf'%s\n'"$command${rest:+ }$rest"+printf'%s\n'"$command$newargs"done<"$todo">"$todo.new"&&mv-f"$todo.new""$todo"}
From: Fabian Ruch <hidden> Date: 2016-06-15 23:01:48
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement the to-do list commands `pick`, `reword`
and `edit`. To cater for the different pick behaviours (like
`squash`), `do_pick` accepts several options not only from the
git-cherry-pick but also the git-commit interface.
Add the option `--amend` from the git-commit interface to the options
pool of `do_pick`. It creates a new commit for the changes introduced
by the picked commit and the previous one. The previous commit is
then replaced with the new commit. If no other options are specified,
the log message of the previous commit is used.
Be careful when `--amend` is used to pick a root commit because HEAD
might point to the sentinel commit but there is still nothing to
amend. Be sure to initialize `amend` so that commits are squashed
even when git-rebase--interactive is interrupted for resolving
conflicts. It is not a mistake to do the initialization regardless of
any conflicts because `amend` is always cleared before the next to-do
item is processed.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
@@ -464,10 +464,16 @@ record_in_rewritten() {# Apply the changes introduced by the given commit to the current head.#-# do_pick [--edit] <commit>+# do_pick [--amend] [--edit] <commit>## Wrapper around git-cherry-pick.#+# --amend+# After picking <commit>, replace the current head commit with a new+# commit that also introduces the changes of <commit>.+#+# _This is not a git-cherry-pick option._+## -e, --edit# After picking <commit>, open an editor and let the user edit the# commit message. The editor contents becomes the commit message of
@@ -488,6 +494,16 @@ do_pick () {whiletest$#-gt0docase"$1"in+--amend)+iftest"$(gitrev-parseHEAD)"="$squash_onto"||!gitrev-parse--verifyHEAD+then+warn"do_pick: nothing to amend"+return2+fi+rewrite=y+rewrite_amend=y+gitrev-parse--verifyHEAD>"$amend"+;;-e|--edit)rewrite=yrewrite_edit=y
From: Fabian Ruch <hidden> Date: 2016-06-15 23:01:48
Rewrite `squash` and `fixup` handling in `do_next` using the sequence
pick_one
commit
in order to test the correctness of a single `do_squash` or
parameterised `do_pick` and make the subsequent patch reimplementing
`squash` in terms of such a single function more readable.
Do not call `rm -f "$GIT_DIR"/MERGE_MSG` since it has no effect on
the state after git-rebase--interactive terminates. The option `-F`
makes git-commit ignore `MERGE_MSG` for the log message. If
git-commit succeeds, `MERGE_MSG` is removed, and if it fails,
`MERGE_MSG` is overwritten by the error sequence `die_failed_squash`.
In summary, removing `MERGE_MSG` neither influences the squash commit
message nor the file state after git-commit returns.
Moreover, `pick_one` ignores `$GIT_DIR/SQUASH_MSG` and does not touch
`$squash_msg` so that it is correct to execute `pick_one` immediately
before git-commit.
Might be squashed into the subsequent commit.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 21 +++++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
@@ -633,15 +633,15 @@ do_next () {author_script_content=$(get_author_ident_from_commitHEAD)echo"$author_script_content">"$author_script"eval"$author_script_content"-if!pick_one-n$sha1-then-gitrev-parse--verifyHEAD>"$amend"-die_failed_squash$sha1"$rest"-ficase"$(peek_next_command)"insquash|s|fixup|f)# This is an intermediate commit; its message will only be# used in case of trouble. So use the long version:+if!pick_one-n$sha1+then+gitrev-parse--verifyHEAD>"$amend"+die_failed_squash$sha1"Could not apply $sha1... $rest"+fido_with_authoroutputgitcommit--amend--no-verify-F"$squash_msg"\${gpg_sign_opt:+"$gpg_sign_opt"}||die_failed_squash$sha1"$rest"
@@ -650,12 +650,21 @@ do_next () {# This is the final command of this squash/fixup groupiftest-f"$fixup_msg"then+if!pick_one-n$sha1+then+gitrev-parse--verifyHEAD>"$amend"+die_failed_squash$sha1"Could not apply $sha1... $rest"+fido_with_authorgitcommit--amend--no-verify-F"$fixup_msg"\${gpg_sign_opt:+"$gpg_sign_opt"}||die_failed_squash$sha1"$rest"elsecp"$squash_msg""$GIT_DIR"/SQUASH_MSG||exit-rm-f"$GIT_DIR"/MERGE_MSG+if!pick_one-n$sha1+then+gitrev-parse--verifyHEAD>"$amend"+die_failed_squash$sha1"Could not apply $sha1... $rest"+fido_with_authorgitcommit--amend--no-verify-F"$GIT_DIR"/SQUASH_MSG-e\${gpg_sign_opt:+"$gpg_sign_opt"}||die_failed_squash$sha1"$rest"
From: Fabian Ruch <hidden> Date: 2016-06-15 23:01:48
The to-do list command `squash` and its close relative `fixup` replay
the changes of a commit like `pick` but do not recreate the commit.
Instead they replace the previous commit with a new commit that also
introduces the changes of the squashed commit. This is roughly like
cherry-picking without committing and using git-commit to amend the
previous commit.
The to-do list
pick a Some changes
squash b Some more changes
gets translated into the sequence of git commands
git cherry-pick a
git cherry-pick -n b
git commit --amend
and if git-cherry-pick supported `--amend` this would look even more
like the to-do list it is based on
git cherry-pick a
git cherry-pick --amend b.
Since `do_pick` takes care of `pick` entries and the above suggests
`squash` as an alias for `pick --amend`, reimplement `squash` in
terms of `do_pick --amend`. Introduce `$squash_msg` as the commit
message via the `--file` option. When the last commit of a squash
series is processed, the user is asked to review the log message.
Pass `--edit` as additional option in this case. The only difference
in the options passed to git-commit and `do_pick` is the omitted
`--no-verify`. However, `do_pick` does not execute the verification
hooks anyway because it solely replays commits and assumes that they
have been verified before.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 30 ++++++------------------------
1 file changed, 6 insertions(+), 24 deletions(-)
@@ -637,37 +637,19 @@ do_next () {squash|s|fixup|f)# This is an intermediate commit; its message will only be# used in case of trouble. So use the long version:-if!pick_one-n$sha1-then-gitrev-parse--verifyHEAD>"$amend"-die_failed_squash$sha1"Could not apply $sha1... $rest"-fi-do_with_authoroutputgitcommit--amend--no-verify-F"$squash_msg"\-${gpg_sign_opt:+"$gpg_sign_opt"}||-die_failed_squash$sha1"$rest"+do_with_authordo_pick--amend-F"$squash_msg"$sha1\+||die_failed_squash$sha1"Could not apply $sha1... $rest";;*)# This is the final command of this squash/fixup groupiftest-f"$fixup_msg"then-if!pick_one-n$sha1-then-gitrev-parse--verifyHEAD>"$amend"-die_failed_squash$sha1"Could not apply $sha1... $rest"-fi-do_with_authorgitcommit--amend--no-verify-F"$fixup_msg"\-${gpg_sign_opt:+"$gpg_sign_opt"}||-die_failed_squash$sha1"$rest"+do_with_authordo_pick--amend-F"$fixup_msg"$sha1\+||die_failed_squash$sha1"Could not apply $sha1... $rest"elsecp"$squash_msg""$GIT_DIR"/SQUASH_MSG||exit-if!pick_one-n$sha1-then-gitrev-parse--verifyHEAD>"$amend"-die_failed_squash$sha1"Could not apply $sha1... $rest"-fi-do_with_authorgitcommit--amend--no-verify-F"$GIT_DIR"/SQUASH_MSG-e\-${gpg_sign_opt:+"$gpg_sign_opt"}||-die_failed_squash$sha1"$rest"+do_with_authordo_pick--amend-F"$GIT_DIR"/SQUASH_MSG-e$sha1\+||die_failed_squash$sha1"Could not apply $sha1... $rest"firm-f"$squash_msg""$fixup_msg";;
From: Fabian Ruch <hidden> Date: 2016-06-15 23:01:48
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement the to-do list command `pick`, `reword` and
`edit`. To cater for the different pick behaviours (like `squash`),
`do_pick` accepts several options not only from the git-cherry-pick
but also the git-commit interface.
Add the option `--file` from the git-commit interface to the options
pool of `do_pick`. It expects an argument itself which is interpreted
as a file path and takes the commit message from the given file. If
`--file` is passed to `do_pick`, assign the given file path to the
local variable `rewrite_message` and relay the option
--file "$rewrite_message"
to the git-commit command line which creates the commit.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
@@ -464,7 +464,7 @@ record_in_rewritten() {# Apply the changes introduced by the given commit to the current head.#-# do_pick [--amend] [--edit] <commit>+# do_pick [--amend] [--file <file>] [--edit] <commit>## Wrapper around git-cherry-pick.#
@@ -474,6 +474,12 @@ record_in_rewritten() {## _This is not a git-cherry-pick option._#+# -F <file>, --file <file>+# Take the commit message from the given file. This creates a fresh+# commit.+#+# _This is not a git-cherry-pick option._+## -e, --edit# After picking <commit>, open an editor and let the user edit the# commit message. The editor contents becomes the commit message of
From: Michael Haggerty <hidden> Date: 2016-06-15 23:01:48
On 07/02/2014 07:47 PM, Fabian Ruch wrote:
[...]
2. Add user options to main commands
Enable options --signoff, --reset-author for pick, reword (19/19)
The last stage was added in this reroll. It enables the parsing of
line options for to-do list commands, which is still restricted to
options without arguments because it is unclear how spaces can be
parsed as characters rather than separators where needed. For
instance, if we were to support
pick --author="A U Thor" fa1afe1 Some changes
then read(1) would hand us the tokens `--author="A`, `U` and `Thor"`
instead of `--author=A U Thor`, which we would want to relay to
`do_pick`. Interpreting the shell quoting would help. However,
eval(1) seems to disqualify itself as an interpreter because the
to-do list entry could potentially contain any shell command line.
This could be both a security and a usability issue. For this reason,
the patch series still hasn't graduated from being RFC.
[...]
It is not required that a patch series solves all of the problems in the
universe. If these patches implements some useful features robustly,
and if there is no reason to expect that future enhancements will
require the user interface to be changed in a backwards-compatible way,
then there is no reason that this patch series has to be held as an RFC
hostage to some hypothetical future.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
From: Fabian Ruch <hidden> Date: 2016-06-15 23:01:52
Hi Chris,
you're the original author of the code touched by this patch. Is the
second -q option really a simple copy-and-paste of the first or am I
overlooking something here? I'd like to confirm this as, in retrospect,
I feel a bit uncertain about the hasty claim in the log message.
Kind regards,
Fabian
Fabian Ruch writes:
quoted hunk
The command line used to recreate root commits specifies the
erroneous option `-q` which suppresses the commit summary message.
However, git-rebase--interactive tends to tell the user about the
commits it creates, if she wishes (cf. command line option
`--verbose`). The code parts handling non-root commits or squash
commits all output commit summary messages. Do not make the replay of
root commits an exception. Remove the option.
It is OK to suppress the commit summary when git-commit is used to
initialize the authorship of the sentinel commit because the
existence of this additional commit is a detail of
git-rebase--interactive's implementation. The option `-q` was
probably introduced as a copy-and-paste error stemming from that part
of the root commit handling code.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Chris Webb <hidden> Date: 2016-06-15 23:01:55
Fabian Ruch [off-list ref] wrote:
you're the original author of the code touched by this patch. Is the
second -q option really a simple copy-and-paste of the first or am I
overlooking something here? I'd like to confirm this as, in retrospect,
I feel a bit uncertain about the hasty claim in the log message.
It was a while ago and I don't remember the details of this patch I'm
afraid, but your rationale here looks sensible to me. I tend to find git too
noisy by default rather than too quiet, so it wouldn't surprise me if I
never thought to try the --verbose version.
Cheers,
Chris.
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:03
Hi,
this is a reroll of the patch series that enables rudimentary support
of line options for git-rebase's to-do list commands and reimplements
the well-known commands `reword` and `squash` in terms of a
parameterised `do_pick`.
I tried to address all the issues raised by Junio in this reroll.
Here is a short summary.
- Test that `reword` behaves like `pick` regarding the `pre-commit`
hook and executes `commit-msg` for the new log message.
- Instead of disallowing empty log messages for root commits allow
empty log messages for all unchanged commits.
- The patch "root commits are replayed with an unnecessary option"
does not change the behaviour of git-rebase but it makes the
subsequent patch easier to read.
The hidden agenda is to have one git-commit command line in
`do_pick` that takes care of rewriting commits as they are being
replayed, be they parentless or not. The advantage of having one
rewrite command instead of one for root commits and one for
non-root commits is that changes to the rewrite mechanism entail
less code changes. As more rewriting mechanisms are being added to
`do_pick`, it becomes important that they compose well with each
other to avoid having a series of amending commits. The `-C`
option conflicts with other ways of substituting the log message,
like files and strings, which is why it seems not to compose so
well.
- The patch "explicitly distinguish replay commands and exec tasks"
does not change behaviour either but is again a separated
refactoring patch.
The distinction of the `exec` command and the replay commands,
which all share the same line format `command args sha1 rest`,
allows us to employ the positional parameters feature of the shell
without introducing another indentation level in `do_pick`.
Thanks for your time,
Fabian
Fabian Ruch (19):
rebase -i: failed reword prints redundant error message
rebase -i: allow rewording an empty commit without complaints
rebase -i: reword executes pre-commit hook on interim commit
rebase -i: teach do_pick the option --edit
rebase -i: implement reword in terms of do_pick
rebase -i: allow replaying commits with empty log messages
rebase -i: log the replay of root commits
rebase -i: root commits are replayed with an unnecessary option
rebase -i: commit only once when rewriting picks
rebase -i: do not die in do_pick
rebase -i: teach do_pick the option --amend
rebase -i: teach do_pick the option --file
rebase -i: prepare for squash in terms of do_pick --amend
rebase -i: implement squash in terms of do_pick
rebase -i: explicitly distinguish replay commands and exec tasks
rebase -i: parse to-do list command line options
rebase -i: teach do_pick the option --reset-author
rebase -i: teach do_pick the option --signoff
rebase -i: enable options --signoff, --reset-author for pick, reword
git-rebase--interactive.sh | 284 ++++++++++++++++++++++++++++++++++--------
t/t3404-rebase-interactive.sh | 70 +++++++++++
t/t3412-rebase-root.sh | 19 +++
t/test-lib-functions.sh | 6 +-
4 files changed, 325 insertions(+), 54 deletions(-)
--
2.0.1
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:03
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. If the edited log
message is empty or is found ill-formatted by one of the commit
hooks, git-rebase--interactive prints three error messages to the
console.
1. The git-commit output, which contains all the output from hook
scripts.
2. A rebase diagnosis saying at which task on the to-do list it
got stuck.
3. Generic presumptions about what could have triggered the
error.
The third message contains redundant information and does not add any
enlightenment either, which makes the output unnecessarily longish
and different from the other command's output. For instance, this is
what the output looks like if the log message is empty (contains
duplicate Signed-off-by lines).
(1.) Aborting commit due to empty commit message. (Duplicate Signed-off-by lines.)
(2.) Could not amend commit after successfully picking fa1afe1... Some change
(3.) This is most likely due to an empty commit message, or the pre-commit hook
failed. If the pre-commit hook failed, you may need to resolve the issue before
you are able to reword the commit.
Discard the third message.
It is true that a failed hook script might not output any diagnosis
but then the generic message is not of much help either. Since this
lack of information affects the built-in git commands for commit,
merge and cherry-pick first, the solution would be to keep track of
the failed hooks in their output so that the user knows which of her
hooks require improvement.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 3 ---
1 file changed, 3 deletions(-)
@@ -506,9 +506,6 @@ do_next () {do_pick$sha1"$rest"gitcommit--amend--no-post-rewrite${gpg_sign_opt:+"$gpg_sign_opt"}||{warn"Could not amend commit after successfully picking $sha1... $rest"-warn"This is most likely due to an empty commit message, or the pre-commit hook"-warn"failed. If the pre-commit hook failed, you may need to resolve the issue before"-warn"you are able to reword the commit."exit_with_patch$sha11}record_in_rewritten$sha1
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:03
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. This happens in two
steps. Firstly, the named commit is cherry-picked. Secondly, the
commit created in the first step is amended using an unchanged index
to edit the log message. The pre-commit hook is meant to verify the
changes introduced by a commit (for instance, catching inserted
trailing white space). Since the committed tree is not changed
between the two steps and we do not verify rebased patches, do not
execute the pre-commit hook in the second step.
Specify the git-commit option `--no-verify` to disable the pre-commit
hook when editing the log message. Because `--no-verify` also skips
the commit-msg hook, execute the hook from within
git-rebase--interactive after the commit is created. Fortunately, the
commit message is still available in `$GIT_DIR/COMMIT_EDITMSG` after
git-commit terminates. Caveat: In case the commit-msg hook finds the
new log message ill-formatted, the user is only notified of the
failed commit-msg hook but the log message is used for the commit
anyway. git-commit ought to offer more fine-grained control over
which hooks are executed.
Teach `test_commit` the `--no-verify` option and add test.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 17 +++++++++++++----
t/t3404-rebase-interactive.sh | 38 ++++++++++++++++++++++++++++++++++++++
t/test-lib-functions.sh | 6 +++++-
3 files changed, 56 insertions(+), 5 deletions(-)
@@ -504,10 +504,19 @@ do_next () {mark_action_donedo_pick$sha1"$rest"-gitcommit--allow-empty--amend--no-post-rewrite${gpg_sign_opt:+"$gpg_sign_opt"}||{-warn"Could not amend commit after successfully picking $sha1... $rest"-exit_with_patch$sha11-}+# TODO: Work around the fact that git-commit lets us+# disable either both the pre-commit and the commit-msg+# hook or none. Disable the pre-commit hook because the+# tree is left unchanged but run the commit-msg hook+# from here because the log message is altered.+gitcommit--allow-empty--amend--no-post-rewrite-n${gpg_sign_opt:+"$gpg_sign_opt"}&&+iftest-x"$GIT_DIR"/hooks/commit-msg+then+"$GIT_DIR"/hooks/commit-msg"$GIT_DIR"/COMMIT_EDITMSG+fi||{+warn"Could not amend commit after successfully picking $sha1... $rest"+exit_with_patch$sha11+}record_in_rewritten$sha1;;edit|e)
@@ -577,6 +577,44 @@ test_expect_success 'rebase a commit violating pre-commit' ''+test_expect_success'reword a commit violating pre-commit''+test_when_finishedrm-r.git/hooks&&+mkdir-p.git/hooks&&+PRE_COMMIT=.git/hooks/pre-commit&&+cat>"$PRE_COMMIT"<<EOF+#!/bin/sh+echorunningpre-commit:exit1+exit1+EOF+chmod+x"$PRE_COMMIT"&&+test_must_failtest_commitpre-commit-violated&&+test_commit--no-verifypre-commit-violated&&+test_when_finishedreset_rebase&&+set_fake_editor&&+FAKE_LINES="pick 1"gitrebase-iHEAD^&&+FAKE_LINES="pick 1"gitrebase-i--no-ffHEAD^&&+FAKE_LINES="reword 1"gitrebase-iHEAD^+'++test_expect_success'reword a commit violating commit-msg''+test_when_finishedrm-r.git/hooks&&+mkdir-p.git/hooks&&+COMMIT_MSG=.git/hooks/commit-msg&&+cat>"$COMMIT_MSG"<<EOF+#!/bin/sh+echorunningcommit-msg:exit1+exit1+EOF+chmod+x"$COMMIT_MSG"&&+test_must_failtest_commitcommit-msg-violated&&+test_commit--no-verifycommit-msg-violated&&+test_when_finishedreset_rebase&&+set_fake_editor&&+FAKE_LINES="pick 1"gitrebase-iHEAD^&&+FAKE_LINES="pick 1"gitrebase-i--no-ffHEAD^&&+test_must_failenvFAKE_LINES="reword 1"gitrebase-iHEAD^+'+ test_expect_success'rebase with a file named HEAD in worktree''rm-fr.git/hooks&&
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:03
git-rebase--interactive handles empty log messages inconsistently
between enabled and disabled fast-forwards. By default, commits with
empty log messages are rebased successfully like in non-interactive
mode. In contrast, the `--no-ff` option aborts the replay of such
commits.
In line with not verifying rebased commits and behaving like
git-rebase for `pick` lines, use the `--allow-empty-message` option
to replay commits. Root commits are replayed by recreating them in
`do_pick` using git-commit and commits with parents are replayed
using git-cherry-pick in `pick_one`. Apply the option, understood by
both git-commit and git-cherry-pick, at the respective sites.
In case of `reword` and `squash`/`fixup` continue to abort the rebase
if the resulting commit would have no commit message. The rationale
behind this default is that patches and their log messages should be
verified at least once. For unchanged commits this is assumed to have
happened according to the author's standards when she created the
commits the first time. While the empty log message can always be
kept in place by editing and resuming the aborted rebase, a debatable
alternative could be to teach git-rebase--interactive the option
`--allow-empty-message` for disabling complaints about empty log
messages in changed commits. The to-do list command `edit` is handled
just like `pick` for this matter, because git-rebase--interactive
replays the named commit without changes before the rebase is
interrupted and the user can make her changes to the replayed commit.
Add tests.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 4 ++--
t/t3404-rebase-interactive.sh | 24 ++++++++++++++++++++++++
t/t3412-rebase-root.sh | 19 +++++++++++++++++++
3 files changed, 45 insertions(+), 2 deletions(-)
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:03
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. If `--keep-empty` is
passed as option to git-rebase--interactive, empty commits ought to
be replayed without complaints. However, if the users chooses to
reword an empty commit by changing the respective to-do list entry
from
pick fa1afe1 Empty commit
to
reword fa1afe1 Empty commit
, then git-rebase--interactive suddenly fails to replay the empty
commit. This is especially counterintuitive because `reword` is
thought of as a `pick` that alters the log message in some way but
nothing more and the unchanged to-do list entry would not fail.
Handle `reword` by cherry-picking the named commit and editing the
log message using
git commit --allow-empty --amend
instead of
git commit --amend.
Add test.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 2 +-
t/t3404-rebase-interactive.sh | 8 ++++++++
2 files changed, 9 insertions(+), 1 deletion(-)
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:03
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement the to-do list command `pick`. To cater for
the different pick behaviours (like `reword`), `do_pick` accepts
several options not only from the git-cherry-pick but also the
git-commit interface. Add the common option `--edit` to let the user
edit the log message of the named commit.
Loop over `$@` to parse the `do_pick` arguments. Assign the local
variable `edit` if one of the options is `--edit` so that the
remainder of `do_pick` can easily check whether the client code asked
to edit the commit message. If one of the options is unknown, mention
it on the console and `die`. Break the loop on the first non-option
and do some sanity checking to ensure that there exactly two
non-options, which are interpreted by the remainder as `<commit>` and
`<title>` like before.
`do_pick` ought to act as a wrapper around `cherry-pick`.
Unfortunately, it cannot just forward `--edit` to the `cherry-pick`
command line. The assembled command line is executed within a command
substitution for controlling the verbosity of `rebase--interactive`.
Passing `--edit` would either hang the terminal or clutter the
substituted command output with control sequences. Execute the
`reword` code from `do_next` instead if the option `--edit` is
specified.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 52 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
@@ -461,7 +461,42 @@ record_in_rewritten() {esac}+# Apply the changes introduced by the given commit to the current head.+#+# do_pick [--edit] <commit> <title>+#+# Wrapper around git-cherry-pick.+#+# -e, --edit+# After picking <commit>, open an editor and let the user edit the+# commit message. The editor contents becomes the commit message of+# the new head. This creates a fresh commit.+#+# <commit>+# The commit to cherry-pick.+#+# <title>+# The commit message title of <commit>. Used for information+# purposes only. do_pick(){+edit=+whiletest$#-gt0+do+case"$1"in+-e|--edit)+edit=y+;;+-*)+die"do_pick: unrecognized option -- $1"+;;+*)+break+;;+esac+shift+done+test$#-ne2&&die"do_pick: wrong number of arguments"+iftest"$(gitrev-parseHEAD)"="$squash_onto"then# Set the correct commit message and author info on the
@@ -483,6 +518,23 @@ do_pick () {pick_one$1||die_with_patch$1"Could not apply $1... $2"fi++iftest-n"$edit"+then+# TODO: Work around the fact that git-commit lets us+# disable either both the pre-commit and the commit-msg+# hook or none. Disable the pre-commit hook because the+# tree is left unchanged but run the commit-msg hook+# from here because the log message is altered.+gitcommit--allow-empty--amend--no-post-rewrite-n${gpg_sign_opt:+"$gpg_sign_opt"}&&+iftest-x"$GIT_DIR"/hooks/commit-msg+then+"$GIT_DIR"/hooks/commit-msg"$GIT_DIR"/COMMIT_EDITMSG+fi||{+warn"Could not amend commit after successfully picking $1... $2"+exit_with_patch$11+}+fi} do_next(){
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:03
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. If one thinks of `pick`
entries as scheduled `cherry-pick` command lines, then `reword`
becomes an alias for the command line `cherry-pick --edit`. The
porcelain `rebase--interactive` defines a function `do_pick` for
processing the `pick` entries on to-do lists. Reimplement `reword` in
terms of `do_pick --edit`.
If the user picks a commit using the to-do list line
reword fa1afe1 Some change
execute the command `do_pick --edit fa1afe1 "Some change"` which
carries out exactly the same steps as the case arm for `reword` in
`do_next` so far.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 15 +--------------
1 file changed, 1 insertion(+), 14 deletions(-)
@@ -555,20 +555,7 @@ do_next () {comment_for_reflogrewordmark_action_done-do_pick$sha1"$rest"-# TODO: Work around the fact that git-commit lets us-# disable either both the pre-commit and the commit-msg-# hook or none. Disable the pre-commit hook because the-# tree is left unchanged but run the commit-msg hook-# from here because the log message is altered.-gitcommit--allow-empty--amend--no-post-rewrite-n${gpg_sign_opt:+"$gpg_sign_opt"}&&-iftest-x"$GIT_DIR"/hooks/commit-msg-then-"$GIT_DIR"/hooks/commit-msg"$GIT_DIR"/COMMIT_EDITMSG-fi||{-warn"Could not amend commit after successfully picking $sha1... $rest"-exit_with_patch$sha11-}+do_pick--edit$sha1"$rest"record_in_rewritten$sha1;;edit|e)
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:03
The command line used to recreate root commits specifies the
effectless option `-C`. It makes git-commit reuse commit message and
authorship of the named commit. However, the commit being amended
here, which is the sentinel commit, already carries the authorship
and log message of the commit being replayed. Remove the option.
Since `-C` (in contrast to `-c`) does not invoke the editor and the
`--amend` option invokes it by default, disable editor invocation
again by specifying `--no-edit`.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:03
Since `do_pick` might be executed in a sub-shell (a modified author
environment for instance), calling `die` in `do_pick` has no effect
but exiting the sub-shell with a failure exit status. The
git-rebase--interactive script is not terminated. Moreover, if
`do_pick` is called while a squash or fixup is in effect,
`die_with_patch` will discard `$squash_msg` as commit message.
Lastly, after a `die` in `do_pick` `do_next` has no chance to
reschedule tasks that failed before changes could be applied.
Indicate an error in `do_pick` using return statements and properly
kill the script at the call sites. Although possible in principle,
the issued error messages are no more indicating whether `do_pick`
failed while applying or while committing the changes. This reduces
code complexity at the call site and does not matter from a user's
point of view because a glance at the index reveals whether there are
conflicts or not and in-depth troubleshooting is still possible using
the `--verbose` option.
Remove the commit message title argument from `do_pick`'s interface,
which has become unused.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 37 ++++++++++++++++++++-----------------
1 file changed, 20 insertions(+), 17 deletions(-)
@@ -464,7 +464,7 @@ record_in_rewritten() {# Apply the changes introduced by the given commit to the current head.#-# do_pick [--edit] <commit> <title>+# do_pick [--edit] <commit>## Wrapper around git-cherry-pick.#
@@ -476,9 +476,11 @@ record_in_rewritten() {# <commit># The commit to cherry-pick.#-# <title>-# The commit message title of <commit>. Used for information-# purposes only.+# The return value is 1 if applying the changes resulted in a conflict+# and 2 if the specified arguments were incorrect. If the changes could+# be applied successfully but creating the commit failed, a value+# greater than 2 is returned. No commit is created in either case and+# the index is left with the (conflicting) changes in place. do_pick(){allow_empty_message=yrewrite=
@@ -501,7 +504,11 @@ do_pick () {esacshiftdone-test$#-ne2&&die"do_pick: wrong number of arguments"+iftest$#-ne1+then+warn"do_pick: wrong number of arguments"+return2+fiiftest"$(gitrev-parseHEAD)"="$squash_onto"then
@@ -519,11 +526,9 @@ do_pick () {# rebase --continue.gitcommit--allow-empty--allow-empty-message--amend\--no-post-rewrite-n-q-C$1&&-pick_one-n$1||-die_with_patch$1"Could not apply $1... $2"+pick_one-n$1||return1else-pick_one${rewrite:+-n}$1||-die_with_patch$1"Could not apply $1... $2"+pick_one${rewrite:+-n}$1||return1fiiftest-n"$rewrite"
@@ -532,8 +537,7 @@ do_pick () {${allow_empty_message:+--allow-empty-message}\${rewrite_amend:+--amend}\${rewrite_edit:+--edit}\-${gpg_sign_opt:+"$gpg_sign_opt"}||-die_with_patch$1"Could not rewrite commit after successfully picking $1... $2"+${gpg_sign_opt:+"$gpg_sign_opt"}||return3fi# TODO: Work around the fact that git-commit lets us
@@ -546,8 +550,7 @@ do_pick () {iftest-x"$GIT_DIR"/hooks/commit-msgthen"$GIT_DIR"/hooks/commit-msg"$GIT_DIR"/COMMIT_EDITMSG-fi||-die_with_patch$1"Could not rewrite commit after successfully picking $1... $2"+fi||return3fi}
@@ -562,21 +565,21 @@ do_next () {comment_for_reflogpickmark_action_done-do_pick$sha1"$rest"+do_pick$sha1||die_with_patch$sha1"Could not apply $sha1... $rest"record_in_rewritten$sha1;;reword|r)comment_for_reflogrewordmark_action_done-do_pick--edit$sha1"$rest"+do_pick--edit$sha1||die_with_patch$sha1"Could not apply $sha1... $rest"record_in_rewritten$sha1;;edit|e)comment_for_reflogeditmark_action_done-do_pick$sha1"$rest"+do_pick$sha1||die_with_patch$sha1"Could not apply $sha1... $rest"warn"Stopped at $sha1... $rest"exit_with_patch$sha10;;
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:03
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement the to-do list command `pick`, `reword` and
`edit`. To cater for the different pick behaviours (like `squash`),
`do_pick` accepts several options not only from the git-cherry-pick
but also the git-commit interface.
Add the option `--file` from the git-commit interface to the options
pool of `do_pick`. It expects an argument itself which is interpreted
as a file path and takes the commit message from the given file. If
`--file` is passed to `do_pick`, assign the given file path to the
local variable `rewrite_message` and relay the option
--file "$rewrite_message"
to the git-commit command line which creates the commit.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
@@ -464,7 +464,7 @@ record_in_rewritten() {# Apply the changes introduced by the given commit to the current head.#-# do_pick [--amend] [--edit] <commit>+# do_pick [--amend] [--file <file>] [--edit] <commit>## Wrapper around git-cherry-pick.#
@@ -474,6 +474,12 @@ record_in_rewritten() {## _This is not a git-cherry-pick option._#+# -F <file>, --file <file>+# Take the commit message from the given file. This creates a fresh+# commit.+#+# _This is not a git-cherry-pick option._+## -e, --edit# After picking <commit>, open an editor and let the user edit the# commit message. The editor contents becomes the commit message of
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:03
The options passed to `do_pick` determine whether the picked commit
will be rewritten or not. If the commit gets rewritten, because the
user requested to edit the commit message for instance, let
`pick_one` merely apply the changes introduced by the commit and do
not commit the resulting tree yet. If the commit is replayed as is,
leave it to `pick_one` to recreate the commit (possibly by
fast-forwarding the head). This makes it easier to combine git-commit
options like `--edit` and `--amend` in `do_pick` because
git-cherry-pick does not support `--amend`.
In the case of `--edit`, do not `exit_with_patch` but assign
`rewrite` to pick the changes with `-n`. If the pick conflicts, no
commit is created which we would have to amend when continuing the
rebase. To complete the pick after the conflicts are resolved the
user just resumes with `git rebase --continue`.
git-commit lets the user edit the commit log message by default. We
do not want that for the rewriting git-commit command line because
the default behaviour of git-rebase is exactly the opposite. Pass
`--no-edit` when rewriting a picked commit. An explicit `--edit`
passed to `do_pick` (for instance, when reword is executed) enables
the editor launch again. Similarly, pass `--allow-empty-message`
unless the log message is edited.
If `rebase--interactive` is used to rebase a complete branch onto
some head, `rebase` creates a sentinel commit that requires special
treatment by `do_pick`. Do not finalize the pick here either because
its commit message can be altered as for any other pick. Since the
orphaned root commit gets a temporary parent, it is always rewritten.
Safely use the rewrite infrastructure of `do_pick` to create the
final commit.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 58 ++++++++++++++++++++++++++++------------------
1 file changed, 36 insertions(+), 22 deletions(-)
@@ -63,7 +63,8 @@ msgnum="$state_dir"/msgnumauthor_script="$state_dir"/author-script# When an "edit" rebase command is being processed, the SHA1 of the-# commit to be edited is recorded in this file. When "git rebase+# commit to be edited is recorded in this file. The same happens when+# rewriting a commit fails, for instance "reword". When "git rebase# --continue" is executed, if there are any staged changes then they# will be amended to the HEAD commit, but only provided the HEAD# commit is still the commit to be edited. When any other rebase
@@ -479,12 +480,17 @@ record_in_rewritten() {# The commit message title of <commit>. Used for information# purposes only. do_pick(){-edit=+allow_empty_message=y+rewrite=+rewrite_amend=+rewrite_edit=whiletest$#-gt0docase"$1"in-e|--edit)-edit=y+rewrite=y+rewrite_edit=y+allow_empty_message=;;-*)die"do_pick: unrecognized option -- $1"
@@ -499,6 +505,10 @@ do_pick () {iftest"$(gitrev-parseHEAD)"="$squash_onto"then+rewrite=y+rewrite_amend=y+gitrev-parse--verifyHEAD>"$amend"+# Set the correct commit message and author info on the# sentinel root before cherry-picking the original changes# without committing (-n). Finally, update the sentinel again
@@ -509,31 +519,35 @@ do_pick () {# rebase --continue.gitcommit--allow-empty--allow-empty-message--amend\--no-post-rewrite-n-q-C$1&&-pick_one-n$1&&-gitcommit--allow-empty--allow-empty-message\---amend--no-post-rewrite-n--no-edit\-${gpg_sign_opt:+"$gpg_sign_opt"}||+pick_one-n$1||die_with_patch$1"Could not apply $1... $2"else-pick_one$1||+pick_one${rewrite:+-n}$1||die_with_patch$1"Could not apply $1... $2"fi-iftest-n"$edit"+iftest-n"$rewrite"then-# TODO: Work around the fact that git-commit lets us-# disable either both the pre-commit and the commit-msg-# hook or none. Disable the pre-commit hook because the-# tree is left unchanged but run the commit-msg hook-# from here because the log message is altered.-gitcommit--allow-empty--amend--no-post-rewrite-n${gpg_sign_opt:+"$gpg_sign_opt"}&&-iftest-x"$GIT_DIR"/hooks/commit-msg-then-"$GIT_DIR"/hooks/commit-msg"$GIT_DIR"/COMMIT_EDITMSG-fi||{-warn"Could not amend commit after successfully picking $1... $2"-exit_with_patch$11-}+gitcommit--allow-empty--no-post-rewrite-n--no-edit\+${allow_empty_message:+--allow-empty-message}\+${rewrite_amend:+--amend}\+${rewrite_edit:+--edit}\+${gpg_sign_opt:+"$gpg_sign_opt"}||+die_with_patch$1"Could not rewrite commit after successfully picking $1... $2"+fi++# TODO: Work around the fact that git-commit lets us+# disable either both the pre-commit and the commit-msg+# hook or none. Disable the pre-commit hook because the+# tree is left unchanged but run the commit-msg hook+# from here because the log message is altered.+iftest-n"$rewrite_edit"+then+iftest-x"$GIT_DIR"/hooks/commit-msg+then+"$GIT_DIR"/hooks/commit-msg"$GIT_DIR"/COMMIT_EDITMSG+fi||+die_with_patch$1"Could not rewrite commit after successfully picking $1... $2"fi}
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:03
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement the to-do list commands `pick`, `reword`
and `edit`. To cater for the different pick behaviours (like
`squash`), `do_pick` accepts several options not only from the
git-cherry-pick but also the git-commit interface.
Add the option `--amend` from the git-commit interface to the options
pool of `do_pick`. It creates a new commit for the changes introduced
by the picked commit and the previous one. The previous commit is
then replaced with the new commit. If no other options are specified,
the log message of the previous commit is used.
Be careful when `--amend` is used to pick a root commit because HEAD
might point to the sentinel commit but there is still nothing to
amend. Be sure to initialize `amend` so that commits are squashed
even when git-rebase--interactive is interrupted for resolving
conflicts. It is not a mistake to do the initialization regardless of
any conflicts because `amend` is always cleared before the next to-do
item is processed.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
@@ -464,10 +464,16 @@ record_in_rewritten() {# Apply the changes introduced by the given commit to the current head.#-# do_pick [--edit] <commit>+# do_pick [--amend] [--edit] <commit>## Wrapper around git-cherry-pick.#+# --amend+# After picking <commit>, replace the current head commit with a new+# commit that also introduces the changes of <commit>.+#+# _This is not a git-cherry-pick option._+## -e, --edit# After picking <commit>, open an editor and let the user edit the# commit message. The editor contents becomes the commit message of
@@ -489,6 +495,16 @@ do_pick () {whiletest$#-gt0docase"$1"in+--amend)+iftest"$(gitrev-parseHEAD)"="$squash_onto"||!gitrev-parse--verifyHEAD+then+warn"do_pick: nothing to amend"+return2+fi+rewrite=y+rewrite_amend=y+gitrev-parse--verifyHEAD>"$amend"+;;-e|--edit)rewrite=yrewrite_edit=y
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:03
Rewrite `squash` and `fixup` handling in `do_next` using the sequence
pick_one
commit
in order to test the correctness of a single `do_squash` or
parameterised `do_pick` and make the subsequent patch reimplementing
`squash` in terms of such a single function more readable.
Do not call `rm -f "$GIT_DIR"/MERGE_MSG` since it has no effect on
the state after git-rebase--interactive terminates. The option `-F`
makes git-commit ignore `MERGE_MSG` for the log message. If
git-commit succeeds, `MERGE_MSG` is removed, and if it fails,
`MERGE_MSG` is overwritten by the error sequence `die_failed_squash`.
In summary, removing `MERGE_MSG` neither influences the squash commit
message nor the file state after git-commit returns.
Moreover, `pick_one` ignores `$GIT_DIR/SQUASH_MSG` and does not touch
`$squash_msg` so that it is correct to execute `pick_one` immediately
before git-commit.
Might be squashed into the subsequent commit.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 21 +++++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
@@ -636,15 +636,15 @@ do_next () {author_script_content=$(get_author_ident_from_commitHEAD)echo"$author_script_content">"$author_script"eval"$author_script_content"-if!pick_one-n$sha1-then-gitrev-parse--verifyHEAD>"$amend"-die_failed_squash$sha1"$rest"-ficase"$(peek_next_command)"insquash|s|fixup|f)# This is an intermediate commit; its message will only be# used in case of trouble. So use the long version:+if!pick_one-n$sha1+then+gitrev-parse--verifyHEAD>"$amend"+die_failed_squash$sha1"Could not apply $sha1... $rest"+fido_with_authoroutputgitcommit--amend--no-verify-F"$squash_msg"\${gpg_sign_opt:+"$gpg_sign_opt"}||die_failed_squash$sha1"$rest"
@@ -653,12 +653,21 @@ do_next () {# This is the final command of this squash/fixup groupiftest-f"$fixup_msg"then+if!pick_one-n$sha1+then+gitrev-parse--verifyHEAD>"$amend"+die_failed_squash$sha1"Could not apply $sha1... $rest"+fido_with_authorgitcommit--amend--no-verify-F"$fixup_msg"\${gpg_sign_opt:+"$gpg_sign_opt"}||die_failed_squash$sha1"$rest"elsecp"$squash_msg""$GIT_DIR"/SQUASH_MSG||exit-rm-f"$GIT_DIR"/MERGE_MSG+if!pick_one-n$sha1+then+gitrev-parse--verifyHEAD>"$amend"+die_failed_squash$sha1"Could not apply $sha1... $rest"+fido_with_authorgitcommit--amend--no-verify-F"$GIT_DIR"/SQUASH_MSG-e\${gpg_sign_opt:+"$gpg_sign_opt"}||die_failed_squash$sha1"$rest"
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:04
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is currently used to implement most of the to-do list commands
and offers additional options that will eventually find their way
onto to-do lists.
To extend the repertoire of available options, add the git-commit and
git-cherry-pick option `--signoff` to the `do_pick` interface. It
appends a Signed-off-by: line using the committer identity to the log
message of the picked commit.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
@@ -464,10 +464,15 @@ record_in_rewritten() {# Apply the changes introduced by the given commit to the current head.#-# do_pick [--reset-author] [--amend] [--file <file>] [--edit] <commit>+# do_pick [--signoff] [--reset-author] [--amend] [--file <file>]+# [--edit] <commit>## Wrapper around git-cherry-pick.#+# -s, --signoff+# Insert a Signed-off-by: line using the committer identity at the+# end of the commit log message. This creates a fresh commit.+## --reset-author# Pretend the changes were made for the first time. Declare that the# authorship of the resulting commit now belongs to the committer.
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:04
pick and reword are atomic to-do list commands in the sense that they
open a new task which is closed after the respective command is
completed. squash and fixup are not atomic. They create a new task
which is not completed until the last squash or fixup is processed.
Lift the general unknown option blockade for the pick and reword
commands. If `do_cmd` comes across one of the options `--signoff` and
`--reset-author` while parsing a to-do entry and the scheduled
command is either `pick` or `reword`, relay the option to `do_pick`.
The `do_pick` options `--gpg-sign` and `--file` are not yet supported
because `do_cmd` cannot handle option arguments and options with
spaces at the moment. It is true that edit is one of the atomic
commands but it displays hash information when the rebase is stopped
and some options rewrite the picked commit which alters that
information. squash and fixup still do not accept user options as the
interplay of `--reset-author` and the author script are yet to be
determined.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
@@ -647,21 +657,24 @@ do_replay () {comment_for_reflogpickmark_action_done-do_pick$sha1||die_with_patch$sha1"Could not apply $sha1... $rest"+evaldo_pick$opts$sha1\+||die_with_patch$sha1"Could not apply $sha1... $rest"record_in_rewritten$sha1;;reword|r)comment_for_reflogrewordmark_action_done-do_pick--edit$sha1||die_with_patch$sha1"Could not apply $sha1... $rest"+evaldo_pick--edit$opts$sha1\+||die_with_patch$sha1"Could not apply $sha1... $rest"record_in_rewritten$sha1;;edit|e)comment_for_reflogeditmark_action_done-do_pick$sha1||die_with_patch$sha1"Could not apply $sha1... $rest"+evaldo_pick$opts$sha1\+||die_with_patch$sha1"Could not apply $sha1... $rest"warn"Stopped at $sha1... $rest"exit_with_patch$sha10;;
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:04
The to-do list command `squash` and its close relative `fixup` replay
the changes of a commit like `pick` but do not recreate the commit.
Instead they replace the previous commit with a new commit that also
introduces the changes of the squashed commit. This is roughly like
cherry-picking without committing and using git-commit to amend the
previous commit.
The to-do list
pick a Some changes
squash b Some more changes
gets translated into the sequence of git commands
git cherry-pick a
git cherry-pick -n b
git commit --amend
and if git-cherry-pick supported `--amend` this would look even more
like the to-do list it is based on
git cherry-pick a
git cherry-pick --amend b.
Since `do_pick` takes care of `pick` entries and the above suggests
`squash` as an alias for `pick --amend`, reimplement `squash` in
terms of `do_pick --amend`. Introduce `$squash_msg` as the commit
message via the `--file` option. When the last commit of a squash
series is processed, the user is asked to review the log message.
Pass `--edit` as additional option in this case. The only difference
in the options passed to git-commit and `do_pick` is the omitted
`--no-verify`. However, `do_pick` does not execute the verification
hooks anyway because it solely replays commits and assumes that they
have been verified before.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 30 ++++++------------------------
1 file changed, 6 insertions(+), 24 deletions(-)
@@ -640,37 +640,19 @@ do_next () {squash|s|fixup|f)# This is an intermediate commit; its message will only be# used in case of trouble. So use the long version:-if!pick_one-n$sha1-then-gitrev-parse--verifyHEAD>"$amend"-die_failed_squash$sha1"Could not apply $sha1... $rest"-fi-do_with_authoroutputgitcommit--amend--no-verify-F"$squash_msg"\-${gpg_sign_opt:+"$gpg_sign_opt"}||-die_failed_squash$sha1"$rest"+do_with_authordo_pick--amend-F"$squash_msg"$sha1\+||die_failed_squash$sha1"Could not apply $sha1... $rest";;*)# This is the final command of this squash/fixup groupiftest-f"$fixup_msg"then-if!pick_one-n$sha1-then-gitrev-parse--verifyHEAD>"$amend"-die_failed_squash$sha1"Could not apply $sha1... $rest"-fi-do_with_authorgitcommit--amend--no-verify-F"$fixup_msg"\-${gpg_sign_opt:+"$gpg_sign_opt"}||-die_failed_squash$sha1"$rest"+do_with_authordo_pick--amend-F"$fixup_msg"$sha1\+||die_failed_squash$sha1"Could not apply $sha1... $rest"elsecp"$squash_msg""$GIT_DIR"/SQUASH_MSG||exit-if!pick_one-n$sha1-then-gitrev-parse--verifyHEAD>"$amend"-die_failed_squash$sha1"Could not apply $sha1... $rest"-fi-do_with_authorgitcommit--amend--no-verify-F"$GIT_DIR"/SQUASH_MSG-e\-${gpg_sign_opt:+"$gpg_sign_opt"}||-die_failed_squash$sha1"$rest"+do_with_authordo_pick--amend-F"$GIT_DIR"/SQUASH_MSG-e$sha1\+||die_failed_squash$sha1"Could not apply $sha1... $rest"firm-f"$squash_msg""$fixup_msg";;
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:04
Read in to-do list lines as
command args
instead of
command sha1 rest
so that to-do list command lines can specify additional arguments
apart from the commit hash and the log message title, which become
the non-options in `args`. Loop over `args`, put all options (an
argument beginning with a dash) in `opts`, stop the loop on the first
non-option and assign it to `sha1`. The loop does not know the
options it parses so that options that take an argument themselves
are not supported at the moment. Neither are options that contain
spaces because the shell expansion of `args` in `do_next` interprets
white space characters as argument separator, that is a command line
like
pick --author "A U Thor" fa1afe1 Some change
is parsed as the pick command
pick --author
and the commit hash
"A
which obviously results in an unknown revision error. For the sake of
completeness, in the example above the message title variable `rest`
is assigned the string 'U Thor" fa1afe1 Some change' (without the
single quotes).
Print an error message for unknown or unsupported command line
options, which means an error for all specified options at the
moment. Cleanly break the `do_next` loop by assigning the special
value 'unknown' to the local variable `command`, which triggers the
unknown command case in `do_cmd`.
The to-do list is also parsed when the commit hashes are translated
between long and short format before and after the to-do list is
edited. Apply the same procedure as in `do_cmd` with the exception
that we only care about where the options stop and the commit hash
begins. Do not reject any options when transforming the commit
hashes.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 49 ++++++++++++++++++++++++++++++++++++++--------
1 file changed, 41 insertions(+), 8 deletions(-)
@@ -799,19 +817,34 @@ skip_unnecessary_picks () {} transform_todo_ids(){-whileread-rcommandrest+whileread-rcommandargsdocase"$command"in"$comment_char"*|exec)# Be careful for oddball commands like 'exec'# that do not have a SHA-1 at the beginning of $rest.+newargs=\ $args;;*)-sha1=$(gitrev-parse--verify--quiet"$@"${rest%% *})&&-rest="$sha1${rest#* }"+newargs=+sha1=+forargin$args+do+case"$arg"in+-*)+newargs="$newargs$arg"+;;+*)+test-z"$sha1"&&+sha1=$(gitrev-parse--verify--quiet"$@"$arg)&&+arg=$sha1+newargs="$newargs$arg"+;;+esac+done;;esac-printf'%s\n'"$command${rest:+ }$rest"+printf'%s\n'"$command$newargs"done<"$todo">"$todo.new"&&mv-f"$todo.new""$todo"}
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:04
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement many of the to-do list commands.
Eventually, the complete `do_pick` interface will be exposed to the
user in some form or another and those commands will become simple
aliases for the `do_pick` options now used to implement them.
Add the git-commit option `--reset-author` to the options pool of
`do_pick`. It rewrites the author date and name of the picked commit
to match the committer date and name.
If `--reset-author` is passed to `do_pick`, set the `rewrite` flag
and relay the option to the git-commit command line which creates the
final commit. If `--amend` is not passed as well, the fresh
authorship effect is achieved by the mere fact that we are creating a
new commit.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
@@ -464,10 +464,18 @@ record_in_rewritten() {# Apply the changes introduced by the given commit to the current head.#-# do_pick [--amend] [--file <file>] [--edit] <commit>+# do_pick [--reset-author] [--amend] [--file <file>] [--edit] <commit>## Wrapper around git-cherry-pick.#+# --reset-author+# Pretend the changes were made for the first time. Declare that the+# authorship of the resulting commit now belongs to the committer.+# This also renews the author timestamp. This creates a fresh+# commit.+#+# _This is not a git-cherry-pick option._+## --amend# After picking <commit>, replace the current head commit with a new# commit that also introduces the changes of <commit>.
@@ -564,6 +576,14 @@ do_pick () {pick_one${rewrite:+-n}$1||return1fi+iftest-n"$rewrite_author"&&test-z"$rewrite_amend"+then+# keep rewrite flag to create a new commit, rewrite+# without --reset-author though because it can only be+# used with -C, -c or --amend+rewrite_author=+fi+iftest-n"$rewrite"thengitcommit--allow-empty--no-post-rewrite-n--no-edit\
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:04
There are two kinds of to-do list commands available. One kind
replays a commit (`pick`, `reword`, `edit`, `squash` and `fixup` that
is) and the other executes a shell command (`exec`). We will call the
first kind replay commands.
The two kinds of tasks are scheduled using different line formats.
Replay commands expect a commit hash argument following the command
name and exec concatenates all arguments to assemble a command line.
Adhere to the distinction of formats by not trying to parse the
`sha1` field unless we are dealing with a replay command. Move the
replay command handling code to a new function `do_replay` which
assumes the first argument to be a commit hash and make no more such
assumptions in `do_next`.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 42 ++++++++++++++++++++++++++++--------------
1 file changed, 28 insertions(+), 14 deletions(-)
@@ -659,6 +658,28 @@ do_next () {esacrecord_in_rewritten$sha1;;+*)+read-rcommand<"$todo"+warn"Unknown command: $command"+fixtodo="Please fix this using 'git rebase --edit-todo'."+ifgitrev-parse--verify-q"$sha1">/dev/null+then+die_with_patch$sha1"$fixtodo"+else+die"$fixtodo"+fi+;;+esac+}++do_next(){+rm-f"$msg""$author_script""$amend"||exit+read-rcommandsha1rest<"$todo"++case"$command"in+"$comment_char"*|''|noop)+mark_action_done+;;x|"exec")read-rcommandrest<"$todo"mark_action_done
@@ -698,14 +719,7 @@ do_next () {fi;;*)-warn"Unknown command: $command$sha1$rest"-fixtodo="Please fix this using 'git rebase --edit-todo'."-ifgitrev-parse--verify-q"$sha1">/dev/null-then-die_with_patch$sha1"$fixtodo"-else-die"$fixtodo"-fi+do_replay$command$sha1"$rest";;esactest-s"$todo"&&return
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:04
The command line used to recreate root commits specifies the option
`-q` which suppresses the commit summary message. However,
git-rebase--interactive tends to tell the user about the commits it
creates in the final history, if she wishes (cf. command line option
`--verbose`). The code parts handling non-root commits and squash
commits all output commit summary messages. Do not make the replay of
root commits an exception. Remove the option to make the report of
the rebased history complete.
It is OK that the commit summary is still suppressed when git-commit
is used to initialize the authorship of the sentinel commit because
this additional commit is an implementation detail hidden from the
final history. The removed `-q` option was probably introduced as a
copy-and-paste error stemming from that part of the root commit
handling code.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Jeff King <hidden> Date: 2016-06-15 23:02:07
On Tue, Jul 29, 2014 at 01:18:03AM +0200, Fabian Ruch wrote:
Specify the git-commit option `--no-verify` to disable the pre-commit
hook when editing the log message. Because `--no-verify` also skips
the commit-msg hook, execute the hook from within
git-rebase--interactive after the commit is created. Fortunately, the
commit message is still available in `$GIT_DIR/COMMIT_EDITMSG` after
git-commit terminates. Caveat: In case the commit-msg hook finds the
new log message ill-formatted, the user is only notified of the
failed commit-msg hook but the log message is used for the commit
anyway. git-commit ought to offer more fine-grained control over
which hooks are executed.
Thanks for a nice explanation of the tradeoff. Have you looked at adding
an option to git-commit? We already have --no-post-rewrite. I think you
would just need:
@@ -661,7 +662,8 @@ static int prepare_to_commit(const char *index_file, const char *prefix,/* This checks and barfs if author is badly specified */determine_author_info(author_ident);-if(!no_verify&&run_commit_hook(use_editor,index_file,"pre-commit",NULL))+if(!no_verify&&!no_pre_commit&&+run_commit_hook(use_editor,index_file,"pre-commit",NULL))return0;if(squash_message){
@@ -1604,6 +1606,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)N_("terminate entries with NUL")),OPT_BOOL(0,"amend",&amend,N_("amend previous commit")),OPT_BOOL(0,"no-post-rewrite",&no_post_rewrite,N_("bypass post-rewrite hook")),+OPT_BOOL(0,"no-pre-commit",&no_pre_commit,N_("bypass pre-commit hook")),{OPTION_STRING,'u',"untracked-files",&untracked_files_arg,N_("mode"),N_("show untracked files, optional modes: all, normal, no. (Default: all)"),PARSE_OPT_OPTARG,NULL,(intptr_t)"all"},/* end commit contents options */
though I would also not be opposed to some more uniform hook selection
mechanism (e.g., "--no-verify=pre-commit" or something).
-Peff
From: Jeff King <hidden> Date: 2016-06-15 23:02:07
On Tue, Jul 29, 2014 at 01:18:07AM +0200, Fabian Ruch wrote:
The command line used to recreate root commits specifies the option
`-q` which suppresses the commit summary message. However,
git-rebase--interactive tends to tell the user about the commits it
creates in the final history, if she wishes (cf. command line option
`--verbose`). The code parts handling non-root commits and squash
commits all output commit summary messages. Do not make the replay of
root commits an exception. Remove the option to make the report of
the rebased history complete.
It is OK that the commit summary is still suppressed when git-commit
is used to initialize the authorship of the sentinel commit because
this additional commit is an implementation detail hidden from the
final history. The removed `-q` option was probably introduced as a
copy-and-paste error stemming from that part of the root commit
handling code.
I'm confused. This implies that we should be seeing summaries for other
commits, but not root commits, and this patch is bring them into
harmony. But if I have a repo like this:
git init -q repo &&
cd repo &&
for i in one two; do
echo $i >file &&
git add file &&
git commit -q -m $i
done
then using stock git gives me this:
$ GIT_EDITOR=true git rebase -i --root 2>&1 | perl -pe 's/\r/\\r\n/g'
Rebasing (1/2)\r
Rebasing (2/2)\r
Successfully rebased and updated refs/heads/master.
but with your patch, I get:
$ GIT_EDITOR=true git.compile rebase -i --root 2>&1 | perl -pe 's/\r/\\r\n/g'
Rebasing (1/2)\r
[detached HEAD 60834b3] one
Date: Fri Aug 1 20:00:05 2014 -0400
1 file changed, 1 insertion(+)
create mode 100644 file
Rebasing (2/2)\r
Successfully rebased and updated refs/heads/master.
Am I misunderstanding the purpose of the patch?
-Peff
From: Jeff King <hidden> Date: 2016-06-15 23:02:07
On Tue, Jul 29, 2014 at 01:18:08AM +0200, Fabian Ruch wrote:
The command line used to recreate root commits specifies the
effectless option `-C`. It makes git-commit reuse commit message and
authorship of the named commit. However, the commit being amended
here, which is the sentinel commit, already carries the authorship
and log message of the commit being replayed. Remove the option.
Since `-C` (in contrast to `-c`) does not invoke the editor and the
`--amend` option invokes it by default, disable editor invocation
again by specifying `--no-edit`.
I found this description a little backwards. The "-C" does have an
effect, as you noticed in the second paragraph.
I think the reasoning is more like:
The command line used to recreate root commits uses "-C" to
suppress the commit editor. This is unnecessarily confusing,
though, because that suppression is a secondary effect of the
option. The main purpose of "-C" is to pull the metadata from
another commit, but here we know that this is a noop, since we
are amending a commit just created from the same data.
At the time, commit did not yet know "--no-edit", and this was a
reasonable way to get the desired behavior. We can switch it to
use "--no-edit" to make the intended effect more obvious.
-Peff
From: Jeff King <hidden> Date: 2016-06-15 23:02:07
On Tue, Jul 29, 2014 at 01:18:09AM +0200, Fabian Ruch wrote:
The options passed to `do_pick` determine whether the picked commit
will be rewritten or not. If the commit gets rewritten, because the
user requested to edit the commit message for instance, let
`pick_one` merely apply the changes introduced by the commit and do
not commit the resulting tree yet. If the commit is replayed as is,
leave it to `pick_one` to recreate the commit (possibly by
fast-forwarding the head). This makes it easier to combine git-commit
options like `--edit` and `--amend` in `do_pick` because
git-cherry-pick does not support `--amend`.
In the case of `--edit`, do not `exit_with_patch` but assign
`rewrite` to pick the changes with `-n`. If the pick conflicts, no
commit is created which we would have to amend when continuing the
rebase. To complete the pick after the conflicts are resolved the
user just resumes with `git rebase --continue`.
Hmm. So does this mean the user will actually see a different state
during such a conflict?
E.g., if I have instructions like:
pick A
squash B
squash C
and there is a conflict picking C, then what state do I see? Right now I
see a commit with the A+B squash prepared. But your description sounds
to me like we would avoid the squash for "B", and the user would see a
different state.
However, I couldn't trigger that behavior in a few experiments. Am I
misunderstanding, or is there some case where the user-visible state
will be different?
-Peff
From: Jeff King <hidden> Date: 2016-06-15 23:02:07
On Tue, Jul 29, 2014 at 01:18:00AM +0200, Fabian Ruch wrote:
this is a reroll of the patch series that enables rudimentary support
of line options for git-rebase's to-do list commands and reimplements
the well-known commands `reword` and `squash` in terms of a
parameterised `do_pick`.
I just finished reading over the whole series (which is my first real
exposure to it). With the exception of the comments I already sent, it
looks pretty reasonable to me.
Thanks for splitting it and writing good commit messages; that made it
relatively easy to follow what was going on.
-Peff
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:07
Hi Peff,
Jeff King writes:
On Tue, Jul 29, 2014 at 01:18:00AM +0200, Fabian Ruch wrote:
quoted
this is a reroll of the patch series that enables rudimentary support
of line options for git-rebase's to-do list commands and reimplements
the well-known commands `reword` and `squash` in terms of a
parameterised `do_pick`.
I just finished reading over the whole series (which is my first real
exposure to it). With the exception of the comments I already sent, it
looks pretty reasonable to me.
Thanks for splitting it and writing good commit messages; that made it
relatively easy to follow what was going on.
Thanks a lot for taking the time.
Your review revealed more shortcomings of the patch series. Now that the
replay of root commits is logged, the log is dumped on the console even
in non-verbose mode. And, I must admit that the fact that `--no-edit`
hasn't been a (documented) feature of git-commit for all time didn't
struck me at all as a possible reason for using `-C`, which is a little
embarrassing.
I will include more details in separate replies to your comments later.
Fabian
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:08
Hi,
Jeff King writes:
quoted hunk
On Tue, Jul 29, 2014 at 01:18:03AM +0200, Fabian Ruch wrote:
quoted
Specify the git-commit option `--no-verify` to disable the pre-commit
hook when editing the log message. Because `--no-verify` also skips
the commit-msg hook, execute the hook from within
git-rebase--interactive after the commit is created. Fortunately, the
commit message is still available in `$GIT_DIR/COMMIT_EDITMSG` after
git-commit terminates. Caveat: In case the commit-msg hook finds the
new log message ill-formatted, the user is only notified of the
failed commit-msg hook but the log message is used for the commit
anyway. git-commit ought to offer more fine-grained control over
which hooks are executed.
Thanks for a nice explanation of the tradeoff. Have you looked at adding
an option to git-commit? We already have --no-post-rewrite. I think you
would just need:
@@ -661,7 +662,8 @@ static int prepare_to_commit(const char *index_file, const char *prefix,/* This checks and barfs if author is badly specified */determine_author_info(author_ident);-if(!no_verify&&run_commit_hook(use_editor,index_file,"pre-commit",NULL))+if(!no_verify&&!no_pre_commit&&+run_commit_hook(use_editor,index_file,"pre-commit",NULL))return0;if(squash_message){
@@ -1604,6 +1606,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)N_("terminate entries with NUL")),OPT_BOOL(0,"amend",&amend,N_("amend previous commit")),OPT_BOOL(0,"no-post-rewrite",&no_post_rewrite,N_("bypass post-rewrite hook")),+OPT_BOOL(0,"no-pre-commit",&no_pre_commit,N_("bypass pre-commit hook")),{OPTION_STRING,'u',"untracked-files",&untracked_files_arg,N_("mode"),N_("show untracked files, optional modes: all, normal, no. (Default: all)"),PARSE_OPT_OPTARG,NULL,(intptr_t)"all"},/* end commit contents options */
though I would also not be opposed to some more uniform hook selection
mechanism (e.g., "--no-verify=pre-commit" or something).
While the --no-verify= mechanism doesn't add a new option to the
git-commit interface but lets one refine the --no-verify option, users
might find it weird to have an argument to name disabled hooks but then
not be able to disable all hooks that way.
To have that uniform hook selection without duplicating code, we might
want to have something like --bypass-hook= right away. This would cover
--no-post-rewrite as well and add support for disabling
prepare-commit-msg and post-commit, whose execution cannot be controlled
via the git-commit interface at the moment.
Since the hook selection wouldn't have to change, the options parsing
code seems to be simpler (--bypass-hook= would have to support several
occurrences with different arguments which could be implemented as an
OPT_CALLBACK?) and git-commit decided to have --no- options for hook
selection so far, I would lean towards your patch from above.
I know you didn't say anything otherwise, I just wanted to expand a
little. You find an amended version of your patch below that documents
--no-verify as a synonym for --no-pre-commit and --no-commit-msg, and
adds tests.
@@ -667,7 +682,8 @@ static int prepare_to_commit(const char *index_file, const char *prefix,/* This checks and barfs if author is badly specified */determine_author_info(author_ident);-if(!no_verify&&run_commit_hook(use_editor,index_file,"pre-commit",NULL))+if(verify&PRE_COMMIT&&+run_commit_hook(use_editor,index_file,"pre-commit",NULL))return0;if(squash_message){
@@ -1597,7 +1613,9 @@ int cmd_commit(int argc, const char **argv, const char *prefix)OPT_BOOL(0,"interactive",&interactive,N_("interactively add files")),OPT_BOOL('p',"patch",&patch_interactive,N_("interactively add changes")),OPT_BOOL('o',"only",&only,N_("commit only specified files")),-OPT_BOOL('n',"no-verify",&no_verify,N_("bypass pre-commit hook")),+OPT_NEGBIT('n',"no-verify",&verify,+N_("synonym for --no-pre-commit --no-commit-msg"),+PRE_COMMIT|COMMIT_MSG),OPT_BOOL(0,"dry-run",&dry_run,N_("show what would be committed")),OPT_SET_INT(0,"short",&status_format,N_("show status concisely"),STATUS_FORMAT_SHORT),
@@ -1610,6 +1628,12 @@ int cmd_commit(int argc, const char **argv, const char *prefix)OPT_BOOL('z',"null",&s.null_termination,N_("terminate entries with NUL")),OPT_BOOL(0,"amend",&amend,N_("amend previous commit")),+OPT_NEGBIT(0,"no-pre-commit",&verify,+N_("bypass pre-commit hook"),+PRE_COMMIT),+OPT_NEGBIT(0,"no-commit-msg",&verify,+N_("bypass commit-msg hook"),+COMMIT_MSG),OPT_BOOL(0,"no-post-rewrite",&no_post_rewrite,N_("bypass post-rewrite hook")),{OPTION_STRING,'u',"untracked-files",&untracked_files_arg,N_("mode"),N_("show untracked files, optional modes: all, normal, no. (Default: all)"),PARSE_OPT_OPTARG,NULL,(intptr_t)"all"},/* end commit contents options */
Since all of the hook options are motivated by internal usage from
git-rebase, perhaps they should be configured as PARSE_OPT_HIDDEN. Any
thoughts on this?
Fabian
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:08
Hi,
Jeff King writes:
On Tue, Jul 29, 2014 at 01:18:07AM +0200, Fabian Ruch wrote:
quoted
The command line used to recreate root commits specifies the option
`-q` which suppresses the commit summary message. However,
git-rebase--interactive tends to tell the user about the commits it
creates in the final history, if she wishes (cf. command line option
`--verbose`). The code parts handling non-root commits and squash
commits all output commit summary messages. Do not make the replay of
root commits an exception. Remove the option to make the report of
the rebased history complete.
It is OK that the commit summary is still suppressed when git-commit
is used to initialize the authorship of the sentinel commit because
this additional commit is an implementation detail hidden from the
final history. The removed `-q` option was probably introduced as a
copy-and-paste error stemming from that part of the root commit
handling code.
I'm confused. This implies that we should be seeing summaries for other
commits, but not root commits, and this patch is bring them into
harmony. But if I have a repo like this:
git init -q repo &&
cd repo &&
for i in one two; do
echo $i >file &&
git add file &&
git commit -q -m $i
done
then using stock git gives me this:
$ GIT_EDITOR=true git rebase -i --root 2>&1 | perl -pe 's/\r/\\r\n/g'
Rebasing (1/2)\r
Rebasing (2/2)\r
Successfully rebased and updated refs/heads/master.
but with your patch, I get:
$ GIT_EDITOR=true git.compile rebase -i --root 2>&1 | perl -pe 's/\r/\\r\n/g'
Rebasing (1/2)\r
[detached HEAD 60834b3] one
Date: Fri Aug 1 20:00:05 2014 -0400
1 file changed, 1 insertion(+)
create mode 100644 file
Rebasing (2/2)\r
Successfully rebased and updated refs/heads/master.
Am I misunderstanding the purpose of the patch?
Thanks for laying out the differences in the user visible output. With
stock git we are seeing summaries for other commits, but not root
commits, _with the --verbose option_. It's the fault of my patch to show
the summary even in non-verbose mode. This is now fixed by wrapping the
relevant command in 'output', a shell function defined in git-rebase.sh
as follows:
The problem that git-rebase--interactive has is that the redirection of
stdin to a variable (or a file) does not work reliably with commands
that invoke the log message editor, that is 'reword' and 'squash'
produce their output both in verbose and non-verbose mode. I wouldn't
know how to fix this but
1) invoking $GIT_EDITOR from git-rebase--interactive.sh, but to make
this right there should be a built-in command for shell scripts and an
interface for git-commit that prepare the editor contents like
git-commit does now, or
2) forcing $GIT_EDITOR and git-commit to print on distinct file
descriptors, which would involve temporarily wrapping the $GIT_EDITOR
call in a shell script that redirects stdin to some other file
descriptor similar to what t/test-lib.sh does, or
3) passing the --quiet option in non-verbose mode and omitting it in
verbose mode, which would cover the '$status != 0' above for if a
command fails, it should indicate its error status despite being asked
to be silent.
Options 2) and 3) seem attainable within this patch series and 3) sounds
like the cleanest option but I'm uncertain if I'm missing something
here. The only command line that is wrapped in 'output' and that doesn't
support a --quiet option seems to be a 'warn' line which could simply be
skipped in non-verbose mode. (Johannes Schindelin is cc'd as the
original author of git-rebase--interactive.sh and 'output' in particular).
Fabian
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:08
Hi Jeff,
Jeff King writes:
On Tue, Jul 29, 2014 at 01:18:08AM +0200, Fabian Ruch wrote:
quoted
The command line used to recreate root commits specifies the
effectless option `-C`. It makes git-commit reuse commit message and
authorship of the named commit. However, the commit being amended
here, which is the sentinel commit, already carries the authorship
and log message of the commit being replayed. Remove the option.
Since `-C` (in contrast to `-c`) does not invoke the editor and the
`--amend` option invokes it by default, disable editor invocation
again by specifying `--no-edit`.
I found this description a little backwards. The "-C" does have an
effect, as you noticed in the second paragraph.
I think the reasoning is more like:
The command line used to recreate root commits uses "-C" to
suppress the commit editor. This is unnecessarily confusing,
though, because that suppression is a secondary effect of the
option. The main purpose of "-C" is to pull the metadata from
another commit, but here we know that this is a noop, since we
are amending a commit just created from the same data.
At the time, commit did not yet know "--no-edit", and this was a
reasonable way to get the desired behavior. We can switch it to
use "--no-edit" to make the intended effect more obvious.
Thanks again, I shamelessly copied your formulation but squeezed in an
"undocumented" because --no-edit had just been implemented (commit
ca1ba2010), though was then still missing from the git-commit manpage.
Fabian
From: Jeff King <hidden> Date: 2016-06-15 23:02:09
On Mon, Aug 04, 2014 at 08:51:42PM +0200, Fabian Ruch wrote:
quoted
though I would also not be opposed to some more uniform hook selection
mechanism (e.g., "--no-verify=pre-commit" or something).
While the --no-verify= mechanism doesn't add a new option to the
git-commit interface but lets one refine the --no-verify option, users
might find it weird to have an argument to name disabled hooks but then
not be able to disable all hooks that way.
Right, I think that is only worth doing if we add it uniformly for all
hooks. I wonder if it should be a "git" option, not one to specific
commands. Like:
git --disable-hook=pre-commit commit ...
and then the run_hook code can just respect the disabled list.
I think a name like "--disable-hook" or your "--bypass-hook" is
better than "--no-verify" here, too. Not all hooks are about verifying
(I also think "disable" is better than "bypass" for that reason, too).
Since the hook selection wouldn't have to change, the options parsing
code seems to be simpler (--bypass-hook= would have to support several
occurrences with different arguments which could be implemented as an
OPT_CALLBACK?) and git-commit decided to have --no- options for hook
selection so far, I would lean towards your patch from above.
You'd probably implement --disable-hook with OPT_STRING_LIST (or just do
it by hand if it's the git.c option parser). And then the
--no-post-rewrite arguments remain for historical compatibility, and can
be implemented as synonyms for "--disable-hook=post-rewrite", etc.
I think people have also asked for the ability to override hooks, too,
though I do not remember the exact details. Instead of --disable-hook,
we could have an option for setting specific hooks (and setting them to
nothing to disable would just be one possibility).
This is getting bigger in scope, though. I was trying not to derail you
too much from your GSoC project, but see if we could just fix this one
hacky corner easily.
Since all of the hook options are motivated by internal usage from
git-rebase, perhaps they should be configured as PARSE_OPT_HIDDEN. Any
thoughts on this?
I could go either way. Just because they are motivated by git-rebase
does not mean other callers might not find them useful (after all, git
commands are often meant to be scripted). As long as we promise to
support them in future versions as we do with normal options, I do not
think there is any problem in advertising them.
That being said, "git commit -h" is already getting pretty long. It
might be worth cutting some seldom-used options from that list just to
make it more palatable to normal users.
-Peff
From: Jeff King <hidden> Date: 2016-06-15 23:02:09
On Mon, Aug 04, 2014 at 11:21:41PM +0200, Fabian Ruch wrote:
Thanks for laying out the differences in the user visible output. With
stock git we are seeing summaries for other commits, but not root
commits, _with the --verbose option_. It's the fault of my patch to show
the summary even in non-verbose mode. This is now fixed by wrapping the
relevant command in 'output', a shell function defined in git-rebase.sh
as follows:
The problem that git-rebase--interactive has is that the redirection of
stdin to a variable (or a file) does not work reliably with commands
that invoke the log message editor, that is 'reword' and 'squash'
produce their output both in verbose and non-verbose mode. I wouldn't
know how to fix this but
1) invoking $GIT_EDITOR from git-rebase--interactive.sh, but to make
this right there should be a built-in command for shell scripts and an
interface for git-commit that prepare the editor contents like
git-commit does now, or
2) forcing $GIT_EDITOR and git-commit to print on distinct file
descriptors, which would involve temporarily wrapping the $GIT_EDITOR
call in a shell script that redirects stdin to some other file
descriptor similar to what t/test-lib.sh does, or
Hmm. In the test scripts, we send stdout and stderr for sub-commands to
fds 3 and 4 respectively. And then we either point those at /dev/null or
to >&1 and >&2, depending on whether $verbose mode was specified.
I don't think that will work here, though. You literally have one "git
commit" command to run, and you want its stderr/stdout to go somewhere
different than the $GIT_EDITOR it will invoke. Your (2) makes some sense
to me. Something like:
GIT_EDITOR="$(shellquote "$(git var GIT_EDITOR)") >&3 2>&4" \
git commit ... 3>&1 4>&2 >wherever 2>&1
Or we could just point it at /dev/tty, though I guess that may open
another can of worms (systems without /dev/tty, what happens when you do
not have a terminal, etc).
3) passing the --quiet option in non-verbose mode and omitting it in
verbose mode, which would cover the '$status != 0' above for if a
command fails, it should indicate its error status despite being asked
to be silent.
Yeah, that is probably the cleanest option if it works. I would just
worry that it is not as complete. It works for "git commit", but are
there are other commands wrapped in the verbose output that would want
the same treatment (that might not know about --quiet)? Your paragraph
below says it would not be that big a deal, so as long as we don't plan
to add anything in the future that could not handle the requirement,
that may be enough.
-Peff
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:09
Hi List,
this is the second reroll of the patch series fixing corner-case bugs
regarding empty commits, commits with no log message and root
commits, providing a uniform implementation of the to-do list
commands using the `do_pick` interface.
This reroll includes the following list of changes to PATCH v1 from
last week, mostly induced by Jeff's comments. However, I didn't get
around the most recent discussion from tonight yet.
- new tests: allow replaying commits with empty log messages
- coverage of all to-do list commands
- new patch: allow squashing empty commits without complaints
- do not complain about an empty squash commit unless it is the
final one and --keep-empty is not specified on the command line
- new tests: allow rewording empty commits without complaints
- coverage of all to-do list commands
- new patch: hide interactive command messages in verbose mode
- make it possible to launch an editor inside 'output'
- new patch: allow disabling pre-commit and commit-msg separately
- add options --no-pre-commit and --no-commit-msg to git-commit
- redefine --no-verify as synonym for the above two
- new patch: squash skips commit-msg hook
- run commit-msg hook for reworded _and_ squashed commits
- a change to 'test_commit' options and 'fake_editor' debug output
Thanks for your time and reviews,
Fabian
Fabian Ruch (23):
rebase -i: allow replaying commits with empty log messages
rebase -i: allow squashing empty commits without complaints
rebase -i: allow rewording empty commits without complaints
rebase -i: hide interactive command messages in verbose mode
rebase -i: failed reword prints redundant error message
commit: allow disabling pre-commit and commit-msg separately
rebase -i: squash skips commit-msg hook
rebase -i: reword executes pre-commit hook on interim commit
rebase -i: teach do_pick the option --edit
rebase -i: implement reword in terms of do_pick
rebase -i: log the replay of root commits
rebase -i: root commits are replayed with an unnecessary option
rebase -i: commit only once when rewriting picks
rebase -i: do not die in do_pick
rebase -i: teach do_pick the option --amend
rebase -i: teach do_pick the option --file
rebase -i: prepare for squash in terms of do_pick --amend
rebase -i: implement squash in terms of do_pick
rebase -i: explicitly distinguish replay commands and exec tasks
rebase -i: parse to-do list command line options
rebase -i: teach do_pick the option --reset-author
rebase -i: teach do_pick the option --signoff
rebase -i: enable options --signoff, --reset-author for pick, reword
Documentation/git-commit.txt | 8 +-
builtin/commit.c | 32 ++++-
git-rebase--interactive.sh | 288 ++++++++++++++++++++++++++++++++++--------
git-rebase.sh | 12 +-
t/lib-rebase.sh | 8 +-
t/t3404-rebase-interactive.sh | 234 ++++++++++++++++++++++++++++++++--
t/t3406-rebase-message.sh | 18 +++
t/t3412-rebase-root.sh | 16 +++
t/t7503-pre-commit-hook.sh | 65 ++++++++--
t/t7504-commit-msg-hook.sh | 85 ++++++++++---
t/test-lib-functions.sh | 23 +++-
11 files changed, 680 insertions(+), 109 deletions(-)
--
2.0.1
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:09
git-rebase--interactive handles empty log messages inconsistently
between enabled and disabled fast-forwards. By default, commits with
empty log messages are rebased successfully like in non-interactive
mode. In contrast, the `--no-ff` option aborts the replay of such
commits.
In line with not verifying rebased commits and behaving like
git-rebase for `pick` lines, use the `--allow-empty-message` option
to replay commits. Root commits are replayed by recreating them in
`do_pick` using git-commit and all other commits are replayed using
git-cherry-pick in `pick_one`. Apply the option, understood by both
git-commit and git-cherry-pick, at the respective sites.
In case of `reword` and `squash`, continue to abort the rebase if the
_resulting_ commit would have no commit message. The rationale behind
this default is that patches and their log messages should be
verified at least once. For unchanged commits this is assumed to have
happened according to the author's standards when she created the
commits for the first time. While the empty log message can always be
kept in place by editing and resuming the aborted rebase, a debatable
alternative could be to teach git-rebase--interactive the option
`--allow-empty-message` for disabling complaints about empty log
messages even in changed commits.
The `fixup` case is different again because it throws away the second
commit's log message and uses the first log message for the changed
commit. Do not abort the rebase if that message is empty either since
it is assumed to have been verified already.
The remaining to-do list command `edit` is handled just like `pick`
for this matter, because git-rebase--interactive replays the named
commit without changes before the rebase is interrupted and the user
can make her changes to the replayed commit.
Add tests. In particular, design the `squash`-specific test case such
that it involves interim commits and `fixup` steps. Interim commits
should not trigger failures themselves and `fixup` steps should not
let git-rebase--interactive forget that it is still dealing with a
`squash` result.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 10 ++++++----
t/t3404-rebase-interactive.sh | 38 ++++++++++++++++++++++++++++++++++++++
t/t3412-rebase-root.sh | 16 ++++++++++++++++
3 files changed, 60 insertions(+), 4 deletions(-)
@@ -363,7 +363,7 @@ pick_one_preserving_merges () {echo"$sha1$(gitrev-parseHEAD^0)">>"$rewritten_list";;*)-outputevalgitcherry-pick\+outputevalgitcherry-pick--allow-empty-message\${gpg_sign_opt:+$(gitrev-parse--sq-quote"$gpg_sign_opt")}\"$strategy_args""$@"||die_with_patch$sha1"Could not pick $sha1"
@@ -549,7 +549,8 @@ do_next () {squash|s|fixup|f)# This is an intermediate commit; its message will only be# used in case of trouble. So use the long version:-do_with_authoroutputgitcommit--amend--no-verify-F"$squash_msg"\+do_with_authoroutputgitcommit--allow-empty-message\+--amend--no-verify-F"$squash_msg"\${gpg_sign_opt:+"$gpg_sign_opt"}||die_failed_squash$sha1"$rest";;
@@ -557,7 +558,8 @@ do_next () {# This is the final command of this squash/fixup groupiftest-f"$fixup_msg"then-do_with_authorgitcommit--amend--no-verify-F"$fixup_msg"\+do_with_authorgitcommit--allow-empty-message\+--amend--no-verify-F"$fixup_msg"\${gpg_sign_opt:+"$gpg_sign_opt"}||die_failed_squash$sha1"$rest"else
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:09
The to-do list commands `squash` and `fixup` apply the changes
introduced by the named commit to the tree but instead of creating
a new commit on top of the current head it replaces the previous
commit with a new commit that records the updated tree. If the
result is an empty commit git-rebase stops with the error message
You asked to amend the most recent commit, but doing so would make
it empty. You can repeat your command with --allow-empty, or you can
remove the commit entirely with "git reset HEAD^".
This message is not very helpful because neither does git-rebase
support an option `--allow-empty` nor does the messages say how to
resume the rebase. Firstly, change the error message to
The squash result is empty and --keep-empty was not specified.
You can remove the squash commit now with
git reset HEAD^
Once you are down, run
git rebase --continue
If the user wishes to squash a sequence of commits into one
commit, f. i.
pick A
squash Revert "A"
squash A'
, it does not matter for the end result that the first squash
result, or any sub-sequence in general, is going to be empty. The
squash message is not affected at all by which commits are created
and only the commit created by the last line in the sequence will
end up in the final history. Secondly, print the error message
only if the whole squash sequence produced an empty commit.
Lastly, since an empty squash commit is not a failure to rewrite
the history as planned, issue the message above as a mere warning
and interrupt the rebase with the return value zero. The
interruption should be considered as a notification with the
chance to undo it on the spot. Specifying the `--keep-empty`
option tells git-rebase to keep empty squash commits in the
rebased history without notification.
Add tests.
Reported-by: Peter Krefting <redacted>
Signed-off-by: Fabian Ruch <redacted>
---
Hi,
Peter Krefting is cc'd as the author of the bug report "Confusing
error message in rebase when commit becomes empty" discussed on the
mailing list in June. Phil Hord and Jeff King both participated in
the problem discussion which ended with two proposals by Jeff.
Jeff King writes:
1. Always keep such empty commits. A user who is surprised by them
being empty can then revisit them. Or drop them by doing another
rebase without --keep-empty.
2. Notice ourselves that the end-result of the whole squash is an
empty commit, and stop to let the user deal with it.
This patch chooses the second alternative. Either way seems OK. The
crucial consensus of the discussion was to silently throw away empty
interim commits.
Fabian
git-rebase--interactive.sh | 20 +++++++++++---
t/t3404-rebase-interactive.sh | 62 +++++++++++++++++++++++++++++++++++++++++++
2 files changed, 79 insertions(+), 3 deletions(-)
@@ -549,7 +549,7 @@ do_next () {squash|s|fixup|f)# This is an intermediate commit; its message will only be# used in case of trouble. So use the long version:-do_with_authoroutputgitcommit--allow-empty-message\+do_with_authoroutputgitcommit--allow-empty-message--allow-empty\--amend--no-verify-F"$squash_msg"\${gpg_sign_opt:+"$gpg_sign_opt"}||die_failed_squash$sha1"$rest"
@@ -558,18 +558,32 @@ do_next () {# This is the final command of this squash/fixup groupiftest-f"$fixup_msg"then-do_with_authorgitcommit--allow-empty-message\+do_with_authorgitcommit--allow-empty-message--allow-empty\--amend--no-verify-F"$fixup_msg"\${gpg_sign_opt:+"$gpg_sign_opt"}||die_failed_squash$sha1"$rest"elsecp"$squash_msg""$GIT_DIR"/SQUASH_MSG||exitrm-f"$GIT_DIR"/MERGE_MSG-do_with_authorgitcommit--amend--no-verify-F"$GIT_DIR"/SQUASH_MSG-e\+do_with_authorgitcommit--allow-empty--amend--no-verify-F"$GIT_DIR"/SQUASH_MSG-e\${gpg_sign_opt:+"$gpg_sign_opt"}||die_failed_squash$sha1"$rest"firm-f"$squash_msg""$fixup_msg"+iftest-z"$keep_empty"&&is_empty_commitHEAD+then+echo"$sha1">"$state_dir"/stopped-sha+warn"The squash result is empty and --keep-empty was not specified."+warn+warn"You can remove the squash commit now with"+warn+warn" git reset HEAD^"+warn+warn"Once you are down, run"+warn+warn" git rebase --continue"+exit0+fi;;esacrecord_in_rewritten$sha1
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:09
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. If `--keep-empty` is
passed as option to git-rebase--interactive, empty commits ought to
be replayed without complaints. However, if the users chooses to
reword an empty commit by changing the respective to-do list entry
from
pick fa1afe1 Empty commit
to
reword fa1afe1 Empty commit
, then git-rebase--interactive suddenly fails to replay the empty
commit. This is especially counterintuitive because `reword` is
thought of as a `pick` that alters the log message in some way but
nothing more and the unchanged to-do list entry would not fail.
Handle `reword` by cherry-picking the named commit and editing the
log message using
git commit --allow-empty --amend
instead of
git commit --amend.
Add test.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 2 +-
t/t3404-rebase-interactive.sh | 24 ++++++++++++++++++++++++
2 files changed, 25 insertions(+), 1 deletion(-)
@@ -504,7 +504,7 @@ do_next () {mark_action_donedo_pick$sha1"$rest"-gitcommit--amend--no-post-rewrite${gpg_sign_opt:+"$gpg_sign_opt"}||{+gitcommit--allow-empty--amend--no-post-rewrite${gpg_sign_opt:+"$gpg_sign_opt"}||{warn"Could not amend commit after successfully picking $sha1... $rest"warn"This is most likely due to an empty commit message, or the pre-commit hook"warn"failed. If the pre-commit hook failed, you may need to resolve the issue before"
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:09
git-rebase--interactive prints summary messages of the commits it
creates in the final history only if the `--verbose` option is
specified by the user and suppresses them otherwise. This behaviour
is implemented by wrapping git-commit calls in a shell function named
`output` which redirects stderr to stdout, captures stdout in a shell
variable and ignores its contents unless the command exits with an
error status.
The command lines used to implement the to-do list commands `reword`
and `squash` print diagnostic messages even in non-verbose mode. The
reason for this inconsistency is that both commands launch the log
message editor which usually requires a working terminal attached to
stdin. Temporarily redirect the editor output to a third file
descriptor in order to ship it around the capture stream. Wrap the
respective git-commit command lines in `output`.
fake_editor prints the to-do list before and after applying the
`FAKE_LINES` rewrite rules to it. Redirect this debug output to
stderr so that it does not interfere with the git-rebase status
output. Add test.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 9 +++++----
git-rebase.sh | 12 ++++++++++--
t/lib-rebase.sh | 8 ++++----
t/t3404-rebase-interactive.sh | 18 ++++++------------
t/t3406-rebase-message.sh | 18 ++++++++++++++++++
5 files changed, 43 insertions(+), 22 deletions(-)
@@ -504,7 +504,7 @@ do_next () {mark_action_donedo_pick$sha1"$rest"-gitcommit--allow-empty--amend--no-post-rewrite${gpg_sign_opt:+"$gpg_sign_opt"}||{+outputgitcommit--allow-empty--amend--no-post-rewrite${gpg_sign_opt:+"$gpg_sign_opt"}||{warn"Could not amend commit after successfully picking $sha1... $rest"warn"This is most likely due to an empty commit message, or the pre-commit hook"warn"failed. If the pre-commit hook failed, you may need to resolve the issue before"
@@ -558,14 +558,14 @@ do_next () {# This is the final command of this squash/fixup groupiftest-f"$fixup_msg"then-do_with_authorgitcommit--allow-empty-message--allow-empty\+do_with_authoroutputgitcommit--allow-empty-message--allow-empty\--amend--no-verify-F"$fixup_msg"\${gpg_sign_opt:+"$gpg_sign_opt"}||die_failed_squash$sha1"$rest"elsecp"$squash_msg""$GIT_DIR"/SQUASH_MSG||exitrm-f"$GIT_DIR"/MERGE_MSG-do_with_authorgitcommit--allow-empty--amend--no-verify-F"$GIT_DIR"/SQUASH_MSG-e\+do_with_authoroutputgitcommit--allow-empty--amend--no-verify-F"$GIT_DIR"/SQUASH_MSG-e\${gpg_sign_opt:+"$gpg_sign_opt"}||die_failed_squash$sha1"$rest"fi
@@ -923,6 +923,8 @@ EOF;;esac+mkdir-p"$state_dir"||die"Could not create temporary $state_dir"+ gitvarGIT_COMMITTER_IDENT>/dev/null||die"You need to set your committer info first"
@@ -938,7 +940,6 @@ thenfiorig_head=$(gitrev-parse--verifyHEAD)||die"No HEAD?"-mkdir-p"$state_dir"||die"Could not create temporary $state_dir" :>"$state_dir"/interactive||die"Could not mark as interactive" write_basic_state
@@ -4,6 +4,8 @@ test_description='messages from rebase operation' ../test-lib.sh+."$TEST_DIRECTORY"/lib-rebase.sh+ test_expect_success'setup''test_commitOfileO&&test_commitXfileX&&
@@ -84,4 +86,20 @@ test_expect_success 'rebase --onto outputs the invalid ref' 'test_i18ngrep"invalid-ref"err'+test_expect_success'commit summary is suppressed in non-verbose mode''+gitcheckout--detachY&&+cat>expected.out<<-EOF&&+Rebasing(1/5)\r+Rebasing(2/5)\r+Rebasing(3/5)\r+Rebasing(4/5)\r+Rebasing(5/5)\r+EOF+set_fake_editor&&+FAKE_LINES="reword 1 fixup 2 fixup 3 4 squash 5"\+gitrebase-i--root>actual.out.tmp&&+sed-e"s/\r/\\\\r\n/g"<actual.out.tmp>actual.out&&+test_cmpexpected.outactual.out+'+ test_done
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:09
Introduce the git-commit command line options `--no-pre-commit` and
`--no-commit-msg` to disable the pre-commit and commit-msg hooks,
respectively. Make `--no-verify` a synonym for specifying both at the
same time.
This change is motivated by an internal usage of git-commit in
git-rebase--interactive to disable pre-commit while keeping
commit-msg enabled when rewording a commit.
Make `test_commit` forward unknown options to git-commit instead of
teaching it all possible options. In order to support leading double
dashes in `<message>`, stop interpreting `test_commit` arguments
following a `--` argument as options. This wasn't a problem before
because the first unknown option would be used as `<message>`.
Allow disabling tag creation to avoid name clashes when using
`test_commit` with the same arguments several times from the same
test suite. By default, `test_commit` tags successful commits using
git-tag for easy reference. The `--notag` option skips this step.
Add tests.
Signed-off-by: Fabian Ruch <redacted>
---
Documentation/git-commit.txt | 8 ++++-
builtin/commit.c | 32 ++++++++++++++---
t/t7503-pre-commit-hook.sh | 65 ++++++++++++++++++++++++++++-----
t/t7504-commit-msg-hook.sh | 85 ++++++++++++++++++++++++++++++++++----------
t/test-lib-functions.sh | 23 ++++++++----
5 files changed, 176 insertions(+), 37 deletions(-)
@@ -158,7 +158,7 @@ OPTIONS -n:: --no-verify::- This option bypasses the pre-commit and commit-msg hooks.+ A synonym for `--no-pre-commit --no-commit-msg`. See also linkgit:githooks[5]. --allow-empty::
@@ -238,6 +238,12 @@ You should understand the implications of rewriting history if you amend a commit that has already been published. (See the "RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)+--no-pre-commit::+ This option bypasses the pre-commit hook.++--no-commit-msg::+ This option bypasses the commit-msg hook.+ --no-post-rewrite:: Bypass the post-rewrite hook.
@@ -661,7 +676,8 @@ static int prepare_to_commit(const char *index_file, const char *prefix,/* This checks and barfs if author is badly specified */determine_author_info(author_ident);-if(!no_verify&&run_commit_hook(use_editor,index_file,"pre-commit",NULL))+if(verify&PRE_COMMIT&&+run_commit_hook(use_editor,index_file,"pre-commit",NULL))return0;if(squash_message){
@@ -1590,7 +1606,9 @@ int cmd_commit(int argc, const char **argv, const char *prefix)OPT_BOOL(0,"interactive",&interactive,N_("interactively add files")),OPT_BOOL('p',"patch",&patch_interactive,N_("interactively add changes")),OPT_BOOL('o',"only",&only,N_("commit only specified files")),-OPT_BOOL('n',"no-verify",&no_verify,N_("bypass pre-commit hook")),+OPT_NEGBIT('n',"no-verify",&verify,+N_("synonym for --no-pre-commit --no-commit-msg"),+PRE_COMMIT|COMMIT_MSG),OPT_BOOL(0,"dry-run",&dry_run,N_("show what would be committed")),OPT_SET_INT(0,"short",&status_format,N_("show status concisely"),STATUS_FORMAT_SHORT),
@@ -1603,6 +1621,12 @@ int cmd_commit(int argc, const char **argv, const char *prefix)OPT_BOOL('z',"null",&s.null_termination,N_("terminate entries with NUL")),OPT_BOOL(0,"amend",&amend,N_("amend previous commit")),+OPT_NEGBIT(0,"no-pre-commit",&verify,+N_("bypass pre-commit hook"),+PRE_COMMIT),+OPT_NEGBIT(0,"no-commit-msg",&verify,+N_("bypass commit-msg hook"),+COMMIT_MSG),OPT_BOOL(0,"no-post-rewrite",&no_post_rewrite,N_("bypass post-rewrite hook")),{OPTION_STRING,'u',"untracked-files",&untracked_files_arg,N_("mode"),N_("show untracked files, optional modes: all, normal, no. (Default: all)"),PARSE_OPT_OPTARG,NULL,(intptr_t)"all"},/* end commit contents options */
@@ -12,11 +12,11 @@ test_expect_success 'with no hook' ''-test_expect_success'--no-verify with no hook''+test_expect_success'--no-pre-commit with no hook''echo"bar">file&&gitaddfile&&-gitcommit--no-verify-m"bar"+gitcommit--no-pre-commit-m"bar"'
@@ -38,11 +38,11 @@ test_expect_success 'with succeeding hook' ''-test_expect_success'--no-verify with succeeding hook''+test_expect_success'--no-pre-commit with succeeding hook''echo"even more">>file&&gitaddfile&&-gitcommit--no-verify-m"even more"+gitcommit--no-pre-commit-m"even more"'
@@ -60,11 +60,11 @@ test_expect_success 'with failing hook' ''-test_expect_success'--no-verify with failing hook''+test_expect_success'--no-pre-commit with failing hook''echo"stuff">>file&&gitaddfile&&-gitcommit--no-verify-m"stuff"+gitcommit--no-pre-commit-m"stuff"'
@@ -77,15 +77,64 @@ test_expect_success POSIXPERM 'with non-executable hook' ''-test_expect_successPOSIXPERM'--no-verify with non-executable hook''+test_expect_successPOSIXPERM'--no-pre-commit with non-executable hook''echo"more content">>file&&gitaddfile&&-gitcommit--no-verify-m"more content"+gitcommit--no-pre-commit-m"more content"' chmod+x"$HOOK"+test_hook_enabled(){+gitcheckout--detachmaster&&+output="running failing pre-commit hook with ${*:-(none)}..."&&+>actual.output&&+cat>"$HOOK"<<-EOF&&+#!/bin/sh+echo"$output">>actual.output+exit1+EOF+chmod+x"$HOOK"&&+echo"$output">expected.output&&+test_must_failtest_commit$*file&&+test_cmpexpected.outputactual.output+}++test_hook_disabled(){+gitcheckout--detachmaster&&+output="running failing pre-commit hook with ${*:-(none)}..."&&+>actual.output&&+cat>"$HOOK"<<-EOF&&+#!/bin/sh+echo"$output">>actual.output+exit1+EOF+chmod+x"$HOOK"&&+test_commit--notag$*file&&+test_must_be_emptyactual.output+}++test_expect_success'command line options combinations''+test_hook_enabled&&+test_hook_enabled--pre-commit&&+test_hook_enabled--no-pre-commit--pre-commit&&+test_hook_enabled--no-verify--pre-commit&&+test_hook_enabled--verify&&+test_hook_enabled--no-pre-commit--verify&&+test_hook_enabled--no-verify--verify&&+test_hook_enabled--verify--no-commit-msg&&+test_hook_enabled--verify--commit-msg&&+test_hook_disabled--no-pre-commit&&+test_hook_disabled--pre-commit--no-pre-commit&&+test_hook_disabled--pre-commit--no-verify&&+test_hook_disabled--no-verify&&+test_hook_disabled--verify--no-pre-commit&&+test_hook_disabled--verify--no-verify&&+test_hook_disabled--no-verify--no-commit-msg&&+test_hook_disabled--no-verify--commit-msg+'+# a hook that checks $GIT_PREFIX and succeeds inside the# success/ subdirectory only cat>"$HOOK"<<EOF
@@ -34,20 +34,20 @@ test_expect_success 'with no hook (editor)' ''-test_expect_success'--no-verify with no hook''+test_expect_success'--no-commit-msg with no hook''echo"bar">file&&gitaddfile&&-gitcommit--no-verify-m"bar"+gitcommit--no-commit-msg-m"bar"'-test_expect_success'--no-verify with no hook (editor)''+test_expect_success'--no-commit-msg with no hook (editor)''echo"more bar">file&&gitaddfile&&echo"more bar">FAKE_MSG&&-GIT_EDITOR="\"\$FAKE_EDITOR\""gitcommit--no-verify+GIT_EDITOR="\"\$FAKE_EDITOR\""gitcommit--no-commit-msg'
@@ -78,20 +78,20 @@ test_expect_success 'with succeeding hook (editor)' ''-test_expect_success'--no-verify with succeeding hook''+test_expect_success'--no-commit-msg with succeeding hook''echo"even more">>file&&gitaddfile&&-gitcommit--no-verify-m"even more"+gitcommit--no-commit-msg-m"even more"'-test_expect_success'--no-verify with succeeding hook (editor)''+test_expect_success'--no-commit-msg with succeeding hook (editor)''echo"even more more">>file&&gitaddfile&&echo"even more more">FAKE_MSG&&-GIT_EDITOR="\"\$FAKE_EDITOR\""gitcommit--no-verify+GIT_EDITOR="\"\$FAKE_EDITOR\""gitcommit--no-commit-msg'
@@ -118,20 +118,20 @@ test_expect_success 'with failing hook (editor)' ''-test_expect_success'--no-verify with failing hook''+test_expect_success'--no-commit-msg with failing hook''echo"stuff">>file&&gitaddfile&&-gitcommit--no-verify-m"stuff"+gitcommit--no-commit-msg-m"stuff"'-test_expect_success'--no-verify with failing hook (editor)''+test_expect_success'--no-commit-msg with failing hook (editor)''echo"more stuff">>file&&gitaddfile&&echo"more stuff">FAKE_MSG&&-GIT_EDITOR="\"\$FAKE_EDITOR\""gitcommit--no-verify+GIT_EDITOR="\"\$FAKE_EDITOR\""gitcommit--no-commit-msg'
@@ -153,23 +153,72 @@ test_expect_success POSIXPERM 'with non-executable hook (editor)' ''-test_expect_successPOSIXPERM'--no-verify with non-executable hook''+test_expect_successPOSIXPERM'--no-commit-msg with non-executable hook''echo"more content">>file&&gitaddfile&&-gitcommit--no-verify-m"more content"+gitcommit--no-commit-msg-m"more content"'-test_expect_successPOSIXPERM'--no-verify with non-executable hook (editor)''+test_expect_successPOSIXPERM'--no-commit-msg with non-executable hook (editor)''echo"even more content">>file&&gitaddfile&&echo"even more content">FAKE_MSG&&-GIT_EDITOR="\"\$FAKE_EDITOR\""gitcommit--no-verify+GIT_EDITOR="\"\$FAKE_EDITOR\""gitcommit--no-commit-msg'+test_hook_enabled(){+gitcheckout--detachmaster&&+output="running failing commit-msg hook with ${*:-(none)}..."&&+>actual.output&&+cat>"$HOOK"<<-EOF&&+#!/bin/sh+echo"$output">>actual.output+exit1+EOF+chmod+x"$HOOK"&&+echo"$output">expected.output&&+test_must_failtest_commit$*file&&+test_cmpexpected.outputactual.output+}++test_hook_disabled(){+gitcheckout--detachmaster&&+output="running failing commit-msg hook with ${*:-(none)}..."&&+>actual.output&&+cat>"$HOOK"<<-EOF&&+#!/bin/sh+echo"$output">>actual.output+exit1+EOF+chmod+x"$HOOK"&&+test_commit--notag$*file&&+test_must_be_emptyactual.output+}++test_expect_success'command line options combinations''+test_hook_enabled&&+test_hook_enabled--commit-msg&&+test_hook_enabled--no-commit-msg--commit-msg&&+test_hook_enabled--no-verify--commit-msg&&+test_hook_enabled--verify&&+test_hook_enabled--no-commit-msg--verify&&+test_hook_enabled--no-verify--verify&&+test_hook_enabled--verify--no-pre-commit&&+test_hook_enabled--verify--pre-commit&&+test_hook_disabled--no-commit-msg&&+test_hook_disabled--commit-msg--no-commit-msg&&+test_hook_disabled--commit-msg--no-verify&&+test_hook_disabled--no-verify&&+test_hook_disabled--verify--no-commit-msg&&+test_hook_disabled--verify--no-verify&&+test_hook_disabled--no-verify--no-pre-commit&&+test_hook_disabled--no-verify--pre-commit+'+# now a hook that edits the commit message cat>"$HOOK"<<'EOF'#!/bin/sh
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:09
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. This happens in two
steps. Firstly, the named commit is cherry-picked. Secondly, the
commit created in the first step is amended using an unchanged index
to edit the log message. The pre-commit hook is meant to verify the
changes introduced by a commit (for instance, catching inserted
trailing white space). Since the committed tree is not changed
between the two steps and we do not verify rebased patches, do not
execute the pre-commit hook in the second step.
Specify the git-commit option `--no-pre-commit` to disable the
pre-commit hook when editing the log message. The commit-msg hook
will still be executed to verify the edited commit log message. As
before, if the hook finds the new log message ill-formatted, the
rebase will be interrupted with the unchanged commit replayed and the
new log message in `$GIT_DIR/COMMIT_EDITMSG`.
Add tests.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 2 +-
t/t3404-rebase-interactive.sh | 14 ++++++++++++++
2 files changed, 15 insertions(+), 1 deletion(-)
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:09
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. If the edited log
message is empty or is found ill-formatted by one of the commit
hooks, git-rebase--interactive prints three error messages to the
console.
1. The git-commit output, which contains all the output from hook
scripts.
2. A rebase diagnosis saying at which task on the to-do list it
got stuck.
3. Generic presumptions about what could have triggered the
error.
The third message contains redundant information and does not add any
enlightenment either, which makes the output unnecessarily longish
and different from the other command's output. For instance, this is
what the output looks like if the log message is empty (contains
duplicate Signed-off-by lines).
(1.) Aborting commit due to empty commit message. (Duplicate Signed-off-by lines.)
(2.) Could not amend commit after successfully picking fa1afe1... Some change
(3.) This is most likely due to an empty commit message, or the pre-commit hook
failed. If the pre-commit hook failed, you may need to resolve the issue before
you are able to reword the commit.
Discard the third message.
It is true that a failed hook script might not output any diagnosis
but then the generic message is not of much help either. Since this
lack of information affects the built-in git commands for commit,
merge and cherry-pick first, the solution would be to keep track of
the failed hooks in their output so that the user knows which of her
hooks require improvement.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 3 ---
1 file changed, 3 deletions(-)
@@ -506,9 +506,6 @@ do_next () {do_pick$sha1"$rest"outputgitcommit--allow-empty--amend--no-post-rewrite${gpg_sign_opt:+"$gpg_sign_opt"}||{warn"Could not amend commit after successfully picking $sha1... $rest"-warn"This is most likely due to an empty commit message, or the pre-commit hook"-warn"failed. If the pre-commit hook failed, you may need to resolve the issue before"-warn"you are able to reword the commit."exit_with_patch$sha11}record_in_rewritten$sha1
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:09
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement the to-do list command `pick`. To cater for
the different pick behaviours (like `reword`), `do_pick` accepts
several options not only from the git-cherry-pick but also the
git-commit interface. Add the common option `--edit` to let the user
edit the log message of the named commit.
Loop over `$@` to parse the `do_pick` arguments. Assign the local
variable `edit` if one of the options is `--edit` so that the
remainder of `do_pick` can easily check whether the client code asked
to edit the commit message. If one of the options is unknown, mention
it on the console and `die`. Break the loop on the first non-option
and do some sanity checking to ensure that there exactly two
non-options, which are interpreted by the remainder as `<commit>` and
`<title>` like before.
`do_pick` ought to act as a wrapper around `cherry-pick`.
Unfortunately, it cannot just forward `--edit` to the `cherry-pick`
command line. The assembled command line is executed within a command
substitution for controlling the verbosity of `rebase--interactive`.
Passing `--edit` would either hang the terminal or clutter the
substituted command output with control sequences. Execute the
`reword` code from `do_next` instead if the option `--edit` is
specified.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 43 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
@@ -461,7 +461,42 @@ record_in_rewritten() {esac}+# Apply the changes introduced by the given commit to the current head.+#+# do_pick [--edit] <commit> <title>+#+# Wrapper around git-cherry-pick.+#+# -e, --edit+# After picking <commit>, open an editor and let the user edit the+# commit message. The editor contents becomes the commit message of+# the new head. This creates a fresh commit.+#+# <commit>+# The commit to cherry-pick.+#+# <title>+# The commit message title of <commit>. Used for information+# purposes only. do_pick(){+edit=+whiletest$#-gt0+do+case"$1"in+-e|--edit)+edit=y+;;+-*)+die"do_pick: unrecognized option -- $1"+;;+*)+break+;;+esac+shift+done+test$#-ne2&&die"do_pick: wrong number of arguments"+iftest"$(gitrev-parseHEAD)"="$squash_onto"then# Set the correct commit message and author info on the
@@ -483,6 +518,14 @@ do_pick () {pick_one$1||die_with_patch$1"Could not apply $1... $2"fi++iftest-n"$edit"+then+outputgitcommit--allow-empty--amend--no-post-rewrite--no-pre-commit${gpg_sign_opt:+"$gpg_sign_opt"}||{+warn"Could not amend commit after successfully picking $1... $2"+exit_with_patch$11+}+fi} do_next(){
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:09
Using the to-do list command `squash` the user can specify two or
more commits and git-rebase creates one commit that introduces all
their changes combined. The authorship for the created commit is
taken from the first commit specified and the user can edit the log
message. There is a variant of `squash` available named `fixup` which
also takes the first log message without asking for user input.
While it is reasonable to not verify replayed changes twice or
rejecting some other author's changes in her name, it is insufficient
to not verify the user input used as log message in the case of
`squash`. Specify the git-commit option `--commit-msg` when
committing the squash result to execute the commit-msg hook and
verify the new log message. For the same reasons the pre-commit hook
is disabled in all replay modes, the commit-msg hook gets disabled in
`fixup` mode.
Add tests. In addition to the existing test checking that the
pre-commit hook is disabled when simply picking a commit, provide a
test checking that the commit-msg hook is disabled as well.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 2 +-
t/t3404-rebase-interactive.sh | 78 +++++++++++++++++++++++++++++++++++++++++++
2 files changed, 79 insertions(+), 1 deletion(-)
@@ -655,6 +655,84 @@ test_expect_success 'rebase a commit violating pre-commit' ''+test_expect_success'setup failing pre-commit''+HOOKDIR="$(gitrev-parse--git-dir)"/hooks&&+mkdir-p"$HOOKDIR"&&+PRE_COMMIT="$HOOKDIR"/pre-commit&&+cat>"$PRE_COMMIT"<<-EOF&&+#!/bin/sh+echorunningfailingpre-commit...+exit1+EOF+chmod+x"$PRE_COMMIT"&&+gitcheckout-bviolating-pre-commitmaster&&+test_must_failtest_commitpre-commit-violated-1&&+test_commit--no-verifypre-commit-violated-1&&+test_must_failtest_commitpre-commit-violated-2&&+test_commit--no-verifypre-commit-violated-2+'++test_expect_success'squash a commit violating pre-commit''+gitcheckout-bsquash-violating-pre-commitviolating-pre-commit&&+test_when_finishedreset_rebase&&+set_fake_editor&&+envFAKE_LINES="1 squash 2"gitrebase-imaster+'++test_expect_success'fixup a commit violating pre-commit''+gitcheckout-bfixup-violating-pre-commitviolating-pre-commit&&+test_when_finishedreset_rebase&&+set_fake_editor&&+envFAKE_LINES="1 fixup 2"gitrebase-imaster+'++test_expect_success'clean up failing pre-commit''+rm"$PRE_COMMIT"+'++test_expect_success'setup failing commit-msg''+HOOKDIR="$(gitrev-parse--git-dir)"/hooks&&+mkdir-p"$HOOKDIR"&&+COMMIT_MSG="$HOOKDIR"/commit-msg&&+cat>"$COMMIT_MSG"<<-EOF&&+#!/bin/sh+echorunningfailingcommit-msg...+exit1+EOF+chmod+x"$COMMIT_MSG"&&+gitcheckout-bviolating-commit-msgmaster&&+test_must_failtest_commitcommit-msg-violated-1&&+test_commit--no-verifycommit-msg-violated-1&&+test_must_failtest_commitcommit-msg-violated-2&&+test_commit--no-verifycommit-msg-violated-2&&+test_must_failtest_commitcommit-msg-violated-3&&+test_commit--no-verifycommit-msg-violated-3+'++test_expect_success'rebase a commit violating commit-msg''+gitcheckout-brebase-violating-commit-msgviolating-commit-msg&&+set_fake_editor&&+FAKE_LINES="1"gitrebase-imaster+'++test_expect_success'squash a commit violating commit-msg''+gitcheckout-bsquash-violating-commit-msgviolating-commit-msg&&+set_fake_editor&&+test_must_failenvFAKE_LINES="1 squash 2 fixup 3"gitrebase-imaster&&+gitcommit--no-verify--amend&&+gitrebase--continue+'++test_expect_success'fixup a commit violating commit-msg''+gitcheckout-bfixup-violating-commit-msgviolating-commit-msg&&+set_fake_editor&&+envFAKE_LINES="1 fixup 2"gitrebase-imaster+'++test_expect_success'clean up failing commit-msg''+rm"$COMMIT_MSG"+'+ test_expect_success'rebase with a file named HEAD in worktree''rm-fr.git/hooks&&
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:09
The command line used to recreate root commits specifies the option
`-q` which suppresses the commit summary message. However,
git-rebase--interactive tends to tell the user about the commits it
creates in the final history, if she wishes (cf. command line option
`--verbose`). The code parts handling non-root commits and squash
commits all output commit summary messages. Do not make the replay of
root commits an exception. Remove the option to make the report of
the rebased history complete. Do not forget to wrap the git-commit
command line in `output` so that the summary is shown if git-rebase
is called with the `--verbose` option but suppressed otherwise.
It is OK that the commit summary is still suppressed when git-commit
is used to initialize the authorship of the sentinel commit because
this additional commit is an implementation detail hidden from the
final history. The removed `-q` option was probably introduced as a
copy-and-paste error stemming from that part of the root commit
handling code.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:09
The options passed to `do_pick` determine whether the picked commit
will be rewritten or not. If the commit gets rewritten, because the
user requested to edit the commit message for instance, let
`pick_one` merely apply the changes introduced by the commit and do
not commit the resulting tree yet. If the commit is replayed as is,
leave it to `pick_one` to recreate the commit (possibly by
fast-forwarding the head). This makes it easier to combine git-commit
options like `--edit` and `--amend` in `do_pick` because
git-cherry-pick does not support `--amend`.
In the case of `--edit`, do not `exit_with_patch` but assign
`rewrite` to pick the changes with `-n`. If the pick conflicts, no
commit is created which we would have to amend when continuing the
rebase. To complete the pick after the conflicts are resolved the
user just resumes with `git rebase --continue`.
git-commit lets the user edit the commit log message by default. We
do not want that for the rewriting git-commit command line because
the default behaviour of git-rebase is exactly the opposite. Pass
`--no-edit` when rewriting a picked commit. An explicit `--edit`
passed to `do_pick` (for instance, when reword is executed) enables
the editor launch again. Similarly, pass `--allow-empty-message`
unless the log message is edited.
If `rebase--interactive` is used to rebase a complete branch onto
some head, `rebase` creates a sentinel commit that requires special
treatment by `do_pick`. Do not finalize the pick here either because
its commit message can be altered as for any other pick. Since the
orphaned root commit gets a temporary parent, it is always rewritten.
Safely use the rewrite infrastructure of `do_pick` to create the
final commit.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 35 ++++++++++++++++++++++-------------
1 file changed, 22 insertions(+), 13 deletions(-)
@@ -63,7 +63,8 @@ msgnum="$state_dir"/msgnumauthor_script="$state_dir"/author-script# When an "edit" rebase command is being processed, the SHA1 of the-# commit to be edited is recorded in this file. When "git rebase+# commit to be edited is recorded in this file. The same happens when+# rewriting a commit fails, for instance "reword". When "git rebase# --continue" is executed, if there are any staged changes then they# will be amended to the HEAD commit, but only provided the HEAD# commit is still the commit to be edited. When any other rebase
@@ -479,12 +480,17 @@ record_in_rewritten() {# The commit message title of <commit>. Used for information# purposes only. do_pick(){-edit=+allow_empty_message=y+rewrite=+rewrite_amend=+rewrite_edit=whiletest$#-gt0docase"$1"in-e|--edit)-edit=y+rewrite=y+rewrite_edit=y+allow_empty_message=;;-*)die"do_pick: unrecognized option -- $1"
@@ -499,6 +505,10 @@ do_pick () {iftest"$(gitrev-parseHEAD)"="$squash_onto"then+rewrite=y+rewrite_amend=y+gitrev-parse--verifyHEAD>"$amend"+# Set the correct commit message and author info on the# sentinel root before cherry-picking the original changes# without committing (-n). Finally, update the sentinel again
@@ -509,22 +519,21 @@ do_pick () {# rebase --continue.gitcommit--allow-empty--allow-empty-message--amend\--no-post-rewrite-n-q-C$1&&-pick_one-n$1&&-outputgitcommit--allow-empty--allow-empty-message\---amend--no-post-rewrite-n--no-edit\-${gpg_sign_opt:+"$gpg_sign_opt"}||+pick_one-n$1||die_with_patch$1"Could not apply $1... $2"else-pick_one$1||+pick_one${rewrite:+-n}$1||die_with_patch$1"Could not apply $1... $2"fi-iftest-n"$edit"+iftest-n"$rewrite"then-outputgitcommit--allow-empty--amend--no-post-rewrite--no-pre-commit${gpg_sign_opt:+"$gpg_sign_opt"}||{-warn"Could not amend commit after successfully picking $1... $2"-exit_with_patch$11-}+outputgitcommit--allow-empty--no-post-rewrite-n--no-edit\+${allow_empty_message:+--allow-empty-message}\+${rewrite_amend:+--amend}\+${rewrite_edit:+--edit --commit-msg}\+${gpg_sign_opt:+"$gpg_sign_opt"}||+die_with_patch$1"Could not rewrite commit after successfully picking $1... $2"fi}
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:09
The to-do list command `squash` and its close relative `fixup` replay
the changes of a commit like `pick` but do not recreate the commit.
Instead they replace the previous commit with a new commit that also
introduces the changes of the squashed commit. This is roughly like
cherry-picking without committing and using git-commit to amend the
previous commit.
The to-do list
pick a Some changes
squash b Some more changes
gets translated into the sequence of git commands
git cherry-pick a
git cherry-pick -n b
git commit --amend
and if git-cherry-pick supported `--amend` this would look even more
like the to-do list it is based on
git cherry-pick a
git cherry-pick --amend b.
Since `do_pick` takes care of `pick` entries and the above suggests
`squash` as an alias for `pick --amend`, reimplement `squash` in
terms of `do_pick --amend`. Introduce `$squash_msg` as the commit
message via the `--file` option. When the last commit of a squash
series is processed, the user is asked to review the log message.
Pass `--edit` as additional option in this case. The only difference
in the options passed to git-commit and `do_pick` is the omitted
`--no-verify`. However, `do_pick` does not execute the verification
hooks anyway because it solely replays commits and assumes that they
have been verified before.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 32 ++++++--------------------------
1 file changed, 6 insertions(+), 26 deletions(-)
@@ -627,39 +627,19 @@ do_next () {squash|s|fixup|f)# This is an intermediate commit; its message will only be# used in case of trouble. So use the long version:-if!pick_one-n$sha1-then-gitrev-parse--verifyHEAD>"$amend"-die_failed_squash$sha1"Could not apply $sha1... $rest"-fi-do_with_authoroutputgitcommit--allow-empty-message--allow-empty\---amend--no-verify-F"$squash_msg"\-${gpg_sign_opt:+"$gpg_sign_opt"}||-die_failed_squash$sha1"$rest"+do_with_authordo_pick--amend-F"$squash_msg"$sha1\+||die_failed_squash$sha1"$rest";;*)# This is the final command of this squash/fixup groupiftest-f"$fixup_msg"then-if!pick_one-n$sha1-then-gitrev-parse--verifyHEAD>"$amend"-die_failed_squash$sha1"Could not apply $sha1... $rest"-fi-do_with_authoroutputgitcommit--allow-empty-message--allow-empty\---amend--no-verify-F"$fixup_msg"\-${gpg_sign_opt:+"$gpg_sign_opt"}||-die_failed_squash$sha1"$rest"+do_with_authordo_pick--amend-F"$fixup_msg"$sha1\+||die_failed_squash$sha1"$rest"elsecp"$squash_msg""$GIT_DIR"/SQUASH_MSG||exit-if!pick_one-n$sha1-then-gitrev-parse--verifyHEAD>"$amend"-die_failed_squash$sha1"Could not apply $sha1... $rest"-fi-do_with_authoroutputgitcommit--allow-empty--amend--no-pre-commit-F"$GIT_DIR"/SQUASH_MSG-e\-${gpg_sign_opt:+"$gpg_sign_opt"}||-die_failed_squash$sha1"$rest"+do_with_authordo_pick--amend-F"$GIT_DIR"/SQUASH_MSG-e$sha1\+||die_failed_squash$sha1"$rest"firm-f"$squash_msg""$fixup_msg"iftest-z"$keep_empty"&&is_empty_commitHEAD
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:09
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement the to-do list commands `pick`, `reword`
and `edit`. To cater for the different pick behaviours (like
`squash`), `do_pick` accepts several options not only from the
git-cherry-pick but also the git-commit interface.
Add the option `--amend` from the git-commit interface to the options
pool of `do_pick`. It creates a new commit for the changes introduced
by the picked commit and the previous one. The previous commit is
then replaced with the new commit. If no other options are specified,
the log message of the previous commit is used.
Be careful when `--amend` is used to pick a root commit because HEAD
might point to the sentinel commit but there is still nothing to
amend. Be sure to initialize `amend` so that commits are squashed
even when git-rebase--interactive is interrupted for resolving
conflicts. It is not a mistake to do the initialization regardless of
any conflicts because `amend` is always cleared before the next to-do
item is processed.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
@@ -464,10 +464,16 @@ record_in_rewritten() {# Apply the changes introduced by the given commit to the current head.#-# do_pick [--edit] <commit>+# do_pick [--amend] [--edit] <commit>## Wrapper around git-cherry-pick.#+# --amend+# After picking <commit>, replace the current head commit with a new+# commit that also introduces the changes of <commit>.+#+# _This is not a git-cherry-pick option._+## -e, --edit# After picking <commit>, open an editor and let the user edit the# commit message. The editor contents becomes the commit message of
@@ -489,6 +495,16 @@ do_pick () {whiletest$#-gt0docase"$1"in+--amend)+iftest"$(gitrev-parseHEAD)"="$squash_onto"||!gitrev-parse-q--verifyHEAD>/dev/null+then+warn"do_pick: nothing to amend"+return2+fi+rewrite=y+rewrite_amend=y+gitrev-parse--verifyHEAD>"$amend"+;;-e|--edit)rewrite=yrewrite_edit=y
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:09
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement the to-do list command `pick`, `reword` and
`edit`. To cater for the different pick behaviours (like `squash`),
`do_pick` accepts several options not only from the git-cherry-pick
but also the git-commit interface.
Add the option `--file` from the git-commit interface to the options
pool of `do_pick`. It expects an argument itself which is interpreted
as a file path and takes the commit message from the given file. If
`--file` is passed to `do_pick`, assign the given file path to the
local variable `rewrite_message` and relay the option
--file "$rewrite_message"
to the git-commit command line which creates the commit.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
@@ -464,7 +464,7 @@ record_in_rewritten() {# Apply the changes introduced by the given commit to the current head.#-# do_pick [--amend] [--edit] <commit>+# do_pick [--amend] [--file <file>] [--edit] <commit>## Wrapper around git-cherry-pick.#
@@ -474,6 +474,12 @@ record_in_rewritten() {## _This is not a git-cherry-pick option._#+# -F <file>, --file <file>+# Take the commit message from the given file. This creates a fresh+# commit.+#+# _This is not a git-cherry-pick option._+## -e, --edit# After picking <commit>, open an editor and let the user edit the# commit message. The editor contents becomes the commit message of
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:09
There are two kinds of to-do list commands available. One kind
replays a commit (`pick`, `reword`, `edit`, `squash` and `fixup` that
is) and the other executes a shell command (`exec`). We will call the
first kind replay commands.
The two kinds of tasks are scheduled using different line formats.
Replay commands expect a commit hash argument following the command
name and exec concatenates all arguments to assemble a command line.
Adhere to the distinction of formats by not trying to parse the
`sha1` field unless we are dealing with a replay command. Move the
replay command handling code to a new function `do_replay` which
assumes the first argument to be a commit hash and make no more such
assumptions in `do_next`.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 42 ++++++++++++++++++++++++++++--------------
1 file changed, 28 insertions(+), 14 deletions(-)
@@ -660,6 +659,28 @@ do_next () {esacrecord_in_rewritten$sha1;;+*)+read-rcommand<"$todo"+warn"Unknown command: $command"+fixtodo="Please fix this using 'git rebase --edit-todo'."+ifgitrev-parse--verify-q"$sha1">/dev/null+then+die_with_patch$sha1"$fixtodo"+else+die"$fixtodo"+fi+;;+esac+}++do_next(){+rm-f"$msg""$author_script""$amend"||exit+read-rcommandsha1rest<"$todo"++case"$command"in+"$comment_char"*|''|noop)+mark_action_done+;;x|"exec")read-rcommandrest<"$todo"mark_action_done
@@ -699,14 +720,7 @@ do_next () {fi;;*)-warn"Unknown command: $command$sha1$rest"-fixtodo="Please fix this using 'git rebase --edit-todo'."-ifgitrev-parse--verify-q"$sha1">/dev/null-then-die_with_patch$sha1"$fixtodo"-else-die"$fixtodo"-fi+do_replay$command$sha1"$rest";;esactest-s"$todo"&&return
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:09
Rewrite `squash` and `fixup` handling in `do_next` using the sequence
pick_one
commit
in order to test the correctness of a single `do_squash` or
parameterised `do_pick` and make the subsequent patch reimplementing
`squash` in terms of such a single function more readable.
Do not call `rm -f "$GIT_DIR"/MERGE_MSG` since it has no effect on
the state after git-rebase--interactive terminates. The option `-F`
makes git-commit ignore `MERGE_MSG` for the log message. If
git-commit succeeds, `MERGE_MSG` is removed, and if it fails,
`MERGE_MSG` is overwritten by the error sequence `die_failed_squash`.
In summary, removing `MERGE_MSG` neither influences the squash commit
message nor the file state after git-commit returns.
Moreover, `pick_one` ignores `$GIT_DIR/SQUASH_MSG` and does not touch
`$squash_msg` so that it is correct to execute `pick_one` immediately
before git-commit.
Might be squashed into the subsequent commit.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 21 +++++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
@@ -623,15 +623,15 @@ do_next () {author_script_content=$(get_author_ident_from_commitHEAD)echo"$author_script_content">"$author_script"eval"$author_script_content"-if!pick_one-n$sha1-then-gitrev-parse--verifyHEAD>"$amend"-die_failed_squash$sha1"$rest"-ficase"$(peek_next_command)"insquash|s|fixup|f)# This is an intermediate commit; its message will only be# used in case of trouble. So use the long version:+if!pick_one-n$sha1+then+gitrev-parse--verifyHEAD>"$amend"+die_failed_squash$sha1"Could not apply $sha1... $rest"+fido_with_authoroutputgitcommit--allow-empty-message--allow-empty\--amend--no-verify-F"$squash_msg"\${gpg_sign_opt:+"$gpg_sign_opt"}||
@@ -641,13 +641,22 @@ do_next () {# This is the final command of this squash/fixup groupiftest-f"$fixup_msg"then+if!pick_one-n$sha1+then+gitrev-parse--verifyHEAD>"$amend"+die_failed_squash$sha1"Could not apply $sha1... $rest"+fido_with_authoroutputgitcommit--allow-empty-message--allow-empty\--amend--no-verify-F"$fixup_msg"\${gpg_sign_opt:+"$gpg_sign_opt"}||die_failed_squash$sha1"$rest"elsecp"$squash_msg""$GIT_DIR"/SQUASH_MSG||exit-rm-f"$GIT_DIR"/MERGE_MSG+if!pick_one-n$sha1+then+gitrev-parse--verifyHEAD>"$amend"+die_failed_squash$sha1"Could not apply $sha1... $rest"+fido_with_authoroutputgitcommit--allow-empty--amend--no-pre-commit-F"$GIT_DIR"/SQUASH_MSG-e\${gpg_sign_opt:+"$gpg_sign_opt"}||die_failed_squash$sha1"$rest"
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:09
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is currently used to implement most of the to-do list commands
and offers additional options that will eventually find their way
onto to-do lists.
To extend the repertoire of available options, add the git-commit and
git-cherry-pick option `--signoff` to the `do_pick` interface. It
appends a Signed-off-by: line using the committer identity to the log
message of the picked commit.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
@@ -464,10 +464,15 @@ record_in_rewritten() {# Apply the changes introduced by the given commit to the current head.#-# do_pick [--reset-author] [--amend] [--file <file>] [--edit] <commit>+# do_pick [--signoff] [--reset-author] [--amend] [--file <file>]+# [--edit] <commit>## Wrapper around git-cherry-pick.#+# -s, --signoff+# Insert a Signed-off-by: line using the committer identity at the+# end of the commit log message. This creates a fresh commit.+## --reset-author# Pretend the changes were made for the first time. Declare that the# authorship of the resulting commit now belongs to the committer.
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:09
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement many of the to-do list commands.
Eventually, the complete `do_pick` interface will be exposed to the
user in some form or another and those commands will become simple
aliases for the `do_pick` options now used to implement them.
Add the git-commit option `--reset-author` to the options pool of
`do_pick`. It rewrites the author date and name of the picked commit
to match the committer date and name.
If `--reset-author` is passed to `do_pick`, set the `rewrite` flag
and relay the option to the git-commit command line which creates the
final commit. If `--amend` is not passed as well, the fresh
authorship effect is achieved by the mere fact that we are creating a
new commit.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
@@ -464,10 +464,18 @@ record_in_rewritten() {# Apply the changes introduced by the given commit to the current head.#-# do_pick [--amend] [--file <file>] [--edit] <commit>+# do_pick [--reset-author] [--amend] [--file <file>] [--edit] <commit>## Wrapper around git-cherry-pick.#+# --reset-author+# Pretend the changes were made for the first time. Declare that the+# authorship of the resulting commit now belongs to the committer.+# This also renews the author timestamp. This creates a fresh+# commit.+#+# _This is not a git-cherry-pick option._+## --amend# After picking <commit>, replace the current head commit with a new# commit that also introduces the changes of <commit>.
@@ -564,6 +576,14 @@ do_pick () {pick_one${rewrite:+-n}$1||return1fi+iftest-n"$rewrite_author"&&test-z"$rewrite_amend"+then+# keep rewrite flag to create a new commit, rewrite+# without --reset-author though because it can only be+# used with -C, -c or --amend+rewrite_author=+fi+iftest-n"$rewrite"thenoutputgitcommit--allow-empty--no-post-rewrite-n--no-edit\
From: Fabian Ruch <hidden> Date: 2016-06-15 23:02:09
Read in to-do list lines as
command args
instead of
command sha1 rest
so that to-do list command lines can specify additional arguments
apart from the commit hash and the log message title, which become
the non-options in `args`. Loop over `args`, put all options (an
argument beginning with a dash) in `opts`, stop the loop on the first
non-option and assign it to `sha1`. The loop does not know the
options it parses so that options that take an argument themselves
are not supported at the moment. Neither are options that contain
spaces because the shell expansion of `args` in `do_next` interprets
white space characters as argument separator, that is a command line
like
pick --author "A U Thor" fa1afe1 Some change
is parsed as the pick command
pick --author
and the commit hash
"A
which obviously results in an unknown revision error. For the sake of
completeness, in the example above the message title variable `rest`
is assigned the string 'U Thor" fa1afe1 Some change' (without the
single quotes).
Print an error message for unknown or unsupported command line
options, which means an error for all specified options at the
moment. Cleanly break the `do_next` loop by assigning the special
value 'unknown' to the local variable `command`, which triggers the
unknown command case in `do_cmd`.
The to-do list is also parsed when the commit hashes are translated
between long and short format before and after the to-do list is
edited. Apply the same procedure as in `do_cmd` with the exception
that we only care about where the options stop and the commit hash
begins. Do not reject any options when transforming the commit
hashes.
Signed-off-by: Fabian Ruch <redacted>
---
git-rebase--interactive.sh | 49 ++++++++++++++++++++++++++++++++++++++--------
1 file changed, 41 insertions(+), 8 deletions(-)
@@ -800,19 +818,34 @@ skip_unnecessary_picks () {} transform_todo_ids(){-whileread-rcommandrest+whileread-rcommandargsdocase"$command"in"$comment_char"*|exec)# Be careful for oddball commands like 'exec'# that do not have a SHA-1 at the beginning of $rest.+newargs=\ $args;;*)-sha1=$(gitrev-parse--verify--quiet"$@"${rest%% *})&&-rest="$sha1${rest#* }"+newargs=+sha1=+forargin$args+do+case"$arg"in+-*)+newargs="$newargs$arg"+;;+*)+test-z"$sha1"&&+sha1=$(gitrev-parse--verify--quiet"$@"$arg)&&+arg=$sha1+newargs="$newargs$arg"+;;+esac+done;;esac-printf'%s\n'"$command${rest:+ }$rest"+printf'%s\n'"$command$newargs"done<"$todo">"$todo.new"&&mv-f"$todo.new""$todo"}