Previously, the pre-rebase-hook would be launched before we knew if
the <upstream> [<branch>] arguments were supplied.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a merge that has a conflict was rebased, then rebase stopped to let
the user resolve the conflicts. However, thereafter --continue failed
because the author-script was not saved. (This is rebase -i's way to
preserve a commit's authorship.) This fixes it by doing taking the same
failure route after a merge that is also taken after a normal cherry-pick.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sh/rebase-i-p:
git-rebase--interactive.sh: comparision with == is bashism
rebase-i-p: minimum fix to obvious issues
rebase-i-p: if todo was reordered use HEAD as the rewritten parent
rebase-i-p: do not include non-first-parent commits touching UPSTREAM
rebase-i-p: only list commits that require rewriting in todo
rebase-i-p: fix 'no squashing merges' tripping up non-merges
rebase-i-p: delay saving current-commit to REWRITTEN if squashing
rebase-i-p: use HEAD for updating the ref instead of mapping OLDHEAD
rebase-i-p: test to exclude commits from todo based on its parents
Jeff King noticed that this series uses non-portable ${var:0:7} syntax
to splice a string, which is not even in POSIX, in the script. A quick
look at around the offending part revealed a few issues, which this commit
fixes:
* Why filter output from "rev-list --left-right A...B" and look for the
ones that begin with ">"? Wouldn't "rev-list A..B" give that?
* The abbreviated SHA-1 are made with "rev-list --abbrev=7" into $TODO in
an earlier invocation, and it can be more than 7 letters to avoid
ambiguity. Not just that "${r:0:7} is not even in POSIX", but use of
it here is actively wrong.
* There is no point in catting a single file and piping it into grep.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This seems like the best guess we can make until git sequencer marks are
available. That being said, within the context of re-ordering a commit before
its parent in todo, I think applying it on top of the current commit seems like
a reasonable assumption of what the user intended.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This covers an odd boundary case found by Avi Kivity's script where a branch
coming off of UPSTREAM is merged into HEAD. Initially it show up in
UPSTREAM..HEAD, but technically UPSTREAM is not moving, the rest of head is, so
we should not need to rewrite the merge.
This adds a check saying we can keep `preserve=t` if `p=UPSTREAM`...unless this
is the first first-parent commit in our UPSTREAM..HEAD rev-list, which could
very well point to UPSTREAM, but we still need to consider it as rewritten so we
start pulling in the rest of the UPSTREAM..HEAD commits that point to it.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is heavily based on Stephan Beyer's git sequencer rewrite of rebase-i-p.
Each commit is still found by rev-list UPSTREAM..HEAD, but a commit is only
included in todo if at least one its parents has been marked for rewriting.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also only check out the first parent if this commit if not a squash--if it is a
squash, we want to explicitly ignore the parent and leave the wc as is, as
cherry-pick will apply the squash on top of it.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the current-commit was dumped to REWRITTEN, but then we squash the next
commit in to it, we have invalidated the HEAD was just written to REWRITTEN.
Instead, append the squash hash to current-commit and save both of them the next
time around.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If OLDHEAD was reordered in the todo, and its mapped NEWHEAD was used to set the
ref, commits reordered after OLDHEAD in the todo would should up as un-committed
changes.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
`rebase -i -p` got its rev-list of commits to keep by --left-right and
--cherry-pick. Adding --cherry-pick would drop commits that duplicated changes
already in the rebase target.
The dropped commits were then forgotten about when it came to rewriting the
parents of their descendents, so the descendents would get cherry-picked with
their old, unwritten parents and essentially make the rebase a no-op.
This commit adds a $DOTEST/dropped directory to remember dropped commits and
rewrite their children's parent as the dropped commit's possibly-rewritten
first-parent.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In case there is no commit to apply (for example because you rebase to
upstream and all your local patches have been applied there), do not
fail. The non-interactive rebase already behaves that way.
Do this by introducing a new command, "noop", which is substituted for
an empty commit list, so that deleting the commit list can still abort
as before.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
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>
One would expect that the prepare-commit-msg hook gets 'squash' as the
second argument when squashing commits with 'rebase -i'. However,
that was not the case, as it got 'merge' instead. This patch fixes
the problem.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
"git rebase --continue" issued after git rebase being stop by "edit"
command is trying to amend the last commit using stage changes. However,
if the last commit is not the commit that was marked as "edit" then it
can produce unexpected results.
For instance, after being stop by "edit", I have made some changes to
commit message using "git commit --amend". After that I realized that
I forgot to add some changes to some file. So, I said "git add file"
and the "git rebase --continue". Unfortunately, it caused that the new
commit message was lost.
Another problem is that after being stopped at "edit", the user adds new
commits. In this case, automatic amend behavior of git rebase triggered
by some stage changes causes that not only that the log message of the
last commit is lost but that it will contain also wrong Author and Date
information.
Therefore, this patch restrict automatic amend only to the situation
where HEAD is the commit at which git rebase stop by "edit" command.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If git rebase interactive is stopped by "edit" command and then the user
said "git rebase --continue" while having some stage changes, git rebase
interactive is trying to amend the last commit by doing:
git --soft reset && git commit
However, the user can abort commit for some reason by providing an empty
log message, and that would leave the last commit undone, while the user
being completely unaware about what happened. Now if the user tries to
continue, by issuing "git rebase --continue" that squashes two previous
commits.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
In a rebase session where more than one commit is to be 'edit'ed, and the
user spends considerable time to 'edit' a commit, it is easy to forget what
one wanted to 'edit' at the individual commits. It would be helpful to see
at which commit the rebase stopped.
Incidentally, if the rebase stopped due to merge conflicts or other errors,
the commit was already reported ("Could not apply $sha1..."), but when
rebase stopped after successfully applying an "edit" commit, it would not
mention it. With this change the commit is reported.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Start preparing 1.5.6.4 release notes
git fetch-pack: do not complain about "no common commits" in an empty repo
rebase-i: keep old parents when preserving merges
t7600-merge: Use test_expect_failure to test option parsing
Fix buffer overflow in prepare_attr_stack
Fix buffer overflow in git diff
Fix buffer overflow in git-grep
git-cvsserver: fix call to nonexistant cleanupWorkDir()
Documentation/git-cherry-pick.txt et al.: Fix misleading -n description
Conflicts:
RelNotes
When "rebase -i -p" tries to preserve merges of unrelated branches, it
lost some parents:
- When you have more than two parents, the commit in the new history
ends up with fewer than expected number of parents and this breakage
goes unnoticed;
- When you are rebasing a merge with two parents and one is lost, the
command tries to cherry-pick the original merge commit, and the command
fails.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
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>
Also add some checks that --continue/--abort/--skip
actions are used without --onto, -p, -t, etc.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"merge" and "reset" leave the original point in history in ORIG_HEAD,
which makes it easy to go back to where you were before you inflict a
major damage to your history and realize that you do not like the result
at all. These days with reflog, we technically do not need to use
ORIG_HEAD, but it is a handy way nevertheless.
This teaches "am" and "rebase" (all forms --- the vanilla one that uses
"am" as its backend, "-m" variant that cherry-picks, and "--interactive")
to do the same.
The original idea and a partial implementation to do this only for "rebase
-m" was by Brian Gernhardt; this extends on his idea.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git rebase -i already supports 'p', 'e' and 's' as aliases for 'pick',
'edit' and 'squash', but one could know it only by reading the source
code. If a user rebases a lot, it's quite handy, so mention these short
forms as well.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the upstream argument to rebase (the first argument) was relative to
HEAD and the name of the branch to rebase (the second argument) was given,
the upstream would have been interpreted relative to the second argument.
In particular, this command
git rebase -i HEAD topic
would always finish with "Nothing to do". (a1bf91e fixed the same issue
for non-interactive rebase.)
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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>
On hitting an edit point in an interactive rebase, git should prompt
the user to run "git rebase --continue"
Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The command repeats "Rebasing (1/1)" many times even when
there is only one task remaining, because mark_action_done() is
called to skip comment and empty lines in the TODO file.
This should fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After replaying a single change, the code performed a number of checks,
but some of them were for sanity checking, failures from which should
make the command abort, and others were checks to see if it should make
a new commit object. Stringing them together with "&&" was wrong.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The commit message template when squashing multiple commits is
prepared by concatenating the messages of existing commits
together. If the messages from some of them end with incomplete
lines, this would result in a suboptimal message template. Make
sure that we add a terminating LF after each commit message.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
During git-rebase --interactive's --continue implementation we used
to silently restart the rebase if the user had made the commit
for us. This is common if the user stops to edit a commit and
does so by amending it. My recent change to watch git-commit's
exit status broke this behavior.
Thanks to Bernt Hansen for catching it in 1.5.4-rc1.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If git-commit fails for any reason then git-rebase needs to stop
and not plow through the rest of the series. Its unlikely that
a future git-commit will succeed if the current attempt failed.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we are rebasing changes that contain potential whitespace
errors that our .git/hooks/pre-commit hook looks for and fails
on then git-commit will fail to commit that change. This causes
git-rebase--interactive to squash commits together, even though it
was not requested to do so by the todo file.
Passing --no-verify to git-commit makes git-rebase -i behave more
like git-rebase normally would in such conditions, providing more
consistent behavior between the different rebase implementations.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
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>
A Porcelain command that uses cherry-pick or revert may make a commit
out of resolved index itself, in which case telling the user to commit
the result is not appropriate at all. This allows GIT_CHERRY_PICK_HELP
environment variable to be set by the calling Porcelain in order to
override the built-in help text.
[jc: this is heavily modified from the original but should be equivalent
in spirit]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Like non-interactive rebase, interactive mode now calls rerere when
appropriate.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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>
[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>
* ph/parseopt-sh:
git-quiltimport.sh fix --patches handling
git-am: -i does not take a string parameter.
sh-setup: don't let eval output to be shell-expanded.
git-sh-setup: fix parseopt `eval` string underquoting
Give git-am back the ability to add Signed-off-by lines.
git-rev-parse --parseopt
scripts: Add placeholders for OPTIONS_SPEC
Migrate git-repack.sh to use git-rev-parse --parseopt
Migrate git-quiltimport.sh to use git-rev-parse --parseopt
Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-dashdash
Migrate git-instaweb.sh to use git-rev-parse --parseopt
Migrate git-merge.sh to use git-rev-parse --parseopt
Migrate git-am.sh to use git-rev-parse --parseopt
Migrate git-clone to use git-rev-parse --parseopt
Migrate git-clean.sh to use git-rev-parse --parseopt.
Update git-sh-setup(1) to allow transparent use of git-rev-parse --parseopt
Add a parseopt mode to git-rev-parse to bring parse-options to shell scripts.
* maint:
Start preparing for 1.5.3.6
git-send-email: Change the prompt for the subject of the initial message.
SubmittingPatches: improve the 'Patch:' section of the checklist
instaweb: Minor cleanups and fixes for potential problems
stop t1400 hiding errors in tests
Makefile: add missing dependency on wt-status.h
refresh_index_quietly(): express "optional" nature of index writing better
Fix sed string regex escaping in module_name.
Avoid a few unportable, needlessly nested "...`...".
git-mailsplit: with maildirs not only process cur/, but also new/
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>
* maint:
Update GIT 1.5.3.5 Release Notes
git-rebase--interactive.sh: Make 3-way merge strategies work for -p.
git-rebase--interactive.sh: Don't pass a strategy to git-cherry-pick.
Fix --strategy parsing in git-rebase--interactive.sh
Make merge-recursive honor diff.renamelimit
cherry-pick/revert: more compact user direction message
core-tutorial: Use new syntax for git-merge.
git-merge: document but discourage the historical syntax
Prevent send-pack from segfaulting (backport from 'master')
Documentation/git-cvsexportcommit.txt: s/mgs/msg/ in example
Conflicts:
git-rebase--interactive.sh
git-rebase--interactive.sh used to pass all parents of a merge commit to
git-merge, which means that we have at least 3 heads to merge: HEAD,
first parent and second parent. So 3-way merge strategies like recursive
wouldn't work.
Fortunately, we have checked out the first parent right before the merge
anyway, so that is HEAD. Therefore we can drop simply it from the list
of parents, making 3-way strategies work for merge commits with only
two parents.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-cherry-pick doesn't support a strategy paramter, so don't pass one.
This means that --strategy for interactive rebases is a no-op for
anything but merge commits, but that's still better than being broken. A
correct fix would probably need to port the --merge behaviour from plain
git-rebase.sh, but I have no clue how to integrate that cleanly.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For the --strategy/-s option, git-rebase--interactive.sh dropped the
parameter which it was trying to parse.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If /bin/sh is /bin/dash, then the script will display an error if
$parent_sha1 is undefined. This patch works fixes the issue by
quoting both arguments to `test'. Arguments composed solely of
variable expansions should always be quoted, unless we know for
certain that the contents are defined.
Signed-off-by: Michael W. Olson <mwolson@gnu.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When diff drivers are installed, calling "git diff <tree1>..<tree2>"
calls those drivers. This borks the patch generation of rebase -i.
So use "git diff-tree -p" instead, which does not call diff drivers.
Noticed by Johannes Sixt.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* jc/autogc:
git-gc --auto: run "repack -A -d -l" as necessary.
git-gc --auto: restructure the way "repack" command line is built.
git-gc --auto: protect ourselves from accumulated cruft
git-gc --auto: add documentation.
git-gc --auto: move threshold check to need_to_gc() function.
repack -A -d: use --keep-unreachable when repacking
pack-objects --keep-unreachable
Export matches_pack_name() and fix its return value
Invoke "git gc --auto" from commit, merge, am and rebase.
Implement git gc --auto
* maint:
git-remote: exit with non-zero status after detecting errors.
rebase -i: squash should retain the authorship of the _first_ commit
git-add--interactive: Improve behavior on bogus input
git-add--interactive: Allow Ctrl-D to exit
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>
When you do many rebases, you can get annoyed by having to type out
the actions "edit" or "squash" in total.
This commit helps that, by allowing you to enter "e" instead of "edit",
"p" instead of "pick", or "s" instead of "squash".
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>
* jc/autogc:
git-gc --auto: run "repack -A -d -l" as necessary.
git-gc --auto: restructure the way "repack" command line is built.
git-gc --auto: protect ourselves from accumulated cruft
git-gc --auto: add documentation.
git-gc --auto: move threshold check to need_to_gc() function.
repack -A -d: use --keep-unreachable when repacking
pack-objects --keep-unreachable
Export matches_pack_name() and fix its return value
Invoke "git gc --auto" from commit, merge, am and rebase.
Implement git gc --auto
Conflicts:
builtin-pack-objects.c
Creating .dotest-merge before validating the options prevents both
--continue and --interactive from working if the options are invalid,
so only create it after validating the options.
[jc: however, just moving the creation of DOTEST breaks output]
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is somewhat unsafe to export the GIT_AUTHOR_* variables, since a later
call to git-commit or git-merge could pick them up inadvertently.
So avoid the export, using a recipe provided by Johannes Sixt.
Incidentally, this fixes authorship of merges with "rebase --preserve -i".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of counting all lines in done and todo, we now count the actions
before outputting "$Rebasing ($count/$total)".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch indents ";;" consistently with the rest of git's shell scripts,
and makes sure that ";;" are before each "esac".
It introduces a helper function "has_action", to make it easier to read
the intentions of the code.
Errors from "git rev-parse --verify" are no longer ignored.
Spaces are quoted using single quotes instead of a backslash, for
readability.
A "test $preserve=f" (missing spaces) was fixed; hashes are no longer
written to "$DOTEST"/rewritten/ unnecessarily.
We used to quote the message for a squash, only to have "echo" unquote it.
Now we use "printf" and do not need to quote to start with.
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>
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>
The point of auto gc is to pack new objects created in loose
format, so a good rule of thumb is where we do update-ref after
creating a new commit.
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>
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 using emacsclient or similar, a temporary buffer (file) named
'todo' could cause confusion with a pre-existing buffer of the same
name.
Signed-off-by: Seth Falcon <sethfalcon@gmail.com>
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>
When squashing, you no longer saw what the editor had to say to you
after commit 'Shut "git rebase -i" up when no --verbose was given'
(if you used a console based editor, at least).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch is literally
:%s/if \[ *\(.*[^ ]\) *\]/if test \1/
in vi, after making sure that the other instances of "[..]" are not
actually invocations of "test".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Up to now, git rebase -i was quite chatty, showing through all the
nice core programs it called.
Now it only shows a progress meter by default.
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>
These variables let you specify an editor that will be launched in
preference to the EDITOR and VISUAL environment variables. The order
of preference is GIT_EDITOR, core.editor, EDITOR, VISUAL.
[jc: added a test and config variable documentation]
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this change the commits will be left standalone, with
duplicated commit message.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It seems that not everybody expects a difference between keeping a "pick"
line, and deleting it. So be a bit more explicit about that, with all
capitals to get the attention.
Noticed by vmiklos on IRC.
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>
The "while" loop in the function do_rest is not supposed to ever be
exited. Instead, the function do_one checks if there is nothing left,
and cleans up and exits if that is the case. So the diffstat code
belongs there.
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>
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>
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>
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>
