1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-10-30 13:57:54 +01:00
git/t/t5572-pull-submodule.sh

136 lines
3.8 KiB
Bash
Raw Normal View History

#!/bin/sh
test_description='pull can handle submodules'
. ./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" &&
git pull
}
# pulls without conflicts
test_submodule_switch "git_pull"
git_pull_ff () {
reset_branch_to_HEAD "$1" &&
git pull --ff
}
test_submodule_switch "git_pull_ff"
git_pull_ff_only () {
reset_branch_to_HEAD "$1" &&
git pull --ff-only
}
test_submodule_switch "git_pull_ff_only"
git_pull_noff () {
reset_branch_to_HEAD "$1" &&
git pull --no-ff
}
KNOWN_FAILURE_NOFF_MERGE_DOESNT_CREATE_EMPTY_SUBMODULE_DIR=1
KNOWN_FAILURE_NOFF_MERGE_ATTEMPTS_TO_MERGE_REMOVED_SUBMODULE_FILES=1
test_submodule_switch "git_pull_noff"
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 21:13:02 +02: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
'
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
'
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 21:13:02 +02:00
test_expect_success 'recursive rebasing pull' '
# 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
'
test_expect_success 'pull rebase recursing fails with conflicts' '
# 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 &&
test_i18ngrep "locally recorded submodule modifications" err
'
test_done