Now that we control the merge base selection, we won't be forced
into rolling things in that we wanted to skip beforehand.

Also, add a test to ensure this all works as intended.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We no longer have to recommit each patch to remove the parent
information we're rebasing since we're using the low-level merge
strategies directly instead of git-merge.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Enhance t3401-rebase-partial to test with --merge as well as
the standard am -3 strategy.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Instead of using 4-digit numbers to name commits being rebased,
just use "cmt.$msgnum" string, with $msgnum as a decimal number
without leading zero padding.  This makes it possible to rebase
more than 9999 commits, but of more practical importance is that
the earlier code used "printf" to format already formatted
$msgnum and barfed when it counted up to 0008.  In other words,
the old code was incapable of rebasing more than 7 commits, and
this fixes that problem.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

recursive merge relies on Python, and we can't perform
rename-aware merges without the recursive merge.  So bail out
before trying it.

The test won't work w/o recursive merge, either, so skip that,
too.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This solves the problem of rebasing local commits against an
upstream that has renamed files.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NSean Estabrooks <seanlkml@sympatico.ca>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

  git rebase [--onto <newbase>] <upstream> [<branch>]
  git rebase --continue
  git rebase --abort

Add "--continue" to restart the rebase process after
manually resolving conflicts.  The user is warned if
there are still differences between the index and the
working files.

Add "--abort" to restore the original branch, and
remove the .dotest working files.

Some minor additions to the git-rebase documentation.

