git/git-rebase.sh, branch v2.9.2

Merge branch 'jc/commit-tree-ignore-commit-gpgsign'

2016-05-13T20:18:27Z

"git commit-tree" plumbing command required the user to always sign its result when the user sets the commit.gpgsign configuration variable, which was an ancient mistake. Rework "git rebase" that relied on this mistake so that it reads commit.gpgsign and pass (or not pass) the -S option to "git commit-tree" to keep the end-user expectation the same, while teaching "git commit-tree" to ignore the configuration variable. This will stop requiring the users to sign commit objects used internally as an implementation detail of "git stash". * jc/commit-tree-ignore-commit-gpgsign: commit-tree: do not pay attention to commit.gpgsign

commit-tree: do not pay attention to commit.gpgsign

2016-05-03T17:59:25Z

ba3c69a9 (commit: teach --gpg-sign option, 2011-10-05) introduced a "signed commit" by teaching the --[no]-gpg-sign option and the commit.gpgsign configuration variable to various commands that create commits. Teaching these to "git commit" and "git merge", both of which are end-user facing Porcelain commands, was perfectly fine. Allowing the plumbing "git commit-tree" to suddenly change the behaviour to surprise the scripts by paying attention to commit.gpgsign was not. Among the in-tree scripts, filter-branch, quiltimport, rebase and stash are the commands that run "commit-tree". If any of these wants to allow users to always sign every single commit, they should offer their own configuration (e.g. "filterBranch.gpgsign") with an option to disable signing (e.g. "git filter-branch --no-gpgsign"). Ignoring commit.gpgsign option _obviously_ breaks the backward compatibility, but it is easy to follow the standard pattern in scripts to honor whatever configuration variable they choose to follow. E.g. case $(git config --bool commit.gpgsign) in true) sign=-S ;; *) sign= ;; esac && git commit-tree $sign ...whatever other args... Do so to make sure that "git rebase" keeps paying attention to the configuration variable, which unfortunately is a documented mistake. Helped-by: Jeff King Signed-off-by: Junio C Hamano

rebase: decouple --exec from --interactive

2016-03-18T21:35:31Z

In the later steps of preparing a patch series I do not want to edit or reorder the patches any more, but just make sure the test suite passes after each patch and also to fix breakage right there if some of the steps fail. I could run EDITOR=true git rebase -i -x "make test" but it would be simpler if it can be spelled like so: git rebase -x "make test" Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano

Merge branch 'jk/ok-to-fail-gc-auto-in-rebase'

2016-01-26T23:40:29Z

"git rebase", unlike all other callers of "gc --auto", did not ignore the exit code from "gc --auto". * jk/ok-to-fail-gc-auto-in-rebase: rebase: ignore failures from "gc --auto"

rebase: ignore failures from "gc --auto"

2016-01-13T20:04:53Z

After rebasing, we call "gc --auto" to clean up if we created a lot of loose objects. However, we do so inside an &&-chain. If "gc --auto" fails (e.g., because a previous background gc blocked us by leaving "gc.log" in place), then: 1. We will fail to clean up the state directory, leaving the user stuck in the rebase forever (even "git am --abort" doesn't work, because it calls "gc --auto"!). 2. In some cases, we may return a bogus exit code from rebase, indicating failure when everything except the auto-gc succeeded. We can fix this by ignoring the exit code of "gc --auto". Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'jk/rebase-no-autostash'

2015-10-05T19:30:22Z

There was no way to defeat a configured rebase.autostash variable from the command line, as "git rebase --no-autostash" was missing. * jk/rebase-no-autostash: Documentation/git-rebase: fix --no-autostash formatting rebase: support --no-autostash

rebase: support --no-autostash

2015-09-11T00:42:01Z

This is documented as an option but we don't actually accept it. Support it so that it is possible to override the "rebase.autostash" config variable. Reported-by: Daniel Hahler Signed-off-by: John Keeping Signed-off-by: Junio C Hamano

Merge branch 'jk/rebase-quiet-noop' into maint

2015-05-26T20:49:23Z

"git rebase --quiet" was not quite quiet when there is nothing to do. * jk/rebase-quiet-noop: rebase: silence "git checkout" for noop rebase

Merge branch 'jk/rebase-quiet-noop'

2015-05-11T21:23:49Z

"git rebase --quiet" was not quite quiet when there is nothing to do. * jk/rebase-quiet-noop: rebase: silence "git checkout" for noop rebase

rebase: silence "git checkout" for noop rebase

2015-04-28T18:38:40Z

When the branch to be rebased is already up to date, we "git checkout" the branch, print an "up to date" message, and end the rebase early. However, our checkout may print "Switched to branch 'foo'" or "Already on 'foo'", even if the user has asked for "--quiet". We should avoid printing these messages at all, "--quiet" or no. Since the rebase is a noop, this checkout can be seen as optimizing out these other two checkout operations (that happen in a real rebase): 1. Moving to the detached HEAD to start the rebase; we always feed "-q" to checkout there, and instead rely on our own custom message (which respects --quiet). 2. Finishing a rebase, where we move to the final branch. Here we actually use update-ref rather than git-checkout, and produce no messages. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano