kernel/git - git - PowerEL Git System

50186 Commits

6 Branches

36 Tags

131 MiB

Tree: ab66fc2705

Commit Graph

Author SHA1 Message Date

Author	SHA1	Message	Date
Nicolas Morey-Chaisemartin	121e43fa53	pull: honor submodule.recurse config option "git pull" supports a --recurse-submodules option but does not parse the submodule.recurse configuration item to set the default for that option. Meanwhile "git fetch" does support submodule.recurse, producing confusing behavior: when submodule.recurse is enabled, "git pull" recursively fetches submodules but does not update them after fetch. Handle submodule.recurse in "git pull" to fix this. Reported-by: Magnus Homann <magnus@homann.se> Signed-off-by: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Stefan Beller	a6d7eb2c7a	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>	8 years ago
Jens Lehmann	921f50b48e	pull: add t5572 for submodule updates Test that the pull command updates the work tree as expected (for submodule changes which don't result in conflicts) when used without arguments or with the '--ff', '--ff-only' and '--no-ff' flag each. Add helper functions to reset the branch to be updated to to the current HEAD so that pull is doing the transition from HEAD to the given branch. Set KNOWN_FAILURE_NOFF_MERGE_ATTEMPTS_TO_MERGE_REMOVED_SUBMODULE_FILES and KNOWN_FAILURE_NOFF_MERGE_DOESNT_CREATE_EMPTY_SUBMODULE_DIR to document that pull has the same --no-ff known failures merge has. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	11 years ago

Nicolas Morey-Chaisemartin

121e43fa53

pull: honor submodule.recurse config option

"git pull" supports a --recurse-submodules option but does not parse the
submodule.recurse configuration item to set the default for that option.
Meanwhile "git fetch" does support submodule.recurse, producing
confusing behavior: when submodule.recurse is enabled, "git pull"
recursively fetches submodules but does not update them after fetch.

Handle submodule.recurse in "git pull" to fix this.

Reported-by: Magnus Homann <magnus@homann.se>
Signed-off-by: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

8 years ago

Stefan Beller

a6d7eb2c7a

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>

8 years ago

Jens Lehmann

921f50b48e

pull: add t5572 for submodule updates

Test that the pull command updates the work tree as expected (for
submodule changes which don't result in conflicts) when used without
arguments or with the '--ff', '--ff-only' and '--no-ff' flag each. Add
helper functions to reset the branch to be updated to to the current
HEAD so that pull is doing the transition from HEAD to the given branch.

Set KNOWN_FAILURE_NOFF_MERGE_ATTEMPTS_TO_MERGE_REMOVED_SUBMODULE_FILES
and KNOWN_FAILURE_NOFF_MERGE_DOESNT_CREATE_EMPTY_SUBMODULE_DIR to
document that pull has the same --no-ff known failures merge has.

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

11 years ago

3 Commits (ab66fc2705b35833582d74a8cd90ac0cf7586f89)