The existing parent rewriting did not handle the case where a previous
commit was amended (via edit or squash). Fix by always putting the
new sha1 of the last commit into the $REWRITTEN map.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
'git rebase -i -p' forgot to update the index and working directory
during fast forwards. Fix this. Makes 'GIT_EDITOR=true rebase -i -p
<ancestor>' a no-op again.
Also, it attempted to do a fast forward even if it was instructed not
to commit (via -n). Fall back to the cherry-pick code path and let
that handle the issue for us.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
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>
There are two cases for preserving merges:
1. The merge base is outside the trunk that is to be rebased.
Then commits of those other parents must not be picked.
2. The merge base is inside the trunk that is to be rebased.
Then all the commits related to that merge must be picked
and the merge must be redone.
The "preserve merges with -p" test case tested for case 1 only.
This patch adds case 2.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This fixes the remainder of the issues where the test script itself is at
fault for failing when the git checkout path contains whitespace or other
shell metacharacters.
The majority of git svn tests used the idiom
test_expect_success "title" "test script using $svnrepo"
These were changed to have the test script in single-quotes:
test_expect_success "title" 'test script using "$svnrepo"'
which unfortunately makes the patch appear larger than it really is.
One consequence of this change is that in the verbose test output the
value of $svnrepo (and in some cases other variables, too) is no
longer expanded, i.e. previously we saw
* expecting success:
test script using /path/to/git/t/trash/svnrepo
but now it is:
* expecting success:
test script using "$svnrepo"
Signed-off-by: Bryan Donlan <bdonlan@fushizen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many scripts compare actual and expected output using
"diff -u". This is nicer than "cmp" because the output shows
how the two differ. However, not all versions of diff
understand -u, leading to unnecessary test failure.
This adds a test_cmp function to the test scripts and
switches all "diff -u" invocations to use it. The function
uses the contents of "$GIT_TEST_CMP" to compare its
arguments; the default is "diff -u".
On systems with a less-capable diff, you can do:
GIT_TEST_CMP=cmp make test
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "-n" syntax is not supported by System V versions of
tail (which prefer "tail -1"). Unfortunately "tail -1" is
not actually POSIX. We had some of both forms in our
scripts.
Since neither form works everywhere, this patch replaces
both with the equivalent sed invocation:
sed -ne '$p'
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
System V versions of grep (such as Solaris /usr/bin/grep)
don't understand either of these options. git's usage of
"grep -e pattern" fell into one of two categories:
1. equivalent to "grep pattern". -e is only useful here if
the pattern begins with a "-", but all of the patterns
are hardcoded and do not begin with a dash.
2. stripping comments and blank lines with
grep -v -e "^$" -e "^#"
We can fortunately do this in the affirmative as
grep '^[^#]'
Uses of "-q" can be replaced with redirection to /dev/null.
In many tests, however, "grep -q" is used as "if this string
is in the expected output, we are OK". In this case, it is
fine to just remove the "-q" entirely; it simply makes the
"verbose" mode of the test slightly more verbose.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The top-level Makefile now creates a GIT-BUILD-OPTIONS file
which stores any options selected by the make process that
may be of use to further parts of the build process.
Specifically, we store the SHELL_PATH so that it can be used
by tests to construct shell scripts on the fly.
The format of the GIT-BUILD-OPTIONS file is Bourne shell,
and it is sourced by test-lib.sh; all tests can rely on just
having $SHELL_PATH correctly set in the environment.
The GIT-BUILD-OPTIONS file is written every time the
toplevel 'make' is invoked. Since the only users right now
are the test scripts, there's no drawback to updating its
timestamp. If something build-related depends on this, we
can do a trick similar to the one used by GIT-CFLAGS.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The fake-editor shell script invoked /bin/sh; normally this
is fine, unless the /bin/sh doesn't meet our compatibility
requirements, as is the case with Solaris. Specifically, the
$() syntax used by fake-editor is not understood.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to use "cat-file commit $commit" to extract the original
author information from existing commit, but an earlier commit
5ac2715 (Consistent message encoding while reusing log from an
existing commit) changed it to use "git show -s $commit". If
you have a file in your work tree that can be interpreted as a
valid object name (e.g. "HEAD"), this conversion will not work.
Disambiguate by marking the end of revision parameter on the
comand line with an explicit "--" to fix this.
This breakage is most visible with rebase when a file called
"HEAD" exists in the worktree.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This accompanies c5b09feb78 (Avoid
update hook during git-rebase --interactive) to make sure that
any regression to make Debian's Bug#458782 (git-core: git-rebase
doesn't work when trying to squash changes into commits created
with --no-verify) resurface will be caught.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since commit 376ccb8cbb (rebase -i: style
fixes and minor cleanups), unchanged SHA-1s are no longer mapped via
$REWRITTEN. But the updating phase was not prepared for the old head
not being rewritten.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
[PATCH] rebase -i: move help to end of todo file
Many editors start in the first line, so the 9-line help text was an
annoyance. So move it to the end.
Requested by Junio.
While at it, add a hint how to abort the rebase.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It was determined on the mailing list, that it makes more sense for a
"squash" to keep the author of the first commit as the author for the
result of the squash.
Make it so.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier, rebase -i refused to rebase a detached HEAD. Now it no longer
does.
Incidentally, this fixes "git gc --auto" shadowing the true exit status.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When doing an "edit" on a commit, editing and git-adding some files,
"git rebase -i" complained about a missing "author-script". The idea was
that the user would call "git commit --amend" herself.
But we can be nice and do that for the user.
Noticed by Dmitry Potapov.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When squashing, rebase -i did not prevent fast forwards. This could
happen when picking some other commit than the first one, and then
squashing the first commit. So do not allow fast forwards when
squashing.
Noticed by Johannes Sixt.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Here-text to create fake-editor did not use <<\EOF but <<EOF,
but there was no point doing so, as it quoted all the variables
anyway. Simplify it.
Also futureproof the special mode to edit COMMIT_EDITMSG file;
it is interested in editing the COMMIT_EDITMSG file in any
GIT_DIR; GIT_DIR may be given as an absolute path.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When calling "git rebase -i <upstream> <branch>", git should switch
to <branch> first. This worked before, but I broke it by my
"Shut git rebase -i up" patch.
Fix that, and add a test to make sure that it does not break again.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Non-interactive rebase had this from the beginning -- match it by
using --cherry-pick option to rev-list.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a squashing merge failed, the first commit would not be replaced,
due to "git reset --soft" being called with an unmerged index.
Noticed by Uwe Kleine-König.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sometimes you want to squash more than two commits. Before this patch,
the editor was fired up for each squash command. Now the editor is
started only with the last squash command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After interruption, be that an edit, or a conflicting commit, reset
the variables VERBOSE, STRATEGY and PRESERVE_MERGES, so that the
user does not have to respecify them with "rebase --continue".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Non-interactive rebase requires the working tree to be clean, but
applies what is in the index without requiring the user to do it
herself. Imitate that, but (since we are interactive, after all)
fire up an editor with the commit message.
It also fixes a subtle bug: a forgotten "continue" was removed, which
led to an infinite loop when continuing without remaining patches.
Both issues noticed by Frank Lichtenheld.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The option "-p" (or long "--preserve-merges") makes it possible to
rebase side branches including merges, without straightening the
history.
Example:
X
\
A---M---B
/
---o---O---P---Q
When the current HEAD is "B", "git rebase -i -p --onto Q O" will yield
X
\
---o---O---P---Q---A'---M'---B'
Note that this will
- _not_ touch X [*1*], it does
- _not_ work without the --interactive flag [*2*], it does
- _not_ guess the type of the merge, but blindly uses recursive or
whatever strategy you provided with "-s <strategy>" for all merges it
has to redo, and it does
- _not_ make use of the original merge commit via git-rerere.
*1*: only commits which reach a merge base between <upstream> and HEAD
are reapplied. The others are kept as-are.
*2*: git-rebase without --interactive is inherently patch based (at
least at the moment), and therefore merges cannot be preserved.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If your rebase succeeded, the HEAD's reflog will still show the whole
mess, but "<branchname>@{1}" now shows the state _before_ the rebase,
so that you can reset (or compare) the original and the rebased
revisions more easily.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Support "--verbose" in addition to "-v", show short names in the list
comment, clean up if there is nothing to do, and add several "test_ticks"
in the test script.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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>
Thomas Rast