Commit Graph

116 Commits

Author SHA1 Message Date
Junio C Hamano
2af89f12c6 Merge branch 'maint'
* 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
2007-09-29 23:32:36 -07:00
Johannes Schindelin
81ab1cb43a rebase -i: squash should retain the authorship of the _first_ commit
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>
2007-09-29 23:16:08 -07:00
Johannes Schindelin
73697a0b57 rebase -i: work on a detached HEAD
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>
2007-09-26 00:42:17 -07:00
Johannes Schindelin
be6ff208d8 rebase -i: commit when continuing after "edit"
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>
2007-09-25 17:46:43 -07:00
Johannes Schindelin
1d25c8cf82 rebase -i: fix squashing corner case
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>
2007-08-23 02:34:19 -07:00
Junio C Hamano
77b258f436 t3404: fix "fake-editor"
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>
2007-08-13 12:58:38 -07:00
Johannes Schindelin
c9e6589288 rebase -i: fix for optional [branch] parameter
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>
2007-08-01 18:17:56 -07:00
Johannes Schindelin
96ffe892e3 rebase -i: ignore patches that are already in the upstream
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>
2007-08-01 17:56:28 -07:00
Johannes Schindelin
fb47cfbd59 rebase -i: fix interrupted squashing
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>
2007-07-27 10:59:42 -07:00
Johannes Schindelin
6368f3f8e7 rebase -i: call editor just once for a multi-squash
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>
2007-07-21 16:04:13 -07:00
Johannes Schindelin
8e4a91bd78 rebase -i: remember the settings of -v, -s and -p when interrupted
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>
2007-07-08 18:24:19 -07:00
Johannes Schindelin
18640d991b rebase -i: handle --continue more like non-interactive rebase
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>
2007-07-08 18:24:19 -07:00
Johannes Schindelin
f09c9b8c5f Teach rebase -i about --preserve-merges
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>
2007-06-26 18:58:59 -07:00
Johannes Schindelin
68a163c9b4 rebase -i: provide reasonable reflog for the rebased branch
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>
2007-06-26 18:58:59 -07:00
Johannes Schindelin
c54b7817f4 rebase -i: several cleanups
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>
2007-06-26 18:58:45 -07:00
Johannes Schindelin
1b1dce4bae Teach rebase an interactive mode
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>
2007-06-24 17:45:02 -07:00