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

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

2016-02-05T22:54:13Z

"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'

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

*.sh: avoid hardcoding $GIT_DIR/hooks/...

2014-12-01T19:00:13Z

If $GIT_COMMON_DIR is set, it should be $GIT_COMMON_DIR/hooks/, not $GIT_DIR/hooks/. Just let rev-parse --git-path handle it. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

rebase: omit patch-identical commits with --fork-point

2014-07-16T20:07:40Z

When the `--fork-point` argument was added to `git rebase`, we changed the value of $upstream to be the fork point instead of the point from which we want to rebase. When $orig_head..$upstream is empty this does not change the behaviour, but when there are new changes in the upstream we are no longer checking if any of them are patch-identical with changes in $upstream..$orig_head. Fix this by introducing a new variable to hold the fork point and using this to restrict the range as an extra (negative) revision argument so that the set of desired revisions becomes (in fork-point mode): git rev-list --cherry-pick --right-only \ $upstream...$orig_head ^$fork_point This allows us to correctly handle the scenario where we have the following topology: C --- D --- E <- dev / B <- master@{1} / o --- B' --- C* --- D* <- master where: - B' is a fixed-up version of B that is not patch-identical with B; - C* and D* are patch-identical to C and D respectively and conflict textually if applied in the wrong order; - E depends textually on D. The correct result of `git rebase master dev` is that B is identified as the fork-point of dev and master, so that C, D, E are the commits that need to be replayed onto master; but C and D are patch-identical with C* and D* and so can be dropped, so that the end result is: o --- B' --- C* --- D* --- E <- dev If the fork-point is not identified, then picking B onto a branch containing B' results in a conflict and if the patch-identical commits are not correctly identified then picking C onto a branch containing D (or equivalently D*) results in a conflict. This change allows us to handle both of these cases, where previously we either identified the fork-point (with `--fork-point`) but not the patch-identical commits *or* (with `--no-fork-point`) identified the patch-identical commits but not the fact that master had been rewritten. Reported-by: Ted Felix Signed-off-by: John Keeping Signed-off-by: Junio C Hamano

Merge branch 'rr/rebase-autostash-fix' into maint

2014-06-25T18:49:31Z

The autostash mode of "git rebase -i" did not restore the dirty working tree state if the user aborted the interactive rebase by emptying the insn sheet. * rr/rebase-autostash-fix: rebase -i: test "Nothing to do" case with autostash rebase -i: handle "Nothing to do" case with autostash

Merge branch 'rr/rebase-autostash-fix'

2014-06-16T17:06:57Z

* rr/rebase-autostash-fix: rebase -i: test "Nothing to do" case with autostash rebase -i: handle "Nothing to do" case with autostash