When you give a non-existent branch to git-rebase, it spits
out the usage. This can be confusing, since you may
understand the usage just fine, but simply have made a
mistake in the branch name.

Before:

  $ git rebase origin bogus
  Usage: git rebase ...

After:

  $ git rebase origin bogus
  fatal: no such branch: bogus
  Usage: git rebase ...
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In the case of a ref/pathname conflict, checkout will
already do the right thing and checkout the ref. However,
for a non-existant ref, this has two advantages:

  1. If a file with that pathname exists, rebase will
     refresh the file from the index and then rebase the
     current branch instead of producing an error.

  2. If no such file exists, the error message using an
     explicit "--" is better:

       # before
       $ git rebase -i origin bogus
       error: pathspec 'bogus' did not match any file(s) known to git.
       Could not checkout bogus

       # after
       $ git rebase -i origin bogus
       fatal: invalid reference: bogus
       Could not checkout bogus

The problems seem to be trigger-able only through "git
rebase -i", as regular git-rebase checks the validity of the
branch parameter as a ref very early on. However, it doesn't
hurt to be defensive.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If rebase.stat is set to true, a diffstat should be displayed. If it is
not set, it should default to false. However, if it is explicitly set to
false (or other value), a diffstat is still displayed, which is probably
not what most users would expect. Show diffstat only if it is set
to true.
Signed-off-by: NMartin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If a non-interactive rebase of a ref fails at commit X and is aborted by
the user, the ref will be updated twice. First to point at X (with the
reflog message "rebase finished: $head_name onto $onto"), and then back
to $orig_head. It should not be updated at all.
Signed-off-by: NMartin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If any strategy options are passed to -X, the strategy will always be
set to 'recursive'. According to the documentation, it should default to
'recursive' if it is not set, but it should be possible to set it to
other values.

This fixes a regression introduced in v1.7.3-rc0~67^2 (2010-07-29).
Signed-off-by: NMartin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It is more portable to say "VAR=VAL && export VAR" instead.

Noticed by Ævar.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

For the case of "diff.noprefix" in git-config, git-format-patch should
still output diff with standard prefixes for git-am
Signed-off-by: NOded Shimon <ods15@ods15.dyndns.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Due to two missing hyphens, The "force" keyword on the command line
would be taken as an alias for the --force-rebase option.
Signed-off-by: NWilly Tarreau <w@1wt.eu>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

git-rebase calls out to merge strategies, but did not support merge
strategy options so far.  Add this, in the same style used in
git-merge.

Sadly we have to do the full quoting/eval dance here, since
merge-recursive supports the --subtree=<path> option which potentially
contains whitespace.

This patch does not cover git rebase -i, which does not call any merge
strategy directly except in --preserve-merges, and even then only for
merges.

[jc: with a trivial fix-up for 'expr']
Signed-off-by: NMike Lundy <mike@fluffypenguin.org>
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When performing a non-interactive rebase, sometimes
"git rebase --continue" will fail if an unmodified file is
touched in the working directory:

    You must edit all merge conflicts and then
    mark them as resolved using git add

This is caused by "git diff-files" reporting a difference
between the index and the filesystem:

    :100644 100644 d00491...... 000000...... M	file

The fix is to run "git update-index --refresh" before
"git diff-files" as is done in git-rebase--interactive.
Signed-off-by: NDavid D. Kilzer <ddkilzer@kilzer.net>
Acked-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We currently do not disable diff.renames configuration while rebase
internally runs "format-patch" to feed "am -3".

The end user configuration for "diff" should not affect the result
produced by the higher level command that is related to "diff" only
because internally it is implemented in terms of it.

For that matter, I have a feeling that format-patch should not even look
at diff.renames, but we seem to have been doing this for a long time so
there is no easy way to fix this thinko.

In any case, here is a much straightforward fix for "rebase".

[jn: with test case from David]
Reported-by: NDavid D. Kilzer <ddkilzer@kilzer.net>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Strip out options before checking for a missing upstream argument.
Before:

 $ git rebase -m
 shift: 426: can't shift that many

After:

 $ git rebase -m
 Usage: git rebase ...

While at it, fix the usage message to explain that the upstream
argument is mandatory.
Reported-by: NJon Dowland <jmtd@debian.org>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

For git-rebase.sh, --no-ff is a synonym for --force-rebase.

