2014-06-15 17:02:47 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='pull can handle submodules'
|
|
|
|
|
2021-10-08 21:08:19 +00:00
|
|
|
GIT_TEST_FATAL_REGISTER_SUBMODULE_ODB=1
|
|
|
|
export GIT_TEST_FATAL_REGISTER_SUBMODULE_ODB
|
|
|
|
|
2014-06-15 17:02:47 +00:00
|
|
|
. ./test-lib.sh
|
|
|
|
. "$TEST_DIRECTORY"/lib-submodule-update.sh
|
|
|
|
|
|
|
|
reset_branch_to_HEAD () {
|
|
|
|
git branch -D "$1" &&
|
|
|
|
git checkout -b "$1" HEAD &&
|
|
|
|
git branch --set-upstream-to="origin/$1" "$1"
|
|
|
|
}
|
|
|
|
|
|
|
|
git_pull () {
|
|
|
|
reset_branch_to_HEAD "$1" &&
|
lib-submodule-update: pass 'test_must_fail' as an argument
When we run a test helper function in test_submodule_switch_common(), we
sometimes specify a whole helper function as the $command. When we do
this, in some test cases, we just mark the whole function with
`test_must_fail`. However, it's possible that the helper function might
fail earlier or later than expected due to an introduced bug. If this
happens, then the test case will still report as passing but it should
really be marked as failing since it didn't actually display the
intended behaviour.
Instead of invoking `test_must_fail $command`, pass the string
"test_must_fail" as the second argument in case where the git command is
expected to fail.
When $command is a helper function, the parent function calling
test_submodule_switch_common() is test_submodule_switch_func(). For all
test_submodule_switch_func() invocations, increase the granularity of
the argument test helper function by prefixing the git invocation which is
meant to fail with the second argument like this:
$2 git checkout "$1"
In the other cases, test_submodule_switch() and
test_submodule_forced_switch(), instead of passing in the git command
directly, wrap it using the git_test_func() and pass the git arguments
using the global variable $gitcmd. Unfortunately, since closures aren't
a thing in shell scripts, the global variable is necessary. Another
unfortunate result is that the "git_test_func" will used as the test
case name when $command is printed but it's worth it for the cleaner
code.
Finally, as an added bonus, `test_must_fail` will now only run on git
commands.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24 08:50:18 +00:00
|
|
|
may_only_be_test_must_fail "$2" &&
|
|
|
|
$2 git pull
|
2014-06-15 17:02:47 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
# pulls without conflicts
|
2020-06-11 17:41:49 +00:00
|
|
|
test_submodule_switch_func "git_pull"
|
2014-06-15 17:02:47 +00:00
|
|
|
|
|
|
|
git_pull_ff () {
|
|
|
|
reset_branch_to_HEAD "$1" &&
|
lib-submodule-update: pass 'test_must_fail' as an argument
When we run a test helper function in test_submodule_switch_common(), we
sometimes specify a whole helper function as the $command. When we do
this, in some test cases, we just mark the whole function with
`test_must_fail`. However, it's possible that the helper function might
fail earlier or later than expected due to an introduced bug. If this
happens, then the test case will still report as passing but it should
really be marked as failing since it didn't actually display the
intended behaviour.
Instead of invoking `test_must_fail $command`, pass the string
"test_must_fail" as the second argument in case where the git command is
expected to fail.
When $command is a helper function, the parent function calling
test_submodule_switch_common() is test_submodule_switch_func(). For all
test_submodule_switch_func() invocations, increase the granularity of
the argument test helper function by prefixing the git invocation which is
meant to fail with the second argument like this:
$2 git checkout "$1"
In the other cases, test_submodule_switch() and
test_submodule_forced_switch(), instead of passing in the git command
directly, wrap it using the git_test_func() and pass the git arguments
using the global variable $gitcmd. Unfortunately, since closures aren't
a thing in shell scripts, the global variable is necessary. Another
unfortunate result is that the "git_test_func" will used as the test
case name when $command is printed but it's worth it for the cleaner
code.
Finally, as an added bonus, `test_must_fail` will now only run on git
commands.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24 08:50:18 +00:00
|
|
|
may_only_be_test_must_fail "$2" &&
|
|
|
|
$2 git pull --ff
|
2014-06-15 17:02:47 +00:00
|
|
|
}
|
|
|
|
|
2020-06-11 17:41:49 +00:00
|
|
|
test_submodule_switch_func "git_pull_ff"
|
2014-06-15 17:02:47 +00:00
|
|
|
|
|
|
|
git_pull_ff_only () {
|
|
|
|
reset_branch_to_HEAD "$1" &&
|
lib-submodule-update: pass 'test_must_fail' as an argument
When we run a test helper function in test_submodule_switch_common(), we
sometimes specify a whole helper function as the $command. When we do
this, in some test cases, we just mark the whole function with
`test_must_fail`. However, it's possible that the helper function might
fail earlier or later than expected due to an introduced bug. If this
happens, then the test case will still report as passing but it should
really be marked as failing since it didn't actually display the
intended behaviour.
Instead of invoking `test_must_fail $command`, pass the string
"test_must_fail" as the second argument in case where the git command is
expected to fail.
When $command is a helper function, the parent function calling
test_submodule_switch_common() is test_submodule_switch_func(). For all
test_submodule_switch_func() invocations, increase the granularity of
the argument test helper function by prefixing the git invocation which is
meant to fail with the second argument like this:
$2 git checkout "$1"
In the other cases, test_submodule_switch() and
test_submodule_forced_switch(), instead of passing in the git command
directly, wrap it using the git_test_func() and pass the git arguments
using the global variable $gitcmd. Unfortunately, since closures aren't
a thing in shell scripts, the global variable is necessary. Another
unfortunate result is that the "git_test_func" will used as the test
case name when $command is printed but it's worth it for the cleaner
code.
Finally, as an added bonus, `test_must_fail` will now only run on git
commands.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24 08:50:18 +00:00
|
|
|
may_only_be_test_must_fail "$2" &&
|
|
|
|
$2 git pull --ff-only
|
2014-06-15 17:02:47 +00:00
|
|
|
}
|
|
|
|
|
2020-06-11 17:41:49 +00:00
|
|
|
test_submodule_switch_func "git_pull_ff_only"
|
2014-06-15 17:02:47 +00:00
|
|
|
|
|
|
|
git_pull_noff () {
|
|
|
|
reset_branch_to_HEAD "$1" &&
|
lib-submodule-update: pass 'test_must_fail' as an argument
When we run a test helper function in test_submodule_switch_common(), we
sometimes specify a whole helper function as the $command. When we do
this, in some test cases, we just mark the whole function with
`test_must_fail`. However, it's possible that the helper function might
fail earlier or later than expected due to an introduced bug. If this
happens, then the test case will still report as passing but it should
really be marked as failing since it didn't actually display the
intended behaviour.
Instead of invoking `test_must_fail $command`, pass the string
"test_must_fail" as the second argument in case where the git command is
expected to fail.
When $command is a helper function, the parent function calling
test_submodule_switch_common() is test_submodule_switch_func(). For all
test_submodule_switch_func() invocations, increase the granularity of
the argument test helper function by prefixing the git invocation which is
meant to fail with the second argument like this:
$2 git checkout "$1"
In the other cases, test_submodule_switch() and
test_submodule_forced_switch(), instead of passing in the git command
directly, wrap it using the git_test_func() and pass the git arguments
using the global variable $gitcmd. Unfortunately, since closures aren't
a thing in shell scripts, the global variable is necessary. Another
unfortunate result is that the "git_test_func" will used as the test
case name when $command is printed but it's worth it for the cleaner
code.
Finally, as an added bonus, `test_must_fail` will now only run on git
commands.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24 08:50:18 +00:00
|
|
|
may_only_be_test_must_fail "$2" &&
|
|
|
|
$2 git pull --no-ff
|
2014-06-15 17:02:47 +00:00
|
|
|
}
|
|
|
|
|
2021-03-20 00:03:51 +00:00
|
|
|
if test "$GIT_TEST_MERGE_ALGORITHM" != ort
|
|
|
|
then
|
|
|
|
KNOWN_FAILURE_NOFF_MERGE_DOESNT_CREATE_EMPTY_SUBMODULE_DIR=1
|
|
|
|
KNOWN_FAILURE_NOFF_MERGE_ATTEMPTS_TO_MERGE_REMOVED_SUBMODULE_FILES=1
|
|
|
|
fi
|
2020-06-11 17:41:49 +00:00
|
|
|
test_submodule_switch_func "git_pull_noff"
|
2014-06-15 17:02:47 +00:00
|
|
|
|
2022-07-29 19:21:06 +00:00
|
|
|
test_expect_success 'setup' '
|
|
|
|
git config --global protocol.file.allow always
|
|
|
|
'
|
|
|
|
|
pull: optionally rebase submodules (remote submodule changes only)
Teach pull to optionally update submodules when '--recurse-submodules'
is provided. This will teach pull to run 'submodule update --rebase'
when the '--recurse-submodules' and '--rebase' flags are given under
specific circumstances.
On a rebase workflow:
=====================
1. Both sides change the submodule
------------------------------
Let's assume the following history in a submodule:
H---I---J---K---L local branch
\
M---N---O---P remote branch
and the following in the superproject (recorded submodule in parens):
A(H)---B(I)---F(K)---G(L) local branch
\
C(N)---D(N)---E(P) remote branch
In an ideal world this would rebase the submodule and rewrite
the submodule pointers that the superproject points at such that
the superproject looks like
A(H)---B(I) F(K')---G(L') rebased branch
\ /
C(N)---D(N)---E(P) remote branch
and the submodule as:
J---K---L (old dangeling tip)
/
H---I J'---K'---L' rebased branch
\ /
M---N---O---P remote branch
And if a conflict arises in the submodule the superproject rebase
would stop at that commit at which the submodule conflict occurs.
Currently a "pull --rebase" in the superproject produces
a merge conflict as the submodule pointer changes are
conflicting and cannot be resolved.
2. Local submodule changes only
-----------------------
Assuming histories as above, except that the remote branch
would not contain submodule changes, then a result as
A(H)---B(I) F(K)---G(L) rebased branch
\ /
C(I)---D(I)---E(I) remote branch
is desire-able. This is what currently happens in rebase.
If the recursive flag is given, the ideal git would
produce a superproject as:
A(H)---B(I) F(K')---G(L') rebased branch (incl. sub rebase!)
\ /
C(I)---D(I)---E(I) remote branch
and the submodule as:
J---K---L (old dangeling tip)
/
H---I J'---K'---L' locally rebased branch
\ /
M---N---O---P advanced branch
This patch doesn't address this issue, however
a test is added that this fails up front.
3. Remote submodule changes only
----------------------
Assuming histories as in (1) except that the local superproject branch
would not have touched the submodule the rebase already works out in the
superproject with no conflicts:
A(H)---B(I) F(P)---G(P) rebased branch (no sub changes)
\ /
C(N)---D(N)---E(P) remote branch
The recurse flag as presented in this patch would additionally
update the submodule as:
H---I J'---K'---L' rebased branch
\ /
M---N---O---P remote branch
As neither J, K, L nor J', K', L' are referred to from the superproject,
no rewriting of the superproject commits is required.
Conclusion for 'pull --rebase --recursive'
-----------------------------------------
If there are no local superproject changes it is sufficient to call
"submodule update --rebase" as this produces the desired results. In case
of conflicts, the behavior is the same as in 'submodule update --recursive'
which is assumed to be sane.
This patch implements (3) only.
On a merge workflow:
====================
We'll start off with the same underlying DAG as in (1) in the rebase
workflow. So in an ideal world a 'pull --merge --recursive' would
produce this:
H---I---J---K---L----X
\ /
M---N---O---P
with X as the new merge-commit in the submodule and the superproject
as:
A(H)---B(I)---F(K)---G(L)---Y(X)
\ /
C(N)---D(N)---E(P)
However modifying the submodules on the fly is not supported in git-merge
such that Y(X) is not easy to produce in a single patch. In fact git-merge
doesn't know about submodules at all.
However when at least one side does not contain commits touching the
submodule at all, then we do not need to perform the merge for the
submodule but a fast-forward can be done via checking out either L or P
in the submodule. This strategy is implemented in 68d03e4a6e (Implement
automatic fast-forward merge for submodules, 2010-07-07) already, so
to align with the rebase behavior we need to also update the worktree
of the submodule.
Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-23 19:13:02 +00:00
|
|
|
test_expect_success 'pull --recurse-submodule setup' '
|
|
|
|
test_create_repo child &&
|
|
|
|
test_commit -C child bar &&
|
|
|
|
|
|
|
|
test_create_repo parent &&
|
|
|
|
test_commit -C child foo &&
|
|
|
|
|
|
|
|
git -C parent submodule add ../child sub &&
|
|
|
|
git -C parent commit -m "add submodule" &&
|
|
|
|
|
|
|
|
git clone --recurse-submodules parent super
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'recursive pull updates working tree' '
|
|
|
|
test_commit -C child merge_strategy &&
|
|
|
|
git -C parent submodule update --remote &&
|
|
|
|
git -C parent add sub &&
|
|
|
|
git -C parent commit -m "update submodule" &&
|
|
|
|
|
|
|
|
git -C super pull --no-rebase --recurse-submodules &&
|
|
|
|
test_path_is_file super/sub/merge_strategy.t
|
|
|
|
'
|
|
|
|
|
2017-09-06 06:48:09 +00:00
|
|
|
test_expect_success "submodule.recurse option triggers recursive pull" '
|
|
|
|
test_commit -C child merge_strategy_2 &&
|
|
|
|
git -C parent submodule update --remote &&
|
|
|
|
git -C parent add sub &&
|
|
|
|
git -C parent commit -m "update submodule" &&
|
|
|
|
|
|
|
|
git -C super -c submodule.recurse pull --no-rebase &&
|
|
|
|
test_path_is_file super/sub/merge_strategy_2.t
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success " --[no-]recurse-submodule and submodule.recurse" '
|
|
|
|
test_commit -C child merge_strategy_3 &&
|
|
|
|
git -C parent submodule update --remote &&
|
|
|
|
git -C parent add sub &&
|
|
|
|
git -C parent commit -m "update submodule" &&
|
|
|
|
|
|
|
|
git -C super -c submodule.recurse pull --no-recurse-submodules --no-rebase &&
|
|
|
|
test_path_is_missing super/sub/merge_strategy_3.t &&
|
|
|
|
git -C super -c submodule.recurse=false pull --recurse-submodules --no-rebase &&
|
|
|
|
test_path_is_file super/sub/merge_strategy_3.t &&
|
|
|
|
|
|
|
|
test_commit -C child merge_strategy_4 &&
|
|
|
|
git -C parent submodule update --remote &&
|
|
|
|
git -C parent add sub &&
|
|
|
|
git -C parent commit -m "update submodule" &&
|
|
|
|
|
|
|
|
git -C super -c submodule.recurse=false pull --no-recurse-submodules --no-rebase &&
|
|
|
|
test_path_is_missing super/sub/merge_strategy_4.t &&
|
|
|
|
git -C super -c submodule.recurse=true pull --recurse-submodules --no-rebase &&
|
|
|
|
test_path_is_file super/sub/merge_strategy_4.t
|
|
|
|
'
|
|
|
|
|
2022-05-10 19:25:47 +00:00
|
|
|
test_expect_success "fetch.recurseSubmodules option triggers recursive fetch (but not recursive update)" '
|
|
|
|
test_commit -C child merge_strategy_5 &&
|
|
|
|
# Omit the parent commit, otherwise this passes with the
|
|
|
|
# default "pull" behavior.
|
|
|
|
|
|
|
|
git -C super -c fetch.recursesubmodules=true pull --no-rebase &&
|
|
|
|
# Check that the submodule commit was fetched
|
|
|
|
sub_oid=$(git -C child rev-parse HEAD) &&
|
|
|
|
git -C super/sub cat-file -e $sub_oid &&
|
|
|
|
# Check that the submodule worktree did not update
|
2023-05-16 02:26:46 +00:00
|
|
|
test_path_is_missing super/sub/merge_strategy_5.t
|
2022-05-10 19:25:47 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success "fetch.recurseSubmodules takes precedence over submodule.recurse" '
|
|
|
|
test_commit -C child merge_strategy_6 &&
|
|
|
|
# Omit the parent commit, otherwise this passes with the
|
|
|
|
# default "pull" behavior.
|
|
|
|
|
|
|
|
git -C super -c submodule.recurse=false -c fetch.recursesubmodules=true pull --no-rebase &&
|
|
|
|
# Check that the submodule commit was fetched
|
|
|
|
sub_oid=$(git -C child rev-parse HEAD) &&
|
|
|
|
git -C super/sub cat-file -e $sub_oid &&
|
|
|
|
# Check that the submodule worktree did not update
|
2023-05-16 02:26:46 +00:00
|
|
|
test_path_is_missing super/sub/merge_strategy_6.t
|
2022-05-10 19:25:47 +00:00
|
|
|
'
|
|
|
|
|
2020-11-14 00:34:44 +00:00
|
|
|
test_expect_success 'pull --rebase --recurse-submodules (remote superproject submodule changes, local submodule changes)' '
|
|
|
|
# This tests the following scenario :
|
|
|
|
# - local submodule has new commits
|
|
|
|
# - local superproject does not have new commits
|
|
|
|
# - upstream superproject has new commits that change the submodule pointer
|
|
|
|
|
pull: optionally rebase submodules (remote submodule changes only)
Teach pull to optionally update submodules when '--recurse-submodules'
is provided. This will teach pull to run 'submodule update --rebase'
when the '--recurse-submodules' and '--rebase' flags are given under
specific circumstances.
On a rebase workflow:
=====================
1. Both sides change the submodule
------------------------------
Let's assume the following history in a submodule:
H---I---J---K---L local branch
\
M---N---O---P remote branch
and the following in the superproject (recorded submodule in parens):
A(H)---B(I)---F(K)---G(L) local branch
\
C(N)---D(N)---E(P) remote branch
In an ideal world this would rebase the submodule and rewrite
the submodule pointers that the superproject points at such that
the superproject looks like
A(H)---B(I) F(K')---G(L') rebased branch
\ /
C(N)---D(N)---E(P) remote branch
and the submodule as:
J---K---L (old dangeling tip)
/
H---I J'---K'---L' rebased branch
\ /
M---N---O---P remote branch
And if a conflict arises in the submodule the superproject rebase
would stop at that commit at which the submodule conflict occurs.
Currently a "pull --rebase" in the superproject produces
a merge conflict as the submodule pointer changes are
conflicting and cannot be resolved.
2. Local submodule changes only
-----------------------
Assuming histories as above, except that the remote branch
would not contain submodule changes, then a result as
A(H)---B(I) F(K)---G(L) rebased branch
\ /
C(I)---D(I)---E(I) remote branch
is desire-able. This is what currently happens in rebase.
If the recursive flag is given, the ideal git would
produce a superproject as:
A(H)---B(I) F(K')---G(L') rebased branch (incl. sub rebase!)
\ /
C(I)---D(I)---E(I) remote branch
and the submodule as:
J---K---L (old dangeling tip)
/
H---I J'---K'---L' locally rebased branch
\ /
M---N---O---P advanced branch
This patch doesn't address this issue, however
a test is added that this fails up front.
3. Remote submodule changes only
----------------------
Assuming histories as in (1) except that the local superproject branch
would not have touched the submodule the rebase already works out in the
superproject with no conflicts:
A(H)---B(I) F(P)---G(P) rebased branch (no sub changes)
\ /
C(N)---D(N)---E(P) remote branch
The recurse flag as presented in this patch would additionally
update the submodule as:
H---I J'---K'---L' rebased branch
\ /
M---N---O---P remote branch
As neither J, K, L nor J', K', L' are referred to from the superproject,
no rewriting of the superproject commits is required.
Conclusion for 'pull --rebase --recursive'
-----------------------------------------
If there are no local superproject changes it is sufficient to call
"submodule update --rebase" as this produces the desired results. In case
of conflicts, the behavior is the same as in 'submodule update --recursive'
which is assumed to be sane.
This patch implements (3) only.
On a merge workflow:
====================
We'll start off with the same underlying DAG as in (1) in the rebase
workflow. So in an ideal world a 'pull --merge --recursive' would
produce this:
H---I---J---K---L----X
\ /
M---N---O---P
with X as the new merge-commit in the submodule and the superproject
as:
A(H)---B(I)---F(K)---G(L)---Y(X)
\ /
C(N)---D(N)---E(P)
However modifying the submodules on the fly is not supported in git-merge
such that Y(X) is not easy to produce in a single patch. In fact git-merge
doesn't know about submodules at all.
However when at least one side does not contain commits touching the
submodule at all, then we do not need to perform the merge for the
submodule but a fast-forward can be done via checking out either L or P
in the submodule. This strategy is implemented in 68d03e4a6e (Implement
automatic fast-forward merge for submodules, 2010-07-07) already, so
to align with the rebase behavior we need to also update the worktree
of the submodule.
Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-23 19:13:02 +00:00
|
|
|
# change upstream
|
|
|
|
test_commit -C child rebase_strategy &&
|
|
|
|
git -C parent submodule update --remote &&
|
|
|
|
git -C parent add sub &&
|
|
|
|
git -C parent commit -m "update submodule" &&
|
|
|
|
|
|
|
|
# also have local commits
|
|
|
|
test_commit -C super/sub local_stuff &&
|
|
|
|
|
|
|
|
git -C super pull --rebase --recurse-submodules &&
|
|
|
|
test_path_is_file super/sub/rebase_strategy.t &&
|
|
|
|
test_path_is_file super/sub/local_stuff.t
|
|
|
|
'
|
|
|
|
|
2020-11-14 00:34:44 +00:00
|
|
|
test_expect_success 'pull --rebase --recurse-submodules fails if both sides record submodule changes' '
|
|
|
|
# This tests the following scenario :
|
|
|
|
# - local superproject has new commits that change the submodule pointer
|
|
|
|
# - upstream superproject has new commits that change the submodule pointer
|
pull: optionally rebase submodules (remote submodule changes only)
Teach pull to optionally update submodules when '--recurse-submodules'
is provided. This will teach pull to run 'submodule update --rebase'
when the '--recurse-submodules' and '--rebase' flags are given under
specific circumstances.
On a rebase workflow:
=====================
1. Both sides change the submodule
------------------------------
Let's assume the following history in a submodule:
H---I---J---K---L local branch
\
M---N---O---P remote branch
and the following in the superproject (recorded submodule in parens):
A(H)---B(I)---F(K)---G(L) local branch
\
C(N)---D(N)---E(P) remote branch
In an ideal world this would rebase the submodule and rewrite
the submodule pointers that the superproject points at such that
the superproject looks like
A(H)---B(I) F(K')---G(L') rebased branch
\ /
C(N)---D(N)---E(P) remote branch
and the submodule as:
J---K---L (old dangeling tip)
/
H---I J'---K'---L' rebased branch
\ /
M---N---O---P remote branch
And if a conflict arises in the submodule the superproject rebase
would stop at that commit at which the submodule conflict occurs.
Currently a "pull --rebase" in the superproject produces
a merge conflict as the submodule pointer changes are
conflicting and cannot be resolved.
2. Local submodule changes only
-----------------------
Assuming histories as above, except that the remote branch
would not contain submodule changes, then a result as
A(H)---B(I) F(K)---G(L) rebased branch
\ /
C(I)---D(I)---E(I) remote branch
is desire-able. This is what currently happens in rebase.
If the recursive flag is given, the ideal git would
produce a superproject as:
A(H)---B(I) F(K')---G(L') rebased branch (incl. sub rebase!)
\ /
C(I)---D(I)---E(I) remote branch
and the submodule as:
J---K---L (old dangeling tip)
/
H---I J'---K'---L' locally rebased branch
\ /
M---N---O---P advanced branch
This patch doesn't address this issue, however
a test is added that this fails up front.
3. Remote submodule changes only
----------------------
Assuming histories as in (1) except that the local superproject branch
would not have touched the submodule the rebase already works out in the
superproject with no conflicts:
A(H)---B(I) F(P)---G(P) rebased branch (no sub changes)
\ /
C(N)---D(N)---E(P) remote branch
The recurse flag as presented in this patch would additionally
update the submodule as:
H---I J'---K'---L' rebased branch
\ /
M---N---O---P remote branch
As neither J, K, L nor J', K', L' are referred to from the superproject,
no rewriting of the superproject commits is required.
Conclusion for 'pull --rebase --recursive'
-----------------------------------------
If there are no local superproject changes it is sufficient to call
"submodule update --rebase" as this produces the desired results. In case
of conflicts, the behavior is the same as in 'submodule update --recursive'
which is assumed to be sane.
This patch implements (3) only.
On a merge workflow:
====================
We'll start off with the same underlying DAG as in (1) in the rebase
workflow. So in an ideal world a 'pull --merge --recursive' would
produce this:
H---I---J---K---L----X
\ /
M---N---O---P
with X as the new merge-commit in the submodule and the superproject
as:
A(H)---B(I)---F(K)---G(L)---Y(X)
\ /
C(N)---D(N)---E(P)
However modifying the submodules on the fly is not supported in git-merge
such that Y(X) is not easy to produce in a single patch. In fact git-merge
doesn't know about submodules at all.
However when at least one side does not contain commits touching the
submodule at all, then we do not need to perform the merge for the
submodule but a fast-forward can be done via checking out either L or P
in the submodule. This strategy is implemented in 68d03e4a6e (Implement
automatic fast-forward merge for submodules, 2010-07-07) already, so
to align with the rebase behavior we need to also update the worktree
of the submodule.
Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-23 19:13:02 +00:00
|
|
|
|
|
|
|
# local changes in submodule recorded in superproject:
|
|
|
|
test_commit -C super/sub local_stuff_2 &&
|
|
|
|
git -C super add sub &&
|
|
|
|
git -C super commit -m "local update submodule" &&
|
|
|
|
|
|
|
|
# and in the remote as well:
|
|
|
|
test_commit -C child important_upstream_work &&
|
|
|
|
git -C parent submodule update --remote &&
|
|
|
|
git -C parent add sub &&
|
|
|
|
git -C parent commit -m "remote update submodule" &&
|
|
|
|
|
|
|
|
# Unfortunately we fail here, despite no conflict in the
|
|
|
|
# submodule itself, but the merge strategy in submodules
|
|
|
|
# does not support rebase:
|
|
|
|
test_must_fail git -C super pull --rebase --recurse-submodules 2>err &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "locally recorded submodule modifications" err
|
pull: optionally rebase submodules (remote submodule changes only)
Teach pull to optionally update submodules when '--recurse-submodules'
is provided. This will teach pull to run 'submodule update --rebase'
when the '--recurse-submodules' and '--rebase' flags are given under
specific circumstances.
On a rebase workflow:
=====================
1. Both sides change the submodule
------------------------------
Let's assume the following history in a submodule:
H---I---J---K---L local branch
\
M---N---O---P remote branch
and the following in the superproject (recorded submodule in parens):
A(H)---B(I)---F(K)---G(L) local branch
\
C(N)---D(N)---E(P) remote branch
In an ideal world this would rebase the submodule and rewrite
the submodule pointers that the superproject points at such that
the superproject looks like
A(H)---B(I) F(K')---G(L') rebased branch
\ /
C(N)---D(N)---E(P) remote branch
and the submodule as:
J---K---L (old dangeling tip)
/
H---I J'---K'---L' rebased branch
\ /
M---N---O---P remote branch
And if a conflict arises in the submodule the superproject rebase
would stop at that commit at which the submodule conflict occurs.
Currently a "pull --rebase" in the superproject produces
a merge conflict as the submodule pointer changes are
conflicting and cannot be resolved.
2. Local submodule changes only
-----------------------
Assuming histories as above, except that the remote branch
would not contain submodule changes, then a result as
A(H)---B(I) F(K)---G(L) rebased branch
\ /
C(I)---D(I)---E(I) remote branch
is desire-able. This is what currently happens in rebase.
If the recursive flag is given, the ideal git would
produce a superproject as:
A(H)---B(I) F(K')---G(L') rebased branch (incl. sub rebase!)
\ /
C(I)---D(I)---E(I) remote branch
and the submodule as:
J---K---L (old dangeling tip)
/
H---I J'---K'---L' locally rebased branch
\ /
M---N---O---P advanced branch
This patch doesn't address this issue, however
a test is added that this fails up front.
3. Remote submodule changes only
----------------------
Assuming histories as in (1) except that the local superproject branch
would not have touched the submodule the rebase already works out in the
superproject with no conflicts:
A(H)---B(I) F(P)---G(P) rebased branch (no sub changes)
\ /
C(N)---D(N)---E(P) remote branch
The recurse flag as presented in this patch would additionally
update the submodule as:
H---I J'---K'---L' rebased branch
\ /
M---N---O---P remote branch
As neither J, K, L nor J', K', L' are referred to from the superproject,
no rewriting of the superproject commits is required.
Conclusion for 'pull --rebase --recursive'
-----------------------------------------
If there are no local superproject changes it is sufficient to call
"submodule update --rebase" as this produces the desired results. In case
of conflicts, the behavior is the same as in 'submodule update --recursive'
which is assumed to be sane.
This patch implements (3) only.
On a merge workflow:
====================
We'll start off with the same underlying DAG as in (1) in the rebase
workflow. So in an ideal world a 'pull --merge --recursive' would
produce this:
H---I---J---K---L----X
\ /
M---N---O---P
with X as the new merge-commit in the submodule and the superproject
as:
A(H)---B(I)---F(K)---G(L)---Y(X)
\ /
C(N)---D(N)---E(P)
However modifying the submodules on the fly is not supported in git-merge
such that Y(X) is not easy to produce in a single patch. In fact git-merge
doesn't know about submodules at all.
However when at least one side does not contain commits touching the
submodule at all, then we do not need to perform the merge for the
submodule but a fast-forward can be done via checking out either L or P
in the submodule. This strategy is implemented in 68d03e4a6e (Implement
automatic fast-forward merge for submodules, 2010-07-07) already, so
to align with the rebase behavior we need to also update the worktree
of the submodule.
Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-23 19:13:02 +00:00
|
|
|
'
|
|
|
|
|
pull: check for local submodule modifications with the right range
Ever since 'git pull' learned '--recurse-submodules' in a6d7eb2c7a
(pull: optionally rebase submodules (remote submodule changes only),
2017-06-23), we check if there are local submodule modifications by
checking the revision range 'curr_head --not rebase_fork_point'.
The goal of this check is to abort the pull if there are submodule
modifications in the local commits being rebased, since this scenario is
not supported.
However, the actual range of commits being rebased is not
'rebase_fork_point..curr_head', as the logic in
'get_rebase_newbase_and_upstream' reveals, it is 'upstream..curr_head'.
If the 'git merge-base --fork-point' invocation in
'get_rebase_fork_point' fails to find a fork point between the current
branch and the remote-tracking branch we are pulling from,
'rebase_fork_point' is null and since 4d36f88be7 (submodule: do not pass
null OID to setup_revisions, 2018-05-24), 'submodule_touches_in_range'
checks 'curr_head' and all its ancestors for submodule modifications.
Since it is highly likely that there are submodule modifications in this
range (which is in effect the whole history of the current branch), this
prevents 'git pull --rebase --recurse-submodules' from succeeding if no
fork point exists between the current branch and the remote-tracking
branch being pulled. This can happen, for example, when the current
branch was forked from a commit which was never recorded in the reflog
of the remote-tracking branch we are pulling, as the last two paragraphs
of the "Discussion on fork-point mode" section in git-merge-base(1)
explain.
Fix this bug by passing 'upstream' instead of 'rebase_fork_point' as the
'excl_oid' argument to 'submodule_touches_in_range'.
Reported-by: Brice Goglin <bgoglin@free.fr>
Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-14 00:34:45 +00:00
|
|
|
test_expect_success 'pull --rebase --recurse-submodules (no submodule changes, no fork-point)' '
|
|
|
|
# This tests the following scenario :
|
|
|
|
# - local submodule does not have new commits
|
|
|
|
# - local superproject has new commits that *do not* change the submodule pointer
|
|
|
|
# - upstream superproject has new commits that *do not* change the submodule pointer
|
|
|
|
# - local superproject branch has no fork-point with its remote-tracking counter-part
|
|
|
|
|
|
|
|
# create upstream superproject
|
|
|
|
test_create_repo submodule &&
|
|
|
|
test_commit -C submodule first_in_sub &&
|
|
|
|
|
|
|
|
test_create_repo superprojet &&
|
|
|
|
test_commit -C superprojet first_in_super &&
|
|
|
|
git -C superprojet submodule add ../submodule &&
|
|
|
|
git -C superprojet commit -m "add submodule" &&
|
|
|
|
test_commit -C superprojet third_in_super &&
|
|
|
|
|
|
|
|
# clone superproject
|
|
|
|
git clone --recurse-submodules superprojet superclone &&
|
|
|
|
|
|
|
|
# add commits upstream
|
|
|
|
test_commit -C superprojet fourth_in_super &&
|
|
|
|
|
|
|
|
# create topic branch in clone, not based on any remote-tracking branch
|
|
|
|
git -C superclone checkout -b feat HEAD~1 &&
|
|
|
|
test_commit -C superclone first_on_feat &&
|
2021-01-25 22:19:18 +00:00
|
|
|
git -C superclone pull --rebase --recurse-submodules origin HEAD
|
pull: check for local submodule modifications with the right range
Ever since 'git pull' learned '--recurse-submodules' in a6d7eb2c7a
(pull: optionally rebase submodules (remote submodule changes only),
2017-06-23), we check if there are local submodule modifications by
checking the revision range 'curr_head --not rebase_fork_point'.
The goal of this check is to abort the pull if there are submodule
modifications in the local commits being rebased, since this scenario is
not supported.
However, the actual range of commits being rebased is not
'rebase_fork_point..curr_head', as the logic in
'get_rebase_newbase_and_upstream' reveals, it is 'upstream..curr_head'.
If the 'git merge-base --fork-point' invocation in
'get_rebase_fork_point' fails to find a fork point between the current
branch and the remote-tracking branch we are pulling from,
'rebase_fork_point' is null and since 4d36f88be7 (submodule: do not pass
null OID to setup_revisions, 2018-05-24), 'submodule_touches_in_range'
checks 'curr_head' and all its ancestors for submodule modifications.
Since it is highly likely that there are submodule modifications in this
range (which is in effect the whole history of the current branch), this
prevents 'git pull --rebase --recurse-submodules' from succeeding if no
fork point exists between the current branch and the remote-tracking
branch being pulled. This can happen, for example, when the current
branch was forked from a commit which was never recorded in the reflog
of the remote-tracking branch we are pulling, as the last two paragraphs
of the "Discussion on fork-point mode" section in git-merge-base(1)
explain.
Fix this bug by passing 'upstream' instead of 'rebase_fork_point' as the
'excl_oid' argument to 'submodule_touches_in_range'.
Reported-by: Brice Goglin <bgoglin@free.fr>
Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-14 00:34:45 +00:00
|
|
|
'
|
|
|
|
|
t5572: add notes on a peculiar test
Test 5572.63 ("branch has no merge base with remote-tracking
counterpart") was introduced in 4d36f88be7 (submodule: do not pass null
OID to setup_revisions, 2018-05-24), as a regression test for the bug
this commit was fixing (preventing a 'fatal: bad object' error when the
current branch and the remote-tracking branch we are pulling have no
merge-base).
However, the commit message for 4d36f88be7 does not describe in which
real-life situation this bug was encountered. The brief discussion on the
mailing list [1] does not either.
The regression test is not really representative of a real-life
scenario: both the local repository and its upstream have only a single
commit, and the "no merge-base" scenario is simulated by recreating this
root commit in the local repository using 'git commit-tree' before
calling 'git pull --rebase --recurse-submodules'. The rebase succeeds
and results in the local branch being reset to the same root commit as
the upstream branch.
The fix in 4d36f88be7 modifies 'submodule.c::submodule_touches_in_range'
so that if 'excl_oid' is null, which is the case when the 'git merge-base
--fork-point' invocation in 'builtin/pull.c::get_rebase_fork_point'
errors (no fork-point), then instead of 'incl_oid --not excl_oid' being
passed to setup_revisions, only 'incl_oid' is passed, and
'submodule_touches_in_range' examines 'incl_oid' and all its ancestors
to verify that they do not touch the submodule.
In test 5572.63, the recreated lone root commit in the local repository is
thus the only commit being examined by 'submodule_touches_in_range', and
this commit *adds* the submodule. However, 'submodule_touches_in_range'
*succeeds* because 'combine-diff.c::diff_tree_combined' (see the
backtrace below) returns early since this commit is the root commit
and has no parents.
#0 diff_tree_combined at combine-diff.c:1494
#1 0x0000000100150cbe in diff_tree_combined_merge at combine-diff.c:1649
#2 0x00000001002c7147 in collect_changed_submodules at submodule.c:869
#3 0x00000001002c7d6f in submodule_touches_in_range at submodule.c:1268
#4 0x00000001000ad58b in cmd_pull at builtin/pull.c:1040
In light of all this, add a note in t5572 documenting this peculiar
test.
[1] https://lore.kernel.org/git/20180524204729.19896-1-jonathantanmy@google.com/t/#u
Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-14 00:34:43 +00:00
|
|
|
# NOTE:
|
|
|
|
#
|
|
|
|
# This test is particular because there is only a single commit in the upstream superproject
|
|
|
|
# 'parent' (which adds the submodule 'a-submodule'). The clone of the superproject
|
|
|
|
# ('child') hard-resets its branch to a new root commit with the same tree as the one
|
|
|
|
# from the upstream superproject, so that its branch has no merge-base with its
|
|
|
|
# remote-tracking counterpart, and then calls 'git pull --recurse-submodules --rebase'.
|
|
|
|
# The result is that the local branch is reset to the remote-tracking branch (as it was
|
|
|
|
# originally before the hard-reset).
|
|
|
|
|
|
|
|
# The only commit in the range generated by 'submodule.c::submodule_touches_in_range' and
|
|
|
|
# passed to 'submodule.c::collect_changed_submodules' is the new (regenerated) initial commit,
|
|
|
|
# which adds the submodule.
|
|
|
|
# However, 'submodule_touches_in_range' does not error (even though this commit adds the submodule)
|
|
|
|
# because 'combine-diff.c::diff_tree_combined' returns early, as the initial commit has no parents.
|
2018-05-24 20:47:29 +00:00
|
|
|
test_expect_success 'branch has no merge base with remote-tracking counterpart' '
|
|
|
|
rm -rf parent child &&
|
|
|
|
|
|
|
|
test_create_repo a-submodule &&
|
|
|
|
test_commit -C a-submodule foo &&
|
|
|
|
|
|
|
|
test_create_repo parent &&
|
|
|
|
git -C parent submodule add "$(pwd)/a-submodule" &&
|
|
|
|
git -C parent commit -m foo &&
|
|
|
|
|
|
|
|
git clone parent child &&
|
|
|
|
|
2021-01-25 22:19:18 +00:00
|
|
|
# Reset the current branch so that it has no merge base with
|
|
|
|
# the remote-tracking branch.
|
2018-05-24 20:47:29 +00:00
|
|
|
OTHER=$(git -C child commit-tree -m bar \
|
|
|
|
$(git -C child rev-parse HEAD^{tree})) &&
|
|
|
|
git -C child reset --hard "$OTHER" &&
|
|
|
|
|
|
|
|
git -C child pull --recurse-submodules --rebase
|
|
|
|
'
|
|
|
|
|
2014-06-15 17:02:47 +00:00
|
|
|
test_done
|