1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-01 14:57:52 +01:00
Commit graph

13 commits

Author SHA1 Message Date
Ralf Thielow
a9f739c111 rebase --preserve-merges: ignore "merge.log" config
When "merge.log" config is set, "rebase --preserve-merges" will add
the log lines to the message of the rebased merge commit.  A rebase
should not modify a commit message automatically.

Teach "git-rebase" to ignore that configuration by passing
"--no-log" to the git-merge call.

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-21 15:44:15 -07:00
Martin von Zweigbergk
3f213981e4 add tests for rebasing merged history
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-07 09:41:59 -07:00
Andrew Wong
12bf828348 rebase -i -p: include non-first-parent commits in todo list
Consider this graph:

        D---E    (topic, HEAD)
       /   /
  A---B---C      (master)
   \
    F            (topic2)

and the following three commands:
  1. git rebase -i -p A
  2. git rebase -i -p --onto F A
  3. git rebase -i -p B

Currently, (1) and (2) will pick B, D, C, and E onto A and F,
respectively.  However, (3) will only pick D and E onto B, but not C,
which is inconsistent with (1) and (2).  As a result, we cannot modify C
during the interactive-rebase.

The current behavior also creates a bug if we do:
  4. git rebase -i -p C

In (4), E is never picked.  And since interactive-rebase resets "HEAD"
to "onto" before picking any commits, D and E are lost after the
interactive-rebase.

This patch fixes the inconsistency and bug by ensuring that all children
of upstream are always picked.  This essentially reverts the commit:
  d80d6bc146

When compiling the todo list, commits reachable from "upstream" should
never be skipped under any conditions.  Otherwise, we lose the ability
to modify them like (3), and create a bug like (4).

Two of the tests contain a scenario like (3).  Since the new behavior
added more commits for picking, these tests need to be updated to
account for the additional pick lines.  A new test has also been added
for (4).

Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-19 14:37:23 -07:00
Andrew Wong
c192f9c865 git-rebase--interactive.sh: preserve-merges fails on merges created with no-ff
'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>
2011-04-28 09:56:55 -07:00
Matthieu Moy
13931236b9 Change incorrect "remote branch" to "remote tracking branch" in C code
(Just like we did for documentation already)

In the process, we change "non-remote branch" to "branch outside the
refs/remotes/ hierarchy" to avoid the ugly "non-remote-tracking branch".
The new formulation actually corresponds to how the code detects this
case (i.e. prefixcmp(refname, "refs/remotes")).

Also, we use 'remote-tracking branch' in generated merge messages (by
merge an fmt-merge-msg).

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-03 09:20:47 -07:00
Jonathan Nieder
18a8269242 tests: subshell indentation stylefix
Format the subshells introduced by the previous patch (Several tests:
cd inside subshell instead of around, 2010-09-06) like so:

	(
		cd subdir &&
		...
	) &&

This is generally easier to read and has the nice side-effect that
this patch will show what commands are used in the subshell, making
it easier to check for lost environment variables and similar
behavior changes.

Cc: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-09 15:56:20 -07:00
Jens Lehmann
fd4ec4f2bb Several tests: cd inside subshell instead of around
Fixed all places where it was a straightforward change from cd'ing into a
directory and back via "cd .." to a cd inside a subshell.

Found these places with "git grep -w "cd \.\.".

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-06 14:30:53 -07:00
Matthew Ogilvie
5d59a4016b t3409 t4107 t7406 t9150: use dashless commands
This is needed to allow test suite to run against a standard
install bin directory instead of GIT_EXEC_PATH.

Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-29 23:09:47 -08:00
Jeff King
69a8b7c741 merge: indicate remote tracking branches in merge message
Previously when merging directly from a local tracking
branch like:

  git merge origin/master

The merge message said:

   Merge commit 'origin/master'

     * commit 'origin/master':
       ...

Instead, let's be more explicit about what we are merging:

   Merge remote branch 'origin/master'

     * origin/master:
       ...

We accomplish this by recognizing remote tracking branches
in git-merge when we build the simulated FETCH_HEAD output
that we feed to fmt-merge-msg.

In addition to a new test in t7608, we have to tweak the
expected output of t3409, which does such a merge.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-09 12:34:21 -07:00
Johannes Schindelin
4fb1a19d50 rebase -i -p: leave a --cc patch when a merge could not be redone
The result is easier to review this way, and the merge resolution has to be
done inside the work tree, not by adjusting "the patch" anyway.
2008-12-24 00:14:08 -08:00
Johannes Sixt
f5b49ea619 rebase -i -p: Fix --continue after a merge could not be redone
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>
2008-12-21 01:08:51 -08:00
Johannes Sixt
03c4829347 Show a failure of rebase -p if the merge had a conflict
This extends t3409-rebase-preserve-merges by a case where the merge that
is rebased has a conflict. Therefore, the rebase stops and expects that
the user resolves the conflict. However, currently rebase --continue
fails because .git/rebase-merge/author-script is missing.

The test script had allocated two identical clones, but only one of them
(clone2) was used. Now we use both as indicated in the comment. Also,
two instances of && was missing in the setup part.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-21 01:08:37 -08:00
Andreas Ericsson
f8cca019b9 rebase: Support preserving merges in non-interactive mode
As a result of implementation details, 'git rebase' could
previously only preserve merges in interactive mode. That
limitation was hard for users to understand and awkward to
explain.

This patch works around it by running the interactive rebase
helper git-rebase--interactive with GIT_EDITOR set to ':'
when the user passes "-p" but not "-i" to the rebase command.
The effect is that the interactive rebase helper is used but
the user never sees an editor.

The test-case included in this patch was originally written
by Stephen Habermann <stephen@exigencecorp.com>, but has
been extensively modified since its creation.

Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-09-30 15:34:52 -07:00