[jc: fix that applies to the maintenance track has been dealt
 with separately.]
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Noticed by Sean.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Some words, e.g., `match', are special to expr(1), and cause strange
parsing effects.  Track down all uses of expr and mangle the arguments
so that this isn't a problem.
Signed-off-by: NMark Wooding <mdw@distorted.org.uk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

s/upsteram/upstream in git-rebase.sh.
Signed-off-by: NJason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

I found a paper thin man page for git-rebase, but was quite happy to
see something much more useful in the usage statement of the script
when I went there to find out how this thing worked. Here it is
cleaned up slightly and expanded a bit into the actual documentation.
Signed-off-by: NCarl Worth <cworth@cworth.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This allows you to rewrite history a bit more flexibly, by
separating the other branch name and new branch point.  By
default, the new branch point is the same as the tip of the
other branch as before, but you can specify where you graft the
rebased branch onto.

When you have this ancestry graph:

          A---B---C topic
         /
    D---E---F---G master

	$ git rebase --onto master~1 master topic

would rewrite the history to look like this:

	      A'\''--B'\''--C'\'' topic
	     /
    D---E---F---G master
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This lets a hook to interfere a rebase and help prevent certain
branches from being rebased by mistake.  A sample hook to show
how to prevent a topic branch that has already been merged into
publish branch.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Fix bugs in git-rebase wrt rebasing another branch than
the current HEAD, rebasing with a dirty working dir,
and rebasing a proper decendant of the target branch.

[jc: with a bit of hand-merging]
Signed-off-by: NLukas Sandström <lukass@etek.chalmers.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When switching to another branch and rebasing it in a one-go, it
failed to update the variable that holds the branch head, and
did not detect fast-forward situation correctly.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NFredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When a .dotest from a previously failed rebase or patch
application exists, rebase got confused and tried to apply
mixture of what was already there and what is being rebased.
Check the existence of the directory and barf.

It failed with an mysterious "fatal: cannot read mbox" message
if the branch being rebased is fully in sync with the base.
Also if the branch is a proper descendant of the base, there is
no need to run rebase logic.  Prevent these from happening by
checking where the merge-base is.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Now all the users of this script detect its exit status and die,
complaining that it is outside git repository.  So move the code
that dies from all callers to git-sh-setup script.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The current rebase implementation finds commits in our tree but
not in the upstream tree using git-cherry, and tries to apply
them using git-cherry-pick (i.e. always use 3-way) one by one.

Which is fine, but when some of the changes do not apply
cleanly, it punts, and punts badly.

Suppose you have commits A-B-C-D-E since you forked from the
upstream and submitted the changes for inclusion.  You fetch
from upstream head U and find that B has been picked up.  You
run git-rebase to update your branch, which tries to apply
changes contained in A-C-D-E, in this order, but replaying of C
fails, because the upstream got changes that touch the same area
from elsewhere.

Now what?

It notes that fact, and goes ahead to apply D and E, and at the
very end tells you to deal with C by hand.  Even if you somehow
managed to replay C on top of the result, you would now end up
with ...-B-...-U-A-D-E-C.

Breaking the order between B and others was the conscious
decision made by the upstream, so we would not worry about it,
and even if it were worrisome, it is too late for us to fix now.
What D and E do may well depend on having C applied before them,
which is a problem for us.

This rewrites rebase to use git-format-patch piped to git-am,
and when the patch does not apply, have git-am fall back on
3-way merge.  The updated diff/patch pair knows how to apply
trivial binary patches as long as the pre- and post-images are
locally available, so this should work on a repository with
binary files as well.

The primary benefit of this change is that it makes rebase
easier to use when some of the changes do not replay cleanly.
In the "unapplicable patch in the middle" case, this "rebase"
works like this:

 - A series of patches in e-mail form is created that records
   what A-C-D-E do, and is fed to git-am.  This is stored in
   .dotest/ directory, just like the case you tried to apply
   them from your mailbox.  Your branch is rewound to the tip of
   upstream U, and the original head is kept in .git/ORIG_HEAD,
   so you could "git reset --hard ORIG_HEAD" in case the end
   result is really messy.

 - Patch A applies cleanly.  This could either be a clean patch
   application on top of rewound head (i.e. same as upstream
   head), or git-am might have internally fell back on 3-way
   (i.e.  it would have done the same thing as git-cherry-pick).
   In either case, a rebased commit A is made on top of U.

 - Patch C does not apply.  git-am stops here, with conflicts to
   be resolved in the working tree.  Yet-to-be-applied D and E
   are still kept in .dotest/ directory at this point.  What the
   user does is exactly the same as fixing up unapplicable patch
   when running git-am:

   - Resolve conflict just like any merge conflicts.
   - "git am --resolved --3way" to continue applying the patches.

 - This applies the fixed-up patch so by definition it had
   better apply.  "git am" knows the patch after the fixed-up
   one is D and then E; it applies them, and you will get the
   changes from A-C-D-E commits on top of U, in this order.

I've been using this without noticing any problem, and as people
may know I do a lot of rebases.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This uses the git-update-ref command in scripts for safer updates.
Also places where we used to read HEAD ref by using "cat" were fixed
to use git-rev-parse.  This will matter when we start using symbolic
references.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

As promised, this is the "big tool rename" patch.  The primary differences
since 0.99.6 are:

  (1) git-*-script are no more.  The commands installed do not
      have any such suffix so users do not have to remember if
      something is implemented as a shell script or not.

  (2) Many command names with 'cache' in them are renamed with
      'index' if that is what they mean.

There are backward compatibility symblic links so that you and
Porcelains can keep using the old names, but the backward
compatibility support  is expected to be removed in the near
future.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The reverse patch application using "git apply" sometimes is too
rigid.  Since the user would get used to resolving conflicting merges
by hand during the normal merge experience, using the same machinery
would be more helpful rather than just giving up.

Cherry-picking and reverting are essentially the same operation.
You pick one commit, and apply the difference that commit introduces
to its own commit ancestry chain to the current tree.  Revert applies
the diff in reverse while cherry-pick applies it forward.  They share
the same logic, just different messages and merge direction.

Rewrite "git rebase" using "git cherry-pick".
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Otherwise the first commit rebase makes could include whatever
dirty state the original working tree had.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

It did not check to see if the working tree was clean and matched
the commit we were starting out as, resulting in the initial rebased
commit including whatever dirty state the working tree has had.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Make sure that we say --verify when we want to get a single SHA1
name.  Also when we say --verify, --revs-only is redundant.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Although these commands take only begin and end, not necessarily
generic SHA1 expressions rev-parse supports, supporting a..b
notation is good for consistency.  This commit adds such without
breaking backward compatibility.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

While moving '-m' to make room for CVS compatible "here is the
log message", enhance source of log parameters.

  -m 'message': a command line parameter.
  -F <file>   : a file (use '-' to read from stdin).
  -C <commit> : message in existing commit.
  -c <commit> : message in existing commit (allows further editing).

Longer option names for these options are also available.

While we are at it, get rid of shell array bashism.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This patch changes rev-parse users that pass a single argument
that is supposed to be a rev parameter to use "--verify".
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Using git-cherry, forward port local commits missing from the
new upstream head.  This also depends on "-m" flag support in
git-commit-script.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>