When rebasing or stashing, chances are that you do not care about
dirty submodules, since they are not updated by those actions anyway.
So ignore the submodules' states.
Note: the submodule states -- as committed in the superproject --
will still be stashed and rebased, it is _just_ the state of the
submodule in the working tree which is ignored.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On some shells (notably /bin/sh on FreeBSD 6.1), the
construct
foo && ! bar | baz
is true if
foo && baz
whereas for most other shells (such as bash) is true if
foo && ! baz
We can work around this by specifying
foo && ! (bar | baz)
which works everywhere.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also update t/t3407-rebase-abort.sh to expose the bug.
Signed-off-by: Bryan Donlan <bdonlan@fushizen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This teaches "git rebase [--onto O] A B" to omit an unnecessary checkout
of branch B before it goes on.
"git-rebase" originally was about rebasing the current branch to somewhere
else, and when the extra parameter to name which branch to rebase was
added, it defined the semantics to the safest but stupid "first switch to
the named branch and then operate exactly the same way as if we were
already on that branch".
But the first thing the real part of "rebase" does is to reset the work
tree and the index to the "onto" commit. Which means the "rebase that
branch" form switched the work tree to the tip of the branch only to
immediately switch again to another commit. This was wasteful.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When rebasing changes that contain issues that the pre-commit hook flags
as problematic, the rebase cannot be continued. However, rebase is about
transplanting commits that are already made with as little distortion as
possible, and pre-commit check should not interfere.
Earlier, c5b09fe (Avoid update hook during git-rebase --interactive,
2007-12-19) fixed "rebase -i", but "rebase -m" shared the same issue.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, --abort would end by git resetting to ORIG_HEAD, but some
commands, such as git reset --hard (which happened in git rebase --skip,
but could just as well be typed by the user), would have already modified
ORIG_HEAD.
Just use the orig-head we store in $dotest instead.
[jc: cherry-picked from 48411d and 4947cf9 on 'master']
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Being in the project's top directory when starting or continuing a rebase
is not necessary since 533b703 (Allow whole-tree operations to be started
from a subdirectory, 2007-01-12).
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The new option --rebasing is used internally for rebase to tell am that
it is being used for its purpose. This would leave .dotest/rebasing to
help "completion" scripts tell if the ongoing operation is am or rebase.
Also the option at the same time stands for --binary, -3 and -k which
are always given when rebase drives am as its backend.
Using the information "am" leaves, git-completion.bash tells ongoing
rebase and am apart.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, --abort would end by git resetting to ORIG_HEAD, but some
commands, such as git reset --hard (which happened in git rebase --skip,
but could just as well be typed by the user), would have already modified
ORIG_HEAD.
Just use the orig-head we store in $dotest instead.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you have a file called HEAD in your work tree, many commands that
our scripts feed "HEAD" to would complain about the rev vs path
ambiguity. A solution is to form command line more carefully by
appending -- to them, which makes it clear that we mean HEAD rev not
HEAD file.
This patch would apply to maint.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --skip case was handled properly when rebasing without --merge,
but the --continue case was not.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you have a merge conflict and want to bypass the commit causing it,
you don't want to care about the dirty state of the working tree.
Also, don't git reset --hard HEAD in the rebase-skip test, so that the
lack of support for this is detected.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The interactive version of rebase does all the operations on a detached
HEAD, so that after a successful rebase, <branch>@{1} is the pre-rebase
state. The reflogs of "HEAD" still show all the actions in detail.
This teaches the non-interactive version to do the same.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
--text follows this line--
These commands currently lack OPTIONS_SPEC; allow people to
easily list with "git grep 'OPTIONS_SPEC=$'" what they can help
improving.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-rebase used to fail when run from a path containing a space.
Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This reverts commit 6c9ad166db.
Allowing rebase to start in a dirty tree might have been a worthy
goal, but it is not necessarily always wanted (some people prefer
to be reminded that the state is dirty, and think about the next
action that may not be to stash and proceed). Furthermore, depending
on the nature of local changes, unstashing the dirty state on top of
the rebased result is not always desirable.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-rebase used to fail when run from a path containing a space.
Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A lot of shell scripts contained stuff starting with
while case "$#" in 0) break ;; esac
and similar. I consider breaking out of the condition instead of the
body od the loop ugly, and the implied "true" value of the
non-matching case is not really obvious to humans at first glance. It
happens not to be obvious to some BSD shells, either, but that's
because they are not POSIX-compliant. In most cases, this has been
replaced by a straight condition using "test". "case" has the
advantage of being faster than "test" on vintage shells where "test"
is not a builtin. Since none of them is likely to run the git
scripts, anyway, the added readability should be worth the change.
A few loops have had their termination condition expressed
differently.
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This uses the new "git stash create" interface to stash away the dirty state
you have in your working tree before starting a rebase, and then replaying
it when you are done with stashing.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The extra shift here causes failure to parse any commandline including
the -C option.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pass --whitespace=<option> to git-apply. Since git-apply and git-am
expect this, I'm always surprised when I try to give it to git-rebase
and it doesn't work.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a topic branch is rebased, some of whose commits are already
cherry-picked upstream:
o--X--A--B--Y <- master
\
A--B--Z <- topic
then 'git rebase -m master' would report:
Already applied: 0001 Y
Already applied: 0002 Y
With this fix it reports the expected:
Already applied: 0001 A
Already applied: 0002 B
As an added bonus, this change also avoids 'echo' of a commit message,
which might contain escapements.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier, "git rerere" was enabled by creating the directory
.git/rr-cache. That is definitely not in line with most other
features, which are enabled by a config variable.
So, check the config variable "rerere.enabled". If it is set
to "false" explicitely, do not activate rerere, even if
.git/rr-cache exists. This should help when you want to disable
rerere temporarily.
If "rerere.enabled" is not set at all, fall back to detection
of the directory .git/rr-cache.
[jc: with minimum tweaks]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Consider this history:
o--o-...-B <- origin
\ \
x--x--M--x--x <- master
In this situation, rebase considers master fully up-to-date and would
not do anything. However, if there were additional commits on origin,
the rebase would run and move the commits x on top of origin.
Here we change rebase to short-circuit out only if the history since origin
is strictly linear. Consequently, the above as well as a history like this
would be linearized:
o--o <- origin
\
x--x
\ \
x--M--x--x <- master
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Don't you just hate the fact sometimes, that git-rebase just applies
the patches, without any possibility to edit them, or rearrange them?
With "--interactive", git-rebase now lets you edit the list of patches,
so that you can reorder, edit and delete patches.
Such a list will typically look like this:
pick deadbee The oneline of this commit
pick fa1afe1 The oneline of the next commit
...
By replacing the command "pick" with the command "edit", you can amend
that patch and/or its commit message, and by replacing it with "squash"
you can tell rebase to fold that patch into the patch before that.
It is derived from the script sent to the list in
<Pine.LNX.4.63.0702252156190.22628@wbgn013.biozentrum.uni-wuerzburg.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The command is part of the main porcelain making git-add more
appropriate.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The rebase and merge commands used diff-tree to display the summary stats of
what files had changed from the operation. diff-tree does not read the
diff ui configuration options, so the diff.color setting was not used.
Have rebase and merge call diff rather than diff-tree, which does read the
diff ui options.
Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This simplifies the shell code, reduces its memory footprint, and
speeds things up. The performance improvements should be noticable
when git-rebase works on big commits.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When you want to amend the commit message of 3 commits before
the tip of the current branch, say 'master',
A--B--C--D--E(master)
it is sometimes handy to make your head detached at that commit
with:
$ git checkout HEAD~3 ;# check out B
$ git commit --amend ;# without modifying contents...
to create:
.B'(HEAD)
/
A--B--C--D--E(master)
and then rebase 'master' branch onto HEAD with this:
$ git rebase HEAD master
to result in:
.B'-C'-D'-E(master=HEAD)
/
A--B--C--D--E
However, the current code interprets HEAD after it switches to
the branch 'master', which means the rebase will not do
anything. You have to say something unwieldly like this
instead:
$ git rebase $(git rev-parse HEAD) master
This fixes it by expanding the $onto commit name before
switching to the target branch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add -C[NUM] to git-am and git-rebase so that patches can be applied even
if context has changed a bit.
Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the index wasn't clean, git-rebase would simply show the output from
git-diff-index with no further comment to the user.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates five commands (merge, pull, rebase, revert and cherry-pick)
so that they can be started from a subdirectory.
This may not actually be what we want to do. These commands are
inherently whole-tree operations, and an inexperienced user may
mistakenly expect a "git pull" from a subdirectory would merge
only the subdirectory the command started from.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the user tries to run a porcelainish command which requires
a working directory in a bare repository they may get unexpected
results which are difficult to predict and may differ from command
to command.
Instead we should detect that the current repository is a bare
repository and refuse to run the command there, as there is no
working directory associated with it.
[jc: updated Shawn's original somewhat -- bugs are mine.]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If a three-way merge in git-rebase generates a conflict then we
should take advantage of git-merge-recursive's ability to include
the branch name of each side of the conflict hunk by setting the
GITHEAD_* environment variables.
In the case of rebase there aren't really two clear branches; we
have the branch we are rebasing onto, and we have the branch we are
currently rebasing. Since most conflicts will be arising between
the user's current branch and the branch they are rebasing onto
we assume the stuff that isn't in the current commit is the "onto"
branch and the stuff in the current commit is the "current" branch.
This assumption may however come up wrong if the user resolves one
conflict in such a way that it conflicts again on a future commit
also being rebased. In this case the user's prior resolution will
appear to be in the "onto" part of the hunk.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio rightly pointed out that the --reflog-action parameter
was starting to get out of control, as most porcelain code
needed to hand it to other porcelain and plumbing alike to
ensure the reflog contained the top-level user action and
not the lower-level actions it invoked.
At Junio's suggestion we are introducing the new set_reflog_action
function to all shell scripts, allowing them to declare early on
what their default reflog name should be, but this setting only
takes effect if the caller has not already set the GIT_REFLOG_ACTION
environment variable.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
An earlier commit made "reset --hard" chattier but leaking its
message from "git rebase" (which calls it when first rewinding
the current branch to prepare replaying our own changes) without
explanation was confusing, so add an extra message to mention
it. Inside restorestate in merge (which is rarely exercised
codepath, where more than one strategies are attempted),
resetting to the original state uses "reset --hard" -- this can
be squelched entirely.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Data in rr-cache isn't valid after a patch application is
skipped or and aborted, so our next commit could be misrecorded
as a resolution of that skipped/failed commit, which is wrong.
git-am --skip, git-rebase --skip/--abort will automatically
invoke git-rerere clear to avoid this.
Also, since git-am --resolved indicates a resolution was
succesful, remember to run git-rerere to record the resolution
(and not surprise the user when the next commit is made).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This reduces the number of conflicts when rebasing after a series of
patches to the same piece of code is committed upstream.
Signed-off-by: Robert Shearman <rob@codeweavers.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This reduces the number of conflicts when rebasing after a series of
patches to the same piece of code is committed upstream.
Signed-off-by: Robert Shearman <rob@codeweavers.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This renames merge-recursive written in Python to merge-recursive-old,
and makes merge-recur as a synonym to merge-recursive. We do not remove
merge-recur yet, but we will remove merge-recur and merge-recursive-old
in a few releases down the road.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Previously, a rebasing operation with on a branch that is just tracking
an upstream branch would output a confusing "Nothing to do" due to no
patches being given to git-am.
The test brings the behaviour back into line with that of just before
e646c9c8c0.
Signed-off-by: Robert Shearman <rob@codeweavers.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
During git-merge-recur development, you could set an environment
variable GIT_USE_RECUR_FOR_RECURSIVE to use WIP recur in place
of the recursive strategy.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is just an update for people being interested. Alex and me were
busy with that project for a few days now. While it has progressed nicely,
there are quite a couple TODOs in merge-recursive.c, just search for "TODO".
For impatient people: yes, it passes all the tests, and yes, according
to the evil test Alex did, it is faster than the Python script.
But no, it is not yet finished. Biggest points are:
- there are still three external calls
- in the end, it should not be necessary to write the index more than once
(just before exiting)
- a lot of things can be refactored to make the code easier and shorter
BTW we cannot just plug in git-merge-tree yet, because git-merge-tree
does not handle renames at all.
This patch is meant for testing, and as such,
- it compile the program to git-merge-recur
- it adjusts the scripts and tests to use git-merge-recur instead of
git-merge-recursive
- it provides "TEST", a script to execute the tests regarding -recursive
- it inlines the changes to read-cache.c (read_cache_from(), discard_cache()
and refresh_cache_entry())
Brought to you by Alex Riesen and Dscho
Signed-off-by: Junio C Hamano <junkio@cox.net>
Johannes Schindelin