The sub commands '--continue', '--skip' or '--abort' may only be used
standalone according to the documentation. Other options following the
sub command are currently not accepted, but options preceeding them
are. For example, 'git rebase --continue -v' is not accepted, while
'git rebase -v --continue' is. Tighten up the check and allow no other
options when one of these sub commands are used.
Only check that it is standalone for non-interactive rebase for
now. Once the command line processing for interactive rebase has been
replaced by the command line processing in git-rebase.sh, this check
will also apply to interactive rebase.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To later be able to use the command line processing in git-rebase.sh
for both interactive and non-interactive rebases, move anything that
is specific to non-interactive rebase outside of the parsing
loop. Keep only parsing and validation of command line options in the
loop.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Detect early on if a rebase is in progress and what type of rebase it
is (interactive, merge-based or am-based). This prepares for further
refactoring where am-based rebase will be dispatched to
git-rebase--am.sh and merge-based rebase will be dispatched to
git-rebase--merge.sh.
The idea is to use the same variables whether the type of rebase was
detected from rebase-apply/ or rebase-merge/ directories or from the
command line options. This will make the code more readable and will
later also make it easier to dispatch to the type-specific scripts.
Also show a consistent error message independent of the type of rebase
that was in progress and remove the obsolete wording about being in
the middle of a 'patch application', since that (an existing
"$GIT_DIR"/rebase-apply/applying) aborts 'git rebase' at an earlier
stage.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The state stored in $GIT_DIR/rebase-merge/prev_head was introduced in
58634db (rebase: Allow merge strategies to be used when rebasing,
2006-06-21), but it was never used and should therefore be removed.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'onto_name' state used in 'git rebase --merge' is currently read
once for each commit that need to be applied. It doesn't change
between each iteration, however, so it should be moved out of the
loop. This also makes the code more readable. Also remove the unused
variable 'end'.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code reading the state saved in $merge_dir or $rebase_dir is
currently spread out in many places, making it harder to read and to
introduce additional state. Extract this code into one method that
reads the state. Only extract the code associated with the state that
is written when the rebase is initiated. Leave the state that changes
for each commmit, at least for now.
Currently, when resuming a merge-based rebase using --continue or
--skip, move_to_original_branch (via finish_rb_merge) will be called
without head_name and orig_head set. These variables are then lazily
read in move_to_original_branch if head_name is not set (together with
onto, which is unnecessarily read again). Change this by always
eagerly reading the state, for both am-based and merge-based rebase,
in the --continue and --skip cases. Note that this does not change the
behavior for am-based rebase, which read the state eagerly even before
this commit.
Reading the state eagerly means that part of the state will sometimes
be read unnecessarily. One example is when the rebase is continued,
but stops again at another merge conflict. Another example is when the
rebase is aborted. However, since both of these cases involve user
interaction, the delay is hopefully not noticeable. The
call_merge/continue_merge loop is not affected.
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of using the old variable name 'dotest' for
"$GIT_DIR"/rebase-merge and no variable for "$GIT_DIR"/rebase-apply,
introduce two variables 'merge_dir' and 'apply_dir' for these paths.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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: Jeff King <peff@peff.net>
Signed-off-by: Junio 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: Jeff King <peff@peff.net>
Signed-off-by: Junio 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: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio 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: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Interactive rebase allows the '--verify' option to be passed, but it will
be ignored. Implement proper support for the option for both interactive
and non-interactive rebase by making it override any previous
'--no-verify'.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio 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: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Although Git interally has the facility to differentiate between
porcelain and plubmbing commands and appropriately print errors,
several shell scripts invoke plubming commands triggering cryptic
plumbing errors to be displayed on a porcelain interface. This patch
replaces the "needs update" message in git-pull and git-rebase, when
`git update-index` is run, with a more friendly message.
Reported-by: Joshua Jensen <jjensen@workspacewhiz.com>
Reported-by: Thore Husfeldt <thore.husfeldt@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio 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: Oded Shimon <ods15@ods15.dyndns.org>
Signed-off-by: Junio 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: Willy Tarreau <w@1wt.eu>
Signed-off-by: Junio 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: Mike Lundy <mike@fluffypenguin.org>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio 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: David D. Kilzer <ddkilzer@kilzer.net>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio 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: David D. Kilzer <ddkilzer@kilzer.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio 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: Jon Dowland <jmtd@debian.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio 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: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Luckily, all the support already happens to be there.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio 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: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This regression was introduced by commit 0aa958d (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: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio 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: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio 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: しらいし ななこ <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce a command line option to override rerere.autoupdate configuration
variable to make it more useful.
Signed-off-by: Junio 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: Junio 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: Junio C Hamano <gitster@pobox.com>
Commit 4cfbe06 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: Jeff King <peff@peff.net>
Signed-off-by: Junio 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: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio 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: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio 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: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add the options --committer-date-is-author-date and --ignore-date
to git-rebase. They were introduced in commit a79ec62d0 for git-am.
These options imply --force-rebase.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Junio 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: Tor Arne Vestbø <torarnv@gmail.com>
Signed-off-by: Junio 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: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio 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: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio 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: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio 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: Jeff King <peff@peff.net>
Signed-off-by: Junio 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: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Shawn 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: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Shawn 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: Andreas Ericsson <ae@op5.se>
Signed-off-by: Shawn 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: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio 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: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since the files generated and used during a rebase are never to be
tracked, they should live in $GIT_DIR. While at it, avoid the rather
meaningless term "dotest" to "rebase", and unhide ".dotest-merge".
This was wished for on the mailing list, but so far unimplemented.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Martin von Zweigbergk