For git-rebase--interactive.sh, --no-ff cherry-picks all the commits in
the rebased branch, instead of fast-forwarding over any unchanged commits.

--no-ff offers an alternative way to deal with reverted merges.  Instead of
"reverting the revert" you can use "rebase --no-ff" to recreate the branch
with entirely new commits (they're new because at the very least the
committer time is different).  This obviates the need to revert the
reversion, as you can re-merge the new topic branch directly.  Added an
addendum to revert-a-faulty-merge.txt describing the situation and how to
use --no-ff to handle it.
Signed-off-by: NMarc Branchaud <marcnarc@xiplink.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Luckily, all the support already happens to be there.
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We have to deal with two separate code paths: a normal rebase, which
actually goes through git-am; and rebase {-m|-s}.

The only small issue with both is that they need to remember the
original sha1 across a possible conflict resolution.  rebase -m
already puts this information in $dotest/current, and we just
introduce a similar file for git-am.

Note that in git-am, the hook really only runs when coming from
git-rebase: the code path that sets the $dotest/original-commit file
is guarded by a test for $dotest/rebasing.
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This regression was introduced by commit 0aa958d4 (rebase: replace
antiquated sed invocation, 2010-01-24), which changed the invocation of
"git rev-list | sed" to "git log".

It can be reproduced by something like this:
$ git rebase -s recursive origin/master
Signed-off-by: NMarkus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Use the modern form of printing a commit subject instead of piping
the output of rev-list to sed.
Signed-off-by: NStephen Boyd <bebarino@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The previous patch didn't parse "rebase --onto A...B" correctly when A
isn't an empty string. It also tried to be careful to notice a case in
which there are more than one merge bases, but forgot to give --all option
to merge-base, making the test pointless.

Fix these problems and add a test script to verify. Improvements to the
script to parse A...B syntax was taken from review comments by Johannes
Schindelin.
Signed-off-by: Nしらいし ななこ <nanako3@lavabit.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Introduce a command line option to override rerere.autoupdate configuration
variable to make it more useful.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If the user has exported the GREP_OPTIONS environment variable, the output
from "grep" and "egrep" in scripted Porcelains may be different from what
they expect.  For example, we may want to count number of matching lines,
by "grep" piped to "wc -l", and GREP_OPTIONS=-C3 will break such use.

The approach taken by this change to address this issue is to protect only
our own use of grep/egrep.  Because we do not unset it at the beginning of
our scripts, hook scripts run from the scripted Porcelains are exposed to
the same insanity this environment variable causes when grep/egrep is used
to implement logic (e.g. "grep | wc -l"), and it is entirely up to the
hook scripts to protect themselves.

On the other hand, applypatch-msg hook may want to show offending words in
the proposed commit log message using grep to the end user, and the user
might want to set GREP_OPTIONS=--color to paint the match more visibly.
The approach to protect only our own use without unsetting the environment
variable globally will allow this use case.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This is in spirit similar to "checkout A...B".  To re-queue a new set of
patches for a series that the original author prepared to apply on 'next'
on the same base as before, you would do something like this:

    $ git checkout next^0
    $ git am -s rerolled-series.mbox
    $ git rebase --onto next...jh/notes next

The first two commands recreates commits to be rebased as the original
author intended (i.e. applies directly on top of 'next'), and the rebase
command replays that history on top of the same commit the series being
replaced was built on (which is typically much older than the tip of
'next').
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It's a compound word.
Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Commit 4cfbe06f introduced the use of "git diff" to show
dirty state in a format more familiar to users. However, it
should have used the plumbing "git diff-files" instead.

Not only is it good practice in general to use plumbing in
scripts, but in this case we really don't want the automatic
pager to kick in for an error message.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Previous version expose the output of the plumbing update-index to the
user, which novice users have difficulty to understand.

