'git rebase' uses 'git merge' to preserve merges (-p). This preserves
the original merge commit correctly, except when the original merge
commit was created by 'git merge --no-ff'. In this case, 'git rebase'
will fail to preserve the merge, because during 'git rebase', 'git
merge' will simply fast-forward and skip the commit. For example:
B
/ \
A---M
/
---o---O---P---Q
If we try to rebase M onto P, we lose the merge commit and this happens:
A---B
/
---o---O---P---Q
To correct this, we simply do a "no fast-forward" on all merge commits
when rebasing. Since by the time we decided to do a 'git merge' inside
'git rebase', it means there was a merge originally, so 'git merge'
should always create a merge commit regardless of what the merge
branches look like. This way, when rebase M onto P from the above
example, we get:
B
/ \
A---M
/
---o---O---P---Q
Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
rebase -i: clarify in-editor documentation of "exec"
tests: sanitize more git environment variables
fast-import: treat filemodify with empty tree as delete
rebase: give a better error message for bogus branch
rebase: use explicit "--" with checkout
Conflicts:
t/t9300-fast-import.sh
The hints in the current "instruction sheet" template look like so:
# Rebase 3f14246..a1d7e01 onto 3f14246
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x <cmd>, exec <cmd> = Run a shell command <cmd>, and stop if it fails
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#
This does not make it clear that the format of each line is
<insn> <commit id> <explanatory text that will be printed>
but the reader will probably infer that from the automatically
generated pick examples above it.
What about the "exec" instruction? By analogy, I might imagine that
the format of that line is "exec <command> <explanatory text>", and
the "x <cmd>" hint does not address that question (at first I read it
as taking an argument <cmd> that is the name of a shell). Meanwhile,
the mention of <cmd> makes the hints harder to scan as a table.
So remove the <cmd> and add some words to remind the reader that
"exec" runs a command named by the rest of the line. To make room, it
is left to the manpage to explain that that command is run using
$SHELL and that nonzero status from that command will pause the
rebase.
Wording from Junio.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
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>
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>
Support lines of the form "fixup! 7a235b" that specify an exact commit
in addition to the normal "squash! Old commit message" form.
Signed-off-by: Kevin Ballard <kevin@sb.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current behvaior of --autosquash can duplicate fixup!/squash! lines
if they match multiple commits, and it can also apply them to commits
that come after them in the todo list. Even more oddly, a commit that
looks like "fixup! fixup!" will match itself and be duplicated in the
todo list.
Change the todo list rearranging to mark all commits as used as soon
as they are emitted, and to avoid emitting a fixup/squash commit if the
commit has already been marked as used.
Signed-off-by: Kevin Ballard <kevin@sb.org>
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>
Some versions of cut do not cope well with lines that do not end in
an LF. In this case, we can completely avoid cut by using the
${var%% *} parameter expansion (suggested by Brandon Casey).
I found this problem when t3404's "avoid unnecessary reset" failed
due to the "rebase -i" not avoiding updating the tested timestamp.
On a Mac OS X 10.4.11 system:
% printf '%s' 'foo bar' | /usr/bin/cut -d ' ' -f 1
cut: stdin: Illegal byte sequence
Signed-off-by: Chris Johnsen <chris_johnsen@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jn/cherry-revert-message-clean-up:
tests: fix syntax error in "Use advise() for hints" test
cherry-pick/revert: Use advise() for hints
cherry-pick/revert: Use error() for failure message
Introduce advise() to print hints
Eliminate “Finished cherry-pick/revert” message
t3508: add check_head_differs_from() helper function and use it
revert: improve success message by adding abbreviated commit sha1
revert: don't print "Finished one cherry-pick." if commit failed
revert: refactor commit code into a new run_git_commit() function
revert: report success when using option --strategy
* mm/rebase-i-exec:
git-rebase--interactive.sh: use printf instead of echo to print commit message
git-rebase--interactive.sh: rework skip_unnecessary_picks
test-lib: user-friendly alternatives to test [-d|-f|-e]
rebase -i: add exec command to launch a shell command
Conflicts:
git-rebase--interactive.sh
t/t3404-rebase-interactive.sh
When cherry-pick fails after picking a large series of commits, it can
be hard to pick out the error message and advice. Prefix the advice
with “hint: ” to help.
Before:
error: could not apply 7ab78c9... foo
After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>'
and commit the result with:
git commit -c 7ab78c9a7898b87127365478431289cb98f8d98f
After:
error: could not apply 7ab78c9... foo
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit -c 7ab78c9'
Noticed-by: Thomas Rast <trast@student.ethz.ch>
Encouraged-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Replace the echo statements that operate on $rest with printf's to restore
what was lost from 938791cd. This avoids any mangling that XSI-conformant
echo's may introduce.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit cd035b1c introduced the exec command to interactive rebase. In
doing so, it modified the way that skip_unnecessary_picks iterates through
the list of rebase commands so that it avoided collapsing multiple spaces
into a single space. This is necessary for example if the argument to the
exec command contains a path with multiple spaces in it.
The way it did this was by reading each line of rebase commands into a
single variable, and then breaking the individual components out using
echo, sed, and cut. It used the individual broken-out components for
decision making, and was still able to write the original line to the
output file from the variable it had saved it in. But, since we only
really need to look at anything other than the first element of the line
when a 'pick' command is encountered, and even that is only necessary when
we are still searching for "unnecessary" picks, and since newer rebase
commands like 'exec' may not even require a sha1 field, let's make our read
statement parse its input into a "command" variable, and a "rest" variable,
and then only break out the sha1 from $rest, and call git-rev-parse, when
absolutely necessary.
I think this future proofs this subroutine, avoids calling git-rev-parse
unnecessarily, and possibly with bogus arguments, and still accomplishes
the goal of not mangling the $rest of the rebase command.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The typical usage pattern would be to run a test (or simply a compilation
command) at given points in history.
The shell command is ran (from the worktree root), and the rebase is
stopped when the command fails, to give the user an opportunity to fix
the problem before continuing with "git rebase --continue".
This needs a little rework of skip_unnecessary_picks, which wasn't robust
enough to deal with lines like
exec >"file name with many spaces"
in the todolist. The new version extracts command, sha1 and rest from
each line, but outputs the line itself verbatim to avoid changing the
whitespace layout.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On systems with an echo which defaults to the XSI-conformant behavior
(Solaris, or others using Ksh), echo will interpret certain backslashed
characters as control sequences. This can cause a problem for interactive
rebase when it is used to rebase commits whose commit "subject" (the first
line) contains any of these backslashed sequences. In this case, echo will
substitute the control sequence for the backslashed characters and either
the rebased commit message will differ from the original, or the rebase
process will fail. Neither is desirable.
So work around this issue by replacing the echo statements used to print
out portions of the commit message, with printf.
Also, add a test to test for this breakage.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you use this feature regularly you can now enable it by default. In
case the user wants to override this config on the commandline
--no-autosquash can be used to force disabling.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Case arms should align with "case" and "esac".
Do not cat a file into a pipeline; just make the downstream command
read from the file.
Having a while statement as a downstream of a pipe is fine, but
the loop should begin on its own line.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Untracked content in the working tree may prevent rebase -i from checking out
the new base onto which it wants to replay commits, if the new base commit
includes files at those (now untracked) paths. Currently, rebase -i dies
uncleanly in this situation, updating ORIG_HEAD and leaving a useless
.git/rebase-merge directory, with which the user can do nothing useful except
rebase --abort. Make rebase -i abort the procedure itself instead, as
non-interactive rebase already does, and add a test for this behavior.
Signed-off-by: Ian Ward Comfort <icomfort@stanford.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you do a "rebase -i" and don't change any commits,
nothing is rewritten, and we have no REWRITTEN_LIST. The
shell prints out an ugly message:
$ GIT_EDITOR=true git rebase -i HEAD^
/path/to/git-rebase--interactive: 1: cannot open
/path/to/repo/.git/rebase-merge/rewritten-list: No such file
Successfully rebased and updated refs/heads/master.
We can fix it by not running "notes copy" at all if nothing
was rewritten.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cc/cherry-pick-ff:
revert: fix tiny memory leak in cherry-pick --ff
rebase -i: use new --ff cherry-pick option
Documentation: describe new cherry-pick --ff option
cherry-pick: add tests for new --ff option
revert: add --ff option to allow fast forward when cherry-picking
builtin/merge: make checkout_fast_forward() non static
parse-options: add parse_options_concat() to concat options
The post-rewrite support, in the form of the call to
'record_in_rewritten', was hidden in the arm where we have to record a
new commit for the user. This meant that it was never invoked in the
case where the user has already amended the commit by herself.
[The test is designed to exercise both arms of the 'if' in question.]
Furthermore, recording the stopped-sha (the SHA1 of the commit before
the editing) suffered from a cut&paste error from die_with_patch and
used the wrong variable, hence it never recorded anything.
Noticed by Junio.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tr/notes-display:
git-notes(1): add a section about the meaning of history
notes: track whether notes_trees were changed at all
notes: add shorthand --ref to override GIT_NOTES_REF
commit --amend: copy notes to the new commit
rebase: support automatic notes copying
notes: implement helpers needed for note copying during rewrite
notes: implement 'git notes copy --stdin'
rebase -i: invoke post-rewrite hook
rebase: invoke post-rewrite hook
commit --amend: invoke post-rewrite hook
Documentation: document post-rewrite hook
Support showing notes from more than one notes tree
test-lib: unset GIT_NOTES_REF to stop it from influencing tests
Conflicts:
git-am.sh
refs.c
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>
git rebase allows you to specify a non-branch commit-ish as the "branch"
argument, which leaves HEAD detached when it's finished. This is
occasionally useful, and this patch brings the same functionality to git
rebase --interactive.
Signed-off-by: Dave Olszewski <cxreg@pobox.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>
Aside from the same issue that rebase also has (remembering the
original commit across a conflict resolution), rebase -i brings an
extra twist: We need to defer writing the rewritten list in the case
of {squash,fixup} because their rewritten result should be the last
commit in the squashed group.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The rough structure of run_rewrite_hook() comes from
run_receive_hook() in receive-pack.
We introduce a --no-post-rewrite option and use it to avoid the hook
when called from git-rebase -i 'edit'. The next patch will add full
support in git-rebase, and we only want to invoke the hook once.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Bash (4.0.24) on OpenBSD 4.6 refuses to run this snippet:
$ cat gomi.sh
#!/bin/sh
one="/var/tmp/1 1"
rm -f /var/tmp/1 "/var/tmp/1 1"
echo hello >$one
$ sh gomi.sh; ls /var/tmp/1*
/var/tmp/1 1
$ bash gomi.sh; ls /var/tmp/1*
gomi.sh: line 4: $one: ambiguous redirect
ls: /var/tmp/1*: No such file or directory
Every competent shell programmer knows that a <$word in redirection is not
subject to field splitting (POSIX.1 "2.7 Redirection" explicitly lists the
kind of expansion performed: "... the word that follows the redirection
operator shall be subjected to ...", and "Field Splitting" is not among
them).
Some clueless folks apparently decided that users need to be protected in
the name of "security", however.
Output from "git grep -e '> *\$' -- '*.sh'" indicates that rebase-i
suffers from this bogus "safety". Work it around by surrounding the
variable reference with a dq pair.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Using a dollar sign in double quotes isn't portable. Escape them with
a backslash or replace the double quotes with single quotes.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is no point doing self-assignments of these variables. Instead,
just export them to the environment, but do so in a sub-shell, because
VAR1=VAL1 VAR2=VAL2 ... command arg1 arg2...
does not mark the variables exported if command that is run
is a shell function, according to POSIX.1.
The callers of do_with_author do not rely on seeing the effect of any
shell variable assignments that may happen inside what was called through
this shell function (currently "output" is the only one), so running it in
the subshell doesn't have an adverse semantic effect.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mh/rebase-fixup:
rebase -i: Retain user-edited commit messages after squash/fixup conflicts
t3404: Set up more of the test repo in the "setup" step
rebase -i: For fixup commands without squashes, do not start editor
rebase -i: Change function make_squash_message into update_squash_message
rebase -i: Extract function do_with_author
rebase -i: Handle the author script all in one place in do_next
rebase -i: Extract a function "commit_message"
rebase -i: Simplify commit counting for generated commit messages
rebase -i: Improve consistency of commit count in generated commit messages
t3404: Test the commit count in commit messages generated by "rebase -i"
rebase -i: Introduce a constant AMEND
rebase -i: Introduce a constant AUTHOR_SCRIPT
rebase -i: Document how temporary files are used
rebase -i: Use symbolic constant $MSG consistently
rebase -i: Use "test -n" instead of "test ! -z"
rebase -i: Inline expression
rebase -i: Remove dead code
rebase -i: Make the condition for an "if" more transparent
* 'mh/rebase-fixup' (early part):
rebase-i: Ignore comments and blank lines in peek_next_command
lib-rebase: Allow comments and blank lines to be added to the rebase script
lib-rebase: Provide clearer debugging info about what the editor did
Add a command "fixup" to rebase --interactive
t3404: Use test_commit to set up test repository
When a squash/fixup fails due to a conflict, the user is required to
edit the commit message. Previously, if further squash/fixup commands
followed the conflicting squash/fixup, this user-edited message was
discarded and a new automatically-generated commit message was
suggested.
Change the handling of conflicts within squash/fixup command series:
Whenever the user is required to intervene, consider the resulting
commit to be a new basis for the following squash/fixups and use its
commit message in later suggested combined commit messages.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the "rebase -i" commands include a series of fixup commands without
any squash commands, then commit the combined commit using the commit
message of the corresponding "pick" without starting up the
commit-message editor.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Alter the file $SQUASH_MSG in place rather than outputting the new
message then juggling it around. Change the function name
accordingly.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Call it instead of repeating similar code blocks in several places.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This change has no practical effect but makes the code easier to
follow.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
...instead of repeating the same short but slightly obscure blob of
code in several places.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Read the old count from the first line of the old commit message
rather than counting the number of commit message blocks in the file.
This is simpler, faster, and more robust (e.g., it cannot be confused
by strange commit message contents).
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use the numeral "2" instead of the word "two" when two commits are
being interactively squashed. This makes the treatment consistent
with that for higher numbers of commits.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
