Skip to content
Commits on Sep 11, 2015
  1. @johnkeeping @gitster

    rebase: support --no-autostash

    johnkeeping committed with gitster
    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 <>
Commits on Jul 16, 2014
  1. @johnkeeping @gitster

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

    johnkeeping committed with gitster
    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
    - 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 <>
Commits on Jan 9, 2014
  1. @johnkeeping @gitster

    rebase: fix fork-point with zero arguments

    johnkeeping committed with gitster
    When no arguments are specified, $switch_to is empty so we end up
    passing the empty string to "git merge-base --fork-point", which causes
    an error.  git-rebase carries on at this point, but in fact we have
    failed to apply the fork-point operation.
    It turns out that the test in t3400 that was meant to test this didn't
    actually need the fork-point behaviour, so enhance it to make sure that
    the fork-point is applied correctly.  The modified test fails without
    the change to in this patch.
    Reported-by: Andreas Krey <>
    Signed-off-by: John Keeping <>
    Signed-off-by: Junio C Hamano <>
Commits on Dec 10, 2013
  1. @johnkeeping @gitster

    rebase: use reflog to find common base with upstream

    johnkeeping committed with gitster
    Commit 15a147e (rebase: use @{upstream} if no upstream specified,
    2011-02-09) says:
    	Make it default to 'git rebase @{upstream}'. That is also what
    	'git pull [--rebase]' defaults to, so it only makes sense that
    	'git rebase' defaults to the same thing.
    but that isn't actually the case.  Since commit d44e712 (pull: support
    rebased upstream + fetch + pull --rebase, 2009-07-19), pull has actually
    chosen the most recent reflog entry which is an ancestor of the current
    branch if it can find one.
    Add a '--fork-point' argument to git-rebase that can be used to trigger
    this behaviour.  This option is turned on by default if no non-option
    arguments are specified on the command line, otherwise we treat an
    upstream specified on the command-line literally.
    Signed-off-by: John Keeping <>
    Signed-off-by: Junio C Hamano <>
Something went wrong with that request. Please try again.