We still need to run update-index to refresh the cache (if
diff.autorefreshindex is false, git diff won't do it).
Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Introduce --ignore-whitespace option and corresponding config bool to
ignore whitespace differences while applying patches, akin to the
'patch' program.

'git am', 'git rebase' and the bash git completion are made aware of
this option.
Signed-off-by: NGiuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

git-am and git-rebase are talkative scripts. Teach them to be quiet when
told, allowing them to speak only when they fail or experience errors.

The quiet option is maintained when git-am or git-rebase fails to apply
a patch. This means subsequent --resolved, --continue, --skip, --abort
invocations will be quiet if the original invocation was quiet.

Drop a handful of >&2 redirection; the rest of the program sends all the
info messages to stdout, not to stderr.
Signed-off-by: NStephen Boyd <bebarino@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NStephen Boyd <bebarino@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NMichele Ballabio <barra_cuda@katamail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Add the options --committer-date-is-author-date and --ignore-date
to git-rebase. They were introduced in commit a79ec62d for git-am.
These options imply --force-rebase.
Signed-off-by: NMichele Ballabio <barra_cuda@katamail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The behavior of --verbose is unchanged, but uses a different state
variable internally, so that the meaning of verbose output may be
expanded without affecting the diffstat. This is also reflected in
the documentation.

The configuration option rebase.stat works the same was as merg.stat,
but the default is currently false.
Signed-off-by: NTor Arne Vestbø <torarnv@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It does not make sense to provide multiple upstream branches to either
git pull --rebase, or to git rebase, so disallow both.
Signed-off-by: NJay Soffian <jaysoffian@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Normally, if the current branch is up to date, the rebase is aborted.
However, it may be desirable to allow rebasing even if the current
branch is up to date. When using the '--whitespace=fix' option -f is
implied.
Signed-off-by: NSverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Teach git-rebase a new option --root, which instructs it to rebase the
entire history leading up to <branch>.  This option must be used with
--onto <newbase>, and causes commits that already exist in <newbase>
to be skipped.  (Normal operation skips commits that already exist in
<upstream> instead.)

One possible use-case is with git-svn: suppose you start hacking
(perhaps offline) on a new project, but later notice you want to
commit this work to SVN.  You will have to rebase the entire history,
including the root commit, on a (possibly empty) commit coming from
git-svn, to establish a history connection.  This previously had to
be done by cherry-picking the root commit manually.
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If you have unstaged changes in your working tree and try to
rebase, you will get the cryptic "foo: needs update"
message, but nothing else.  If you have staged changes, you
get "your index is not up-to-date".

Let's improve this situation in two ways:

 - for unstaged changes, let's also tell them we are
   canceling the rebase, and why (in addition to the "needs
   update" lines)

 - for the staged changes case, let's use language that is a
   little more clear to the user: their index contains
   uncommitted changes
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NMiklos Vajna <vmiklos@frugalware.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It is sometimes desirable to disable the safety net of pre-rebase hook
when the user knows what he is doing (for example, when the original
changes on the branch have not been shown to the public yet).

This teaches --no-verify option to git-rebase, which is similar to the way
pre-commit hook is bypassed by git-commit.
Signed-off-by: NNanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

The original git-rebase honored pre-rebase hook so that public branches
can be protected from getting rebased, but rebase --interactive ignored
the hook entirely.  This fixes it.
Signed-off-by: NNanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

As a result of implementation details, 'git rebase' could
previously only preserve merges in interactive mode. That
limitation was hard for users to understand and awkward to
explain.

This patch works around it by running the interactive rebase
helper git-rebase--interactive with GIT_EDITOR set to ':'
when the user passes "-p" but not "-i" to the rebase command.
The effect is that the interactive rebase helper is used but
the user never sees an editor.

The test-case included in this patch was originally written
by Stephen Habermann <stephen@exigencecorp.com>, but has
been extensively modified since its creation.
Signed-off-by: NAndreas Ericsson <ae@op5.se>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

"git rebase" without arguments on initial startup showed:

	fatal: Needed a single revision
	invalid upstream

This patch makes it show the ordinary usage string.

If .git/rebase-merge or .git/rebase-apply/rebasing exists, git-rebase
will die with a message saying that a rebase is in progress and the user
should try --skip/--abort/--continue.

If .git/rebase-apply/applying exists, git-rebase will die with a message
saying that git-am is in progress, regardless how many arguments are
given.

If no arguments are given and .git/rebase-apply/ exists, but neither a
rebasing nor applying file is in that directory, git-rebase dies with a
message saying that rebase-apply exists and no arguments were given.
Signed-off-by: NStephan Beyer <s-beyer@gmx.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

With git-am, it sounds awkward to have the patches in ".git/rebase/",
but for technical reasons, we have to keep the same directory name
for git-am and git-rebase. ".git/rebase-apply" seems to be a good
compromise.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>