rebase: introduce the --rebase-merges option
Once upon a time, this here developer thought: wouldn't it be nice if,
say, Git for Windows' patches on top of core Git could be represented as
a thicket of branches, and be rebased on top of core Git in order to
maintain a cherry-pick'able set of patch series?
The original attempt to answer this was: git rebase --preserve-merges.
However, that experiment was never intended as an interactive option,
and it only piggy-backed on git rebase --interactive because that
command's implementation looked already very, very familiar: it was
designed by the same person who designed --preserve-merges: yours truly.
Some time later, some other developer (I am looking at you, Andreas!
;-)) decided that it would be a good idea to allow --preserve-merges to
be combined with --interactive (with caveats!) and the Git maintainer
(well, the interim Git maintainer during Junio's absence, that is)
agreed, and that is when the glamor of the --preserve-merges design
started to fall apart rather quickly and unglamorously.
The reason? In --preserve-merges mode, the parents of a merge commit (or
for that matter, of *any* commit) were not stated explicitly, but were
*implied* by the commit name passed to the `pick` command.
This made it impossible, for example, to reorder commits. Not to mention
to move commits between branches or, deity forbid, to split topic branches
into two.
Alas, these shortcomings also prevented that mode (whose original
purpose was to serve Git for Windows' needs, with the additional hope
that it may be useful to others, too) from serving Git for Windows'
needs.
Five years later, when it became really untenable to have one unwieldy,
big hodge-podge patch series of partly related, partly unrelated patches
in Git for Windows that was rebased onto core Git's tags from time to
time (earning the undeserved wrath of the developer of the ill-fated
git-remote-hg series that first obsoleted Git for Windows' competing
approach, only to be abandoned without maintainer later) was really
untenable, the "Git garden shears" were born [*1*/*2*]: a script,
piggy-backing on top of the interactive rebase, that would first
determine the branch topology of the patches to be rebased, create a
pseudo todo list for further editing, transform the result into a real
todo list (making heavy use of the `exec` command to "implement" the
missing todo list commands) and finally recreate the patch series on
top of the new base commit.
That was in 2013. And it took about three weeks to come up with the
design and implement it as an out-of-tree script. Needless to say, the
implementation needed quite a few years to stabilize, all the while the
design itself proved itself sound.
With this patch, the goodness of the Git garden shears comes to `git
rebase -i` itself. Passing the `--rebase-merges` option will generate
a todo list that can be understood readily, and where it is obvious
how to reorder commits. New branches can be introduced by inserting
`label` commands and calling `merge <label>`. And once this mode will
have become stable and universally accepted, we can deprecate the design
mistake that was `--preserve-merges`.
Link *1*:
https://github.com/msysgit/msysgit/blob/master/share/msysGit/shears.sh
Link *2*:
https://github.com/git-for-windows/build-extra/blob/master/shears.sh
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 14:29:04 +02:00
|
|
|
#!/bin/sh
|
|
|
|
|
#
|
|
|
|
|
# Copyright (c) 2018 Johannes E. Schindelin
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
test_description='git rebase -i --rebase-merges
|
|
|
|
|
|
|
|
|
|
This test runs git rebase "interactively", retaining the branch structure by
|
|
|
|
|
recreating merge commits.
|
|
|
|
|
|
|
|
|
|
Initial setup:
|
|
|
|
|
|
|
|
|
|
-- B -- (first)
|
|
|
|
|
/ \
|
|
|
|
|
A - C - D - E - H (master)
|
2018-08-15 11:39:34 +02:00
|
|
|
\ \ /
|
|
|
|
|
\ F - G (second)
|
|
|
|
|
\
|
|
|
|
|
Conflicting-G
|
rebase: introduce the --rebase-merges option
Once upon a time, this here developer thought: wouldn't it be nice if,
say, Git for Windows' patches on top of core Git could be represented as
a thicket of branches, and be rebased on top of core Git in order to
maintain a cherry-pick'able set of patch series?
The original attempt to answer this was: git rebase --preserve-merges.
However, that experiment was never intended as an interactive option,
and it only piggy-backed on git rebase --interactive because that
command's implementation looked already very, very familiar: it was
designed by the same person who designed --preserve-merges: yours truly.
Some time later, some other developer (I am looking at you, Andreas!
;-)) decided that it would be a good idea to allow --preserve-merges to
be combined with --interactive (with caveats!) and the Git maintainer
(well, the interim Git maintainer during Junio's absence, that is)
agreed, and that is when the glamor of the --preserve-merges design
started to fall apart rather quickly and unglamorously.
The reason? In --preserve-merges mode, the parents of a merge commit (or
for that matter, of *any* commit) were not stated explicitly, but were
*implied* by the commit name passed to the `pick` command.
This made it impossible, for example, to reorder commits. Not to mention
to move commits between branches or, deity forbid, to split topic branches
into two.
Alas, these shortcomings also prevented that mode (whose original
purpose was to serve Git for Windows' needs, with the additional hope
that it may be useful to others, too) from serving Git for Windows'
needs.
Five years later, when it became really untenable to have one unwieldy,
big hodge-podge patch series of partly related, partly unrelated patches
in Git for Windows that was rebased onto core Git's tags from time to
time (earning the undeserved wrath of the developer of the ill-fated
git-remote-hg series that first obsoleted Git for Windows' competing
approach, only to be abandoned without maintainer later) was really
untenable, the "Git garden shears" were born [*1*/*2*]: a script,
piggy-backing on top of the interactive rebase, that would first
determine the branch topology of the patches to be rebased, create a
pseudo todo list for further editing, transform the result into a real
todo list (making heavy use of the `exec` command to "implement" the
missing todo list commands) and finally recreate the patch series on
top of the new base commit.
That was in 2013. And it took about three weeks to come up with the
design and implement it as an out-of-tree script. Needless to say, the
implementation needed quite a few years to stabilize, all the while the
design itself proved itself sound.
With this patch, the goodness of the Git garden shears comes to `git
rebase -i` itself. Passing the `--rebase-merges` option will generate
a todo list that can be understood readily, and where it is obvious
how to reorder commits. New branches can be introduced by inserting
`label` commands and calling `merge <label>`. And once this mode will
have become stable and universally accepted, we can deprecate the design
mistake that was `--preserve-merges`.
Link *1*:
https://github.com/msysgit/msysgit/blob/master/share/msysGit/shears.sh
Link *2*:
https://github.com/git-for-windows/build-extra/blob/master/shears.sh
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 14:29:04 +02:00
|
|
|
'
|
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
. "$TEST_DIRECTORY"/lib-rebase.sh
|
|
|
|
|
|
|
|
|
|
test_cmp_graph () {
|
|
|
|
|
cat >expect &&
|
|
|
|
|
git log --graph --boundary --format=%s "$@" >output &&
|
|
|
|
|
sed "s/ *$//" <output >output.trimmed &&
|
|
|
|
|
test_cmp expect output.trimmed
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test_expect_success 'setup' '
|
|
|
|
|
write_script replace-editor.sh <<-\EOF &&
|
|
|
|
|
mv "$1" "$(git rev-parse --git-path ORIGINAL-TODO)"
|
|
|
|
|
cp script-from-scratch "$1"
|
|
|
|
|
EOF
|
|
|
|
|
|
|
|
|
|
test_commit A &&
|
|
|
|
|
git checkout -b first &&
|
|
|
|
|
test_commit B &&
|
|
|
|
|
git checkout master &&
|
|
|
|
|
test_commit C &&
|
|
|
|
|
test_commit D &&
|
|
|
|
|
git merge --no-commit B &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m E &&
|
|
|
|
|
git tag -m E E &&
|
|
|
|
|
git checkout -b second C &&
|
|
|
|
|
test_commit F &&
|
|
|
|
|
test_commit G &&
|
|
|
|
|
git checkout master &&
|
|
|
|
|
git merge --no-commit G &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m H &&
|
2018-08-15 11:39:34 +02:00
|
|
|
git tag -m H H &&
|
|
|
|
|
git checkout A &&
|
|
|
|
|
test_commit conflicting-G G.t
|
rebase: introduce the --rebase-merges option
Once upon a time, this here developer thought: wouldn't it be nice if,
say, Git for Windows' patches on top of core Git could be represented as
a thicket of branches, and be rebased on top of core Git in order to
maintain a cherry-pick'able set of patch series?
The original attempt to answer this was: git rebase --preserve-merges.
However, that experiment was never intended as an interactive option,
and it only piggy-backed on git rebase --interactive because that
command's implementation looked already very, very familiar: it was
designed by the same person who designed --preserve-merges: yours truly.
Some time later, some other developer (I am looking at you, Andreas!
;-)) decided that it would be a good idea to allow --preserve-merges to
be combined with --interactive (with caveats!) and the Git maintainer
(well, the interim Git maintainer during Junio's absence, that is)
agreed, and that is when the glamor of the --preserve-merges design
started to fall apart rather quickly and unglamorously.
The reason? In --preserve-merges mode, the parents of a merge commit (or
for that matter, of *any* commit) were not stated explicitly, but were
*implied* by the commit name passed to the `pick` command.
This made it impossible, for example, to reorder commits. Not to mention
to move commits between branches or, deity forbid, to split topic branches
into two.
Alas, these shortcomings also prevented that mode (whose original
purpose was to serve Git for Windows' needs, with the additional hope
that it may be useful to others, too) from serving Git for Windows'
needs.
Five years later, when it became really untenable to have one unwieldy,
big hodge-podge patch series of partly related, partly unrelated patches
in Git for Windows that was rebased onto core Git's tags from time to
time (earning the undeserved wrath of the developer of the ill-fated
git-remote-hg series that first obsoleted Git for Windows' competing
approach, only to be abandoned without maintainer later) was really
untenable, the "Git garden shears" were born [*1*/*2*]: a script,
piggy-backing on top of the interactive rebase, that would first
determine the branch topology of the patches to be rebased, create a
pseudo todo list for further editing, transform the result into a real
todo list (making heavy use of the `exec` command to "implement" the
missing todo list commands) and finally recreate the patch series on
top of the new base commit.
That was in 2013. And it took about three weeks to come up with the
design and implement it as an out-of-tree script. Needless to say, the
implementation needed quite a few years to stabilize, all the while the
design itself proved itself sound.
With this patch, the goodness of the Git garden shears comes to `git
rebase -i` itself. Passing the `--rebase-merges` option will generate
a todo list that can be understood readily, and where it is obvious
how to reorder commits. New branches can be introduced by inserting
`label` commands and calling `merge <label>`. And once this mode will
have become stable and universally accepted, we can deprecate the design
mistake that was `--preserve-merges`.
Link *1*:
https://github.com/msysgit/msysgit/blob/master/share/msysGit/shears.sh
Link *2*:
https://github.com/git-for-windows/build-extra/blob/master/shears.sh
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 14:29:04 +02:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'create completely different structure' '
|
|
|
|
|
cat >script-from-scratch <<-\EOF &&
|
|
|
|
|
label onto
|
|
|
|
|
|
|
|
|
|
# onebranch
|
|
|
|
|
pick G
|
|
|
|
|
pick D
|
|
|
|
|
label onebranch
|
|
|
|
|
|
|
|
|
|
# second
|
|
|
|
|
reset onto
|
|
|
|
|
pick B
|
|
|
|
|
label second
|
|
|
|
|
|
|
|
|
|
reset onto
|
|
|
|
|
merge -C H second
|
|
|
|
|
merge onebranch # Merge the topic branch '\''onebranch'\''
|
|
|
|
|
EOF
|
|
|
|
|
test_config sequence.editor \""$PWD"/replace-editor.sh\" &&
|
|
|
|
|
test_tick &&
|
2018-08-15 11:39:34 +02:00
|
|
|
git rebase -i -r A master &&
|
rebase: introduce the --rebase-merges option
Once upon a time, this here developer thought: wouldn't it be nice if,
say, Git for Windows' patches on top of core Git could be represented as
a thicket of branches, and be rebased on top of core Git in order to
maintain a cherry-pick'able set of patch series?
The original attempt to answer this was: git rebase --preserve-merges.
However, that experiment was never intended as an interactive option,
and it only piggy-backed on git rebase --interactive because that
command's implementation looked already very, very familiar: it was
designed by the same person who designed --preserve-merges: yours truly.
Some time later, some other developer (I am looking at you, Andreas!
;-)) decided that it would be a good idea to allow --preserve-merges to
be combined with --interactive (with caveats!) and the Git maintainer
(well, the interim Git maintainer during Junio's absence, that is)
agreed, and that is when the glamor of the --preserve-merges design
started to fall apart rather quickly and unglamorously.
The reason? In --preserve-merges mode, the parents of a merge commit (or
for that matter, of *any* commit) were not stated explicitly, but were
*implied* by the commit name passed to the `pick` command.
This made it impossible, for example, to reorder commits. Not to mention
to move commits between branches or, deity forbid, to split topic branches
into two.
Alas, these shortcomings also prevented that mode (whose original
purpose was to serve Git for Windows' needs, with the additional hope
that it may be useful to others, too) from serving Git for Windows'
needs.
Five years later, when it became really untenable to have one unwieldy,
big hodge-podge patch series of partly related, partly unrelated patches
in Git for Windows that was rebased onto core Git's tags from time to
time (earning the undeserved wrath of the developer of the ill-fated
git-remote-hg series that first obsoleted Git for Windows' competing
approach, only to be abandoned without maintainer later) was really
untenable, the "Git garden shears" were born [*1*/*2*]: a script,
piggy-backing on top of the interactive rebase, that would first
determine the branch topology of the patches to be rebased, create a
pseudo todo list for further editing, transform the result into a real
todo list (making heavy use of the `exec` command to "implement" the
missing todo list commands) and finally recreate the patch series on
top of the new base commit.
That was in 2013. And it took about three weeks to come up with the
design and implement it as an out-of-tree script. Needless to say, the
implementation needed quite a few years to stabilize, all the while the
design itself proved itself sound.
With this patch, the goodness of the Git garden shears comes to `git
rebase -i` itself. Passing the `--rebase-merges` option will generate
a todo list that can be understood readily, and where it is obvious
how to reorder commits. New branches can be introduced by inserting
`label` commands and calling `merge <label>`. And once this mode will
have become stable and universally accepted, we can deprecate the design
mistake that was `--preserve-merges`.
Link *1*:
https://github.com/msysgit/msysgit/blob/master/share/msysGit/shears.sh
Link *2*:
https://github.com/git-for-windows/build-extra/blob/master/shears.sh
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 14:29:04 +02:00
|
|
|
test_cmp_graph <<-\EOF
|
|
|
|
|
* Merge the topic branch '\''onebranch'\''
|
|
|
|
|
|\
|
|
|
|
|
| * D
|
|
|
|
|
| * G
|
|
|
|
|
* | H
|
|
|
|
|
|\ \
|
|
|
|
|
| |/
|
|
|
|
|
|/|
|
|
|
|
|
| * B
|
|
|
|
|
|/
|
|
|
|
|
* A
|
|
|
|
|
EOF
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'generate correct todo list' '
|
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
|
label onto
|
|
|
|
|
|
|
|
|
|
reset onto
|
|
|
|
|
pick d9df450 B
|
|
|
|
|
label E
|
|
|
|
|
|
|
|
|
|
reset onto
|
|
|
|
|
pick 5dee784 C
|
|
|
|
|
label branch-point
|
|
|
|
|
pick ca2c861 F
|
|
|
|
|
pick 088b00a G
|
|
|
|
|
label H
|
|
|
|
|
|
|
|
|
|
reset branch-point # C
|
|
|
|
|
pick 12bd07b D
|
|
|
|
|
merge -C 2051b56 E # E
|
|
|
|
|
merge -C 233d48a H # H
|
|
|
|
|
|
|
|
|
|
EOF
|
|
|
|
|
|
|
|
|
|
grep -v "^#" <.git/ORIGINAL-TODO >output &&
|
|
|
|
|
test_cmp expect output
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success '`reset` refuses to overwrite untracked files' '
|
|
|
|
|
git checkout -b refuse-to-reset &&
|
|
|
|
|
test_commit dont-overwrite-untracked &&
|
|
|
|
|
git checkout @{-1} &&
|
|
|
|
|
: >dont-overwrite-untracked.t &&
|
|
|
|
|
echo "reset refs/tags/dont-overwrite-untracked" >script-from-scratch &&
|
|
|
|
|
test_config sequence.editor \""$PWD"/replace-editor.sh\" &&
|
|
|
|
|
test_must_fail git rebase -r HEAD &&
|
|
|
|
|
git rebase --abort
|
|
|
|
|
'
|
|
|
|
|
|
2018-08-15 11:39:35 +02:00
|
|
|
test_expect_success 'failed `merge -C` writes patch (may be rescheduled, too)' '
|
rebase: introduce the --rebase-merges option
Once upon a time, this here developer thought: wouldn't it be nice if,
say, Git for Windows' patches on top of core Git could be represented as
a thicket of branches, and be rebased on top of core Git in order to
maintain a cherry-pick'able set of patch series?
The original attempt to answer this was: git rebase --preserve-merges.
However, that experiment was never intended as an interactive option,
and it only piggy-backed on git rebase --interactive because that
command's implementation looked already very, very familiar: it was
designed by the same person who designed --preserve-merges: yours truly.
Some time later, some other developer (I am looking at you, Andreas!
;-)) decided that it would be a good idea to allow --preserve-merges to
be combined with --interactive (with caveats!) and the Git maintainer
(well, the interim Git maintainer during Junio's absence, that is)
agreed, and that is when the glamor of the --preserve-merges design
started to fall apart rather quickly and unglamorously.
The reason? In --preserve-merges mode, the parents of a merge commit (or
for that matter, of *any* commit) were not stated explicitly, but were
*implied* by the commit name passed to the `pick` command.
This made it impossible, for example, to reorder commits. Not to mention
to move commits between branches or, deity forbid, to split topic branches
into two.
Alas, these shortcomings also prevented that mode (whose original
purpose was to serve Git for Windows' needs, with the additional hope
that it may be useful to others, too) from serving Git for Windows'
needs.
Five years later, when it became really untenable to have one unwieldy,
big hodge-podge patch series of partly related, partly unrelated patches
in Git for Windows that was rebased onto core Git's tags from time to
time (earning the undeserved wrath of the developer of the ill-fated
git-remote-hg series that first obsoleted Git for Windows' competing
approach, only to be abandoned without maintainer later) was really
untenable, the "Git garden shears" were born [*1*/*2*]: a script,
piggy-backing on top of the interactive rebase, that would first
determine the branch topology of the patches to be rebased, create a
pseudo todo list for further editing, transform the result into a real
todo list (making heavy use of the `exec` command to "implement" the
missing todo list commands) and finally recreate the patch series on
top of the new base commit.
That was in 2013. And it took about three weeks to come up with the
design and implement it as an out-of-tree script. Needless to say, the
implementation needed quite a few years to stabilize, all the while the
design itself proved itself sound.
With this patch, the goodness of the Git garden shears comes to `git
rebase -i` itself. Passing the `--rebase-merges` option will generate
a todo list that can be understood readily, and where it is obvious
how to reorder commits. New branches can be introduced by inserting
`label` commands and calling `merge <label>`. And once this mode will
have become stable and universally accepted, we can deprecate the design
mistake that was `--preserve-merges`.
Link *1*:
https://github.com/msysgit/msysgit/blob/master/share/msysGit/shears.sh
Link *2*:
https://github.com/git-for-windows/build-extra/blob/master/shears.sh
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 14:29:04 +02:00
|
|
|
test_when_finished "test_might_fail git rebase --abort" &&
|
|
|
|
|
git checkout -b conflicting-merge A &&
|
|
|
|
|
|
|
|
|
|
: fail because of conflicting untracked file &&
|
|
|
|
|
>G.t &&
|
|
|
|
|
echo "merge -C H G" >script-from-scratch &&
|
|
|
|
|
test_config sequence.editor \""$PWD"/replace-editor.sh\" &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
test_must_fail git rebase -ir HEAD &&
|
|
|
|
|
grep "^merge -C .* G$" .git/rebase-merge/done &&
|
|
|
|
|
grep "^merge -C .* G$" .git/rebase-merge/git-rebase-todo &&
|
|
|
|
|
test_path_is_file .git/rebase-merge/patch &&
|
|
|
|
|
|
|
|
|
|
: fail because of merge conflict &&
|
|
|
|
|
rm G.t .git/rebase-merge/patch &&
|
2018-08-15 11:39:34 +02:00
|
|
|
git reset --hard conflicting-G &&
|
rebase: introduce the --rebase-merges option
Once upon a time, this here developer thought: wouldn't it be nice if,
say, Git for Windows' patches on top of core Git could be represented as
a thicket of branches, and be rebased on top of core Git in order to
maintain a cherry-pick'able set of patch series?
The original attempt to answer this was: git rebase --preserve-merges.
However, that experiment was never intended as an interactive option,
and it only piggy-backed on git rebase --interactive because that
command's implementation looked already very, very familiar: it was
designed by the same person who designed --preserve-merges: yours truly.
Some time later, some other developer (I am looking at you, Andreas!
;-)) decided that it would be a good idea to allow --preserve-merges to
be combined with --interactive (with caveats!) and the Git maintainer
(well, the interim Git maintainer during Junio's absence, that is)
agreed, and that is when the glamor of the --preserve-merges design
started to fall apart rather quickly and unglamorously.
The reason? In --preserve-merges mode, the parents of a merge commit (or
for that matter, of *any* commit) were not stated explicitly, but were
*implied* by the commit name passed to the `pick` command.
This made it impossible, for example, to reorder commits. Not to mention
to move commits between branches or, deity forbid, to split topic branches
into two.
Alas, these shortcomings also prevented that mode (whose original
purpose was to serve Git for Windows' needs, with the additional hope
that it may be useful to others, too) from serving Git for Windows'
needs.
Five years later, when it became really untenable to have one unwieldy,
big hodge-podge patch series of partly related, partly unrelated patches
in Git for Windows that was rebased onto core Git's tags from time to
time (earning the undeserved wrath of the developer of the ill-fated
git-remote-hg series that first obsoleted Git for Windows' competing
approach, only to be abandoned without maintainer later) was really
untenable, the "Git garden shears" were born [*1*/*2*]: a script,
piggy-backing on top of the interactive rebase, that would first
determine the branch topology of the patches to be rebased, create a
pseudo todo list for further editing, transform the result into a real
todo list (making heavy use of the `exec` command to "implement" the
missing todo list commands) and finally recreate the patch series on
top of the new base commit.
That was in 2013. And it took about three weeks to come up with the
design and implement it as an out-of-tree script. Needless to say, the
implementation needed quite a few years to stabilize, all the while the
design itself proved itself sound.
With this patch, the goodness of the Git garden shears comes to `git
rebase -i` itself. Passing the `--rebase-merges` option will generate
a todo list that can be understood readily, and where it is obvious
how to reorder commits. New branches can be introduced by inserting
`label` commands and calling `merge <label>`. And once this mode will
have become stable and universally accepted, we can deprecate the design
mistake that was `--preserve-merges`.
Link *1*:
https://github.com/msysgit/msysgit/blob/master/share/msysGit/shears.sh
Link *2*:
https://github.com/git-for-windows/build-extra/blob/master/shears.sh
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 14:29:04 +02:00
|
|
|
test_must_fail git rebase --continue &&
|
|
|
|
|
! grep "^merge -C .* G$" .git/rebase-merge/git-rebase-todo &&
|
|
|
|
|
test_path_is_file .git/rebase-merge/patch
|
|
|
|
|
'
|
|
|
|
|
|
2018-08-15 11:39:35 +02:00
|
|
|
SQ="'"
|
|
|
|
|
test_expect_success 'failed `merge <branch>` does not crash' '
|
|
|
|
|
test_when_finished "test_might_fail git rebase --abort" &&
|
|
|
|
|
git checkout conflicting-G &&
|
|
|
|
|
|
|
|
|
|
echo "merge G" >script-from-scratch &&
|
|
|
|
|
test_config sequence.editor \""$PWD"/replace-editor.sh\" &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
test_must_fail git rebase -ir HEAD &&
|
|
|
|
|
! grep "^merge G$" .git/rebase-merge/git-rebase-todo &&
|
|
|
|
|
grep "^Merge branch ${SQ}G${SQ}$" .git/rebase-merge/message
|
|
|
|
|
'
|
|
|
|
|
|
rebase: introduce the --rebase-merges option
Once upon a time, this here developer thought: wouldn't it be nice if,
say, Git for Windows' patches on top of core Git could be represented as
a thicket of branches, and be rebased on top of core Git in order to
maintain a cherry-pick'able set of patch series?
The original attempt to answer this was: git rebase --preserve-merges.
However, that experiment was never intended as an interactive option,
and it only piggy-backed on git rebase --interactive because that
command's implementation looked already very, very familiar: it was
designed by the same person who designed --preserve-merges: yours truly.
Some time later, some other developer (I am looking at you, Andreas!
;-)) decided that it would be a good idea to allow --preserve-merges to
be combined with --interactive (with caveats!) and the Git maintainer
(well, the interim Git maintainer during Junio's absence, that is)
agreed, and that is when the glamor of the --preserve-merges design
started to fall apart rather quickly and unglamorously.
The reason? In --preserve-merges mode, the parents of a merge commit (or
for that matter, of *any* commit) were not stated explicitly, but were
*implied* by the commit name passed to the `pick` command.
This made it impossible, for example, to reorder commits. Not to mention
to move commits between branches or, deity forbid, to split topic branches
into two.
Alas, these shortcomings also prevented that mode (whose original
purpose was to serve Git for Windows' needs, with the additional hope
that it may be useful to others, too) from serving Git for Windows'
needs.
Five years later, when it became really untenable to have one unwieldy,
big hodge-podge patch series of partly related, partly unrelated patches
in Git for Windows that was rebased onto core Git's tags from time to
time (earning the undeserved wrath of the developer of the ill-fated
git-remote-hg series that first obsoleted Git for Windows' competing
approach, only to be abandoned without maintainer later) was really
untenable, the "Git garden shears" were born [*1*/*2*]: a script,
piggy-backing on top of the interactive rebase, that would first
determine the branch topology of the patches to be rebased, create a
pseudo todo list for further editing, transform the result into a real
todo list (making heavy use of the `exec` command to "implement" the
missing todo list commands) and finally recreate the patch series on
top of the new base commit.
That was in 2013. And it took about three weeks to come up with the
design and implement it as an out-of-tree script. Needless to say, the
implementation needed quite a few years to stabilize, all the while the
design itself proved itself sound.
With this patch, the goodness of the Git garden shears comes to `git
rebase -i` itself. Passing the `--rebase-merges` option will generate
a todo list that can be understood readily, and where it is obvious
how to reorder commits. New branches can be introduced by inserting
`label` commands and calling `merge <label>`. And once this mode will
have become stable and universally accepted, we can deprecate the design
mistake that was `--preserve-merges`.
Link *1*:
https://github.com/msysgit/msysgit/blob/master/share/msysGit/shears.sh
Link *2*:
https://github.com/git-for-windows/build-extra/blob/master/shears.sh
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 14:29:04 +02:00
|
|
|
test_expect_success 'with a branch tip that was cherry-picked already' '
|
|
|
|
|
git checkout -b already-upstream master &&
|
|
|
|
|
base="$(git rev-parse --verify HEAD)" &&
|
|
|
|
|
|
|
|
|
|
test_commit A1 &&
|
|
|
|
|
test_commit A2 &&
|
|
|
|
|
git reset --hard $base &&
|
|
|
|
|
test_commit B1 &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git merge -m "Merge branch A" A2 &&
|
|
|
|
|
|
|
|
|
|
git checkout -b upstream-with-a2 $base &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git cherry-pick A2 &&
|
|
|
|
|
|
|
|
|
|
git checkout already-upstream &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git rebase -i -r upstream-with-a2 &&
|
|
|
|
|
test_cmp_graph upstream-with-a2.. <<-\EOF
|
|
|
|
|
* Merge branch A
|
|
|
|
|
|\
|
|
|
|
|
| * A1
|
|
|
|
|
* | B1
|
|
|
|
|
|/
|
|
|
|
|
o A2
|
|
|
|
|
EOF
|
|
|
|
|
'
|
|
|
|
|
|
rebase -i: introduce --rebase-merges=[no-]rebase-cousins
When running `git rebase --rebase-merges` non-interactively with an
ancestor of HEAD as <upstream> (or leaving the todo list unmodified),
we would ideally recreate the exact same commits as before the rebase.
However, if there are commits in the commit range <upstream>.. that do not
have <upstream> as direct ancestor (i.e. if `git log <upstream>..` would
show commits that are omitted by `git log --ancestry-path <upstream>..`),
this is currently not the case: we would turn them into commits that have
<upstream> as direct ancestor.
Let's illustrate that with a diagram:
C
/ \
A - B - E - F
\ /
D
Currently, after running `git rebase -i --rebase-merges B`, the new branch
structure would be (pay particular attention to the commit `D`):
--- C' --
/ \
A - B ------ E' - F'
\ /
D'
This is not really preserving the branch topology from before! The
reason is that the commit `D` does not have `B` as ancestor, and
therefore it gets rebased onto `B`.
This is unintuitive behavior. Even worse, when recreating branch
structure, most use cases would appear to want cousins *not* to be
rebased onto the new base commit. For example, Git for Windows (the
heaviest user of the Git garden shears, which served as the blueprint
for --rebase-merges) frequently merges branches from `next` early, and
these branches certainly do *not* want to be rebased. In the example
above, the desired outcome would look like this:
--- C' --
/ \
A - B ------ E' - F'
\ /
-- D' --
Let's introduce the term "cousins" for such commits ("D" in the
example), and let's not rebase them by default. For hypothetical
use cases where cousins *do* need to be rebased, `git rebase
--rebase=merges=rebase-cousins` needs to be used.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 14:29:40 +02:00
|
|
|
test_expect_success 'do not rebase cousins unless asked for' '
|
|
|
|
|
git checkout -b cousins master &&
|
|
|
|
|
before="$(git rev-parse --verify HEAD)" &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git rebase -r HEAD^ &&
|
|
|
|
|
test_cmp_rev HEAD $before &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git rebase --rebase-merges=rebase-cousins HEAD^ &&
|
|
|
|
|
test_cmp_graph HEAD^.. <<-\EOF
|
|
|
|
|
* Merge the topic branch '\''onebranch'\''
|
|
|
|
|
|\
|
|
|
|
|
| * D
|
|
|
|
|
| * G
|
|
|
|
|
|/
|
|
|
|
|
o H
|
|
|
|
|
EOF
|
|
|
|
|
'
|
|
|
|
|
|
2018-04-25 14:29:16 +02:00
|
|
|
test_expect_success 'refs/rewritten/* is worktree-local' '
|
|
|
|
|
git worktree add wt &&
|
|
|
|
|
cat >wt/script-from-scratch <<-\EOF &&
|
|
|
|
|
label xyz
|
|
|
|
|
exec GIT_DIR=../.git git rev-parse --verify refs/rewritten/xyz >a || :
|
|
|
|
|
exec git rev-parse --verify refs/rewritten/xyz >b
|
|
|
|
|
EOF
|
|
|
|
|
|
|
|
|
|
test_config -C wt sequence.editor \""$PWD"/replace-editor.sh\" &&
|
|
|
|
|
git -C wt rebase -i HEAD &&
|
|
|
|
|
test_must_be_empty wt/a &&
|
|
|
|
|
test_cmp_rev HEAD "$(cat wt/b)"
|
|
|
|
|
'
|
|
|
|
|
|
2018-04-25 14:29:29 +02:00
|
|
|
test_expect_success 'post-rewrite hook and fixups work for merges' '
|
|
|
|
|
git checkout -b post-rewrite &&
|
|
|
|
|
test_commit same1 &&
|
|
|
|
|
git reset --hard HEAD^ &&
|
|
|
|
|
test_commit same2 &&
|
|
|
|
|
git merge -m "to fix up" same1 &&
|
|
|
|
|
echo same old same old >same2.t &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit --fixup HEAD same2.t &&
|
|
|
|
|
fixup="$(git rev-parse HEAD)" &&
|
|
|
|
|
|
|
|
|
|
mkdir -p .git/hooks &&
|
|
|
|
|
test_when_finished "rm .git/hooks/post-rewrite" &&
|
|
|
|
|
echo "cat >actual" | write_script .git/hooks/post-rewrite &&
|
|
|
|
|
|
|
|
|
|
test_tick &&
|
|
|
|
|
git rebase -i --autosquash -r HEAD^^^ &&
|
|
|
|
|
printf "%s %s\n%s %s\n%s %s\n%s %s\n" >expect $(git rev-parse \
|
|
|
|
|
$fixup^^2 HEAD^2 \
|
|
|
|
|
$fixup^^ HEAD^ \
|
|
|
|
|
$fixup^ HEAD \
|
|
|
|
|
$fixup HEAD) &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
2018-04-25 14:29:31 +02:00
|
|
|
test_expect_success 'refuse to merge ancestors of HEAD' '
|
|
|
|
|
echo "merge HEAD^" >script-from-scratch &&
|
|
|
|
|
test_config -C wt sequence.editor \""$PWD"/replace-editor.sh\" &&
|
|
|
|
|
before="$(git rev-parse HEAD)" &&
|
|
|
|
|
git rebase -i HEAD &&
|
|
|
|
|
test_cmp_rev HEAD $before
|
|
|
|
|
'
|
|
|
|
|
|
2018-05-04 01:01:23 +02:00
|
|
|
test_expect_success 'root commits' '
|
|
|
|
|
git checkout --orphan unrelated &&
|
|
|
|
|
(GIT_AUTHOR_NAME="Parsnip" GIT_AUTHOR_EMAIL="root@example.com" \
|
|
|
|
|
test_commit second-root) &&
|
|
|
|
|
test_commit third-root &&
|
|
|
|
|
cat >script-from-scratch <<-\EOF &&
|
|
|
|
|
pick third-root
|
|
|
|
|
label first-branch
|
|
|
|
|
reset [new root]
|
|
|
|
|
pick second-root
|
|
|
|
|
merge first-branch # Merge the 3rd root
|
|
|
|
|
EOF
|
|
|
|
|
test_config sequence.editor \""$PWD"/replace-editor.sh\" &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git rebase -i --force --root -r &&
|
|
|
|
|
test "Parsnip" = "$(git show -s --format=%an HEAD^)" &&
|
|
|
|
|
test $(git rev-parse second-root^0) != $(git rev-parse HEAD^) &&
|
|
|
|
|
test $(git rev-parse second-root:second-root.t) = \
|
|
|
|
|
$(git rev-parse HEAD^:second-root.t) &&
|
|
|
|
|
test_cmp_graph HEAD <<-\EOF &&
|
|
|
|
|
* Merge the 3rd root
|
|
|
|
|
|\
|
|
|
|
|
| * third-root
|
|
|
|
|
* second-root
|
|
|
|
|
EOF
|
|
|
|
|
|
|
|
|
|
: fast forward if possible &&
|
|
|
|
|
before="$(git rev-parse --verify HEAD)" &&
|
|
|
|
|
test_might_fail git config --unset sequence.editor &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git rebase -i --root -r &&
|
|
|
|
|
test_cmp_rev HEAD $before
|
|
|
|
|
'
|
|
|
|
|
|
2018-05-04 01:01:28 +02:00
|
|
|
test_expect_success 'a "merge" into a root commit is a fast-forward' '
|
|
|
|
|
head=$(git rev-parse HEAD) &&
|
|
|
|
|
cat >script-from-scratch <<-EOF &&
|
|
|
|
|
reset [new root]
|
|
|
|
|
merge $head
|
|
|
|
|
EOF
|
|
|
|
|
test_config sequence.editor \""$PWD"/replace-editor.sh\" &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git rebase -i -r HEAD^ &&
|
|
|
|
|
test_cmp_rev HEAD $head
|
|
|
|
|
'
|
|
|
|
|
|
2018-05-04 01:01:29 +02:00
|
|
|
test_expect_success 'A root commit can be a cousin, treat it that way' '
|
|
|
|
|
git checkout --orphan khnum &&
|
|
|
|
|
test_commit yama &&
|
|
|
|
|
git checkout -b asherah master &&
|
|
|
|
|
test_commit shamkat &&
|
|
|
|
|
git merge --allow-unrelated-histories khnum &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git rebase -f -r HEAD^ &&
|
|
|
|
|
! test_cmp_rev HEAD^2 khnum &&
|
|
|
|
|
test_cmp_graph HEAD^.. <<-\EOF &&
|
|
|
|
|
* Merge branch '\''khnum'\'' into asherah
|
|
|
|
|
|\
|
|
|
|
|
| * yama
|
|
|
|
|
o shamkat
|
|
|
|
|
EOF
|
|
|
|
|
test_tick &&
|
|
|
|
|
git rebase --rebase-merges=rebase-cousins HEAD^ &&
|
|
|
|
|
test_cmp_graph HEAD^.. <<-\EOF
|
|
|
|
|
* Merge branch '\''khnum'\'' into asherah
|
|
|
|
|
|\
|
|
|
|
|
| * yama
|
|
|
|
|
|/
|
|
|
|
|
o shamkat
|
|
|
|
|
EOF
|
|
|
|
|
'
|
2018-05-04 01:01:28 +02:00
|
|
|
|
2018-05-29 18:32:36 +02:00
|
|
|
test_expect_success 'labels that are object IDs are rewritten' '
|
|
|
|
|
git checkout -b third B &&
|
|
|
|
|
test_commit I &&
|
|
|
|
|
third=$(git rev-parse HEAD) &&
|
|
|
|
|
git checkout -b labels master &&
|
|
|
|
|
git merge --no-commit third &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m "Merge commit '\''$third'\'' into labels" &&
|
2018-06-01 19:46:39 +02:00
|
|
|
echo noop >script-from-scratch &&
|
2018-05-29 18:32:36 +02:00
|
|
|
test_config sequence.editor \""$PWD"/replace-editor.sh\" &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git rebase -i -r A &&
|
2018-06-01 19:46:39 +02:00
|
|
|
grep "^label $third-" .git/ORIGINAL-TODO &&
|
2018-05-29 18:32:36 +02:00
|
|
|
! grep "^label $third$" .git/ORIGINAL-TODO
|
|
|
|
|
'
|
|
|
|
|
|
2017-12-21 15:52:45 +01:00
|
|
|
test_expect_success 'octopus merges' '
|
|
|
|
|
git checkout -b three &&
|
|
|
|
|
test_commit before-octopus &&
|
|
|
|
|
test_commit three &&
|
|
|
|
|
git checkout -b two HEAD^ &&
|
|
|
|
|
test_commit two &&
|
|
|
|
|
git checkout -b one HEAD^ &&
|
|
|
|
|
test_commit one &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
(GIT_AUTHOR_NAME="Hank" GIT_AUTHOR_EMAIL="hank@sea.world" \
|
|
|
|
|
git merge -m "Tüntenfüsch" two three) &&
|
|
|
|
|
|
|
|
|
|
: fast forward if possible &&
|
|
|
|
|
before="$(git rev-parse --verify HEAD)" &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git rebase -i -r HEAD^^ &&
|
|
|
|
|
test_cmp_rev HEAD $before &&
|
|
|
|
|
|
|
|
|
|
test_tick &&
|
|
|
|
|
git rebase -i --force -r HEAD^^ &&
|
|
|
|
|
test "Hank" = "$(git show -s --format=%an HEAD)" &&
|
|
|
|
|
test "$before" != $(git rev-parse HEAD) &&
|
|
|
|
|
test_cmp_graph HEAD^^.. <<-\EOF
|
|
|
|
|
*-. Tüntenfüsch
|
|
|
|
|
|\ \
|
|
|
|
|
| | * three
|
|
|
|
|
| * | two
|
|
|
|
|
| |/
|
|
|
|
|
* | one
|
|
|
|
|
|/
|
|
|
|
|
o before-octopus
|
|
|
|
|
EOF
|
|
|
|
|
'
|
|
|
|
|
|
rebase --exec: make it work with --rebase-merges
The idea of `--exec` is to append an `exec` call after each `pick`.
Since the introduction of fixup!/squash! commits, this idea was extended
to apply to "pick, possibly followed by a fixup/squash chain", i.e. an
exec would not be inserted between a `pick` and any of its corresponding
`fixup` or `squash` lines.
The current implementation uses a dirty trick to achieve that: it
assumes that there are only pick/fixup/squash commands, and then
*inserts* the `exec` lines before any `pick` but the first, and appends
a final one.
With the todo lists generated by `git rebase --rebase-merges`, this
simple implementation shows its problems: it produces the exact wrong
thing when there are `label`, `reset` and `merge` commands.
Let's change the implementation to do exactly what we want: look for
`pick` lines, skip any fixup/squash chains, and then insert the `exec`
line. Lather, rinse, repeat.
Note: we take pains to insert *before* comment lines whenever possible,
as empty commits are represented by commented-out pick lines (and we
want to insert a preceding pick's exec line *before* such a line, not
afterward).
While at it, also add `exec` lines after `merge` commands, because they
are similar in spirit to `pick` commands: they add new commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-09 11:41:11 +02:00
|
|
|
test_expect_success 'with --autosquash and --exec' '
|
2018-08-06 11:52:52 +02:00
|
|
|
git checkout -b with-exec H &&
|
|
|
|
|
echo Booh >B.t &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit --fixup B B.t &&
|
|
|
|
|
write_script show.sh <<-\EOF &&
|
|
|
|
|
subject="$(git show -s --format=%s HEAD)"
|
|
|
|
|
content="$(git diff HEAD^! | tail -n 1)"
|
|
|
|
|
echo "$subject: $content"
|
|
|
|
|
EOF
|
|
|
|
|
test_tick &&
|
|
|
|
|
git rebase -ir --autosquash --exec ./show.sh A >actual &&
|
|
|
|
|
grep "B: +Booh" actual &&
|
|
|
|
|
grep "E: +Booh" actual &&
|
|
|
|
|
grep "G: +G" actual
|
|
|
|
|
'
|
|
|
|
|
|
2018-11-13 00:25:58 +01:00
|
|
|
test_expect_success '--continue after resolving conflicts after a merge' '
|
2018-11-13 00:25:57 +01:00
|
|
|
git checkout -b already-has-g E &&
|
|
|
|
|
git cherry-pick E..G &&
|
|
|
|
|
test_commit H2 &&
|
|
|
|
|
|
|
|
|
|
git checkout -b conflicts-in-merge H &&
|
|
|
|
|
test_commit H2 H2.t conflicts H2-conflict &&
|
|
|
|
|
test_must_fail git rebase -r already-has-g &&
|
|
|
|
|
grep conflicts H2.t &&
|
|
|
|
|
echo resolved >H2.t &&
|
|
|
|
|
git add -u &&
|
|
|
|
|
git rebase --continue &&
|
|
|
|
|
test_must_fail git rev-parse --verify HEAD^2 &&
|
|
|
|
|
test_path_is_missing .git/MERGE_HEAD
|
|
|
|
|
'
|
|
|
|
|
|
rebase: introduce the --rebase-merges option
Once upon a time, this here developer thought: wouldn't it be nice if,
say, Git for Windows' patches on top of core Git could be represented as
a thicket of branches, and be rebased on top of core Git in order to
maintain a cherry-pick'able set of patch series?
The original attempt to answer this was: git rebase --preserve-merges.
However, that experiment was never intended as an interactive option,
and it only piggy-backed on git rebase --interactive because that
command's implementation looked already very, very familiar: it was
designed by the same person who designed --preserve-merges: yours truly.
Some time later, some other developer (I am looking at you, Andreas!
;-)) decided that it would be a good idea to allow --preserve-merges to
be combined with --interactive (with caveats!) and the Git maintainer
(well, the interim Git maintainer during Junio's absence, that is)
agreed, and that is when the glamor of the --preserve-merges design
started to fall apart rather quickly and unglamorously.
The reason? In --preserve-merges mode, the parents of a merge commit (or
for that matter, of *any* commit) were not stated explicitly, but were
*implied* by the commit name passed to the `pick` command.
This made it impossible, for example, to reorder commits. Not to mention
to move commits between branches or, deity forbid, to split topic branches
into two.
Alas, these shortcomings also prevented that mode (whose original
purpose was to serve Git for Windows' needs, with the additional hope
that it may be useful to others, too) from serving Git for Windows'
needs.
Five years later, when it became really untenable to have one unwieldy,
big hodge-podge patch series of partly related, partly unrelated patches
in Git for Windows that was rebased onto core Git's tags from time to
time (earning the undeserved wrath of the developer of the ill-fated
git-remote-hg series that first obsoleted Git for Windows' competing
approach, only to be abandoned without maintainer later) was really
untenable, the "Git garden shears" were born [*1*/*2*]: a script,
piggy-backing on top of the interactive rebase, that would first
determine the branch topology of the patches to be rebased, create a
pseudo todo list for further editing, transform the result into a real
todo list (making heavy use of the `exec` command to "implement" the
missing todo list commands) and finally recreate the patch series on
top of the new base commit.
That was in 2013. And it took about three weeks to come up with the
design and implement it as an out-of-tree script. Needless to say, the
implementation needed quite a few years to stabilize, all the while the
design itself proved itself sound.
With this patch, the goodness of the Git garden shears comes to `git
rebase -i` itself. Passing the `--rebase-merges` option will generate
a todo list that can be understood readily, and where it is obvious
how to reorder commits. New branches can be introduced by inserting
`label` commands and calling `merge <label>`. And once this mode will
have become stable and universally accepted, we can deprecate the design
mistake that was `--preserve-merges`.
Link *1*:
https://github.com/msysgit/msysgit/blob/master/share/msysGit/shears.sh
Link *2*:
https://github.com/git-for-windows/build-extra/blob/master/shears.sh
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25 14:29:04 +02:00
|
|
|
test_done
|