This project is mirrored from Updated .
  1. 13 Oct, 2011 2 commits
    • Brad King's avatar
      submodule: Search for merges only at end of recursive merge · 80988783
      Brad King authored
      The submodule merge search is not useful during virtual merges because
      the results cannot be used automatically.  Furthermore any suggestions
      made by the search may apply to commits different than HEAD:sub and
      MERGE_HEAD:sub, thus confusing the user.  Skip searching for submodule
      merges during a virtual merge such as that between B and C while merging
      the heads of:
         / \ /
        A   X
         \ / \
      Run the search only when the recursion level is zero (!o->call_depth).
      This fixes known breakage tested in t7405-submodule-merge.
      Signed-off-by: Brad King's avatarBrad King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Brad King's avatar
      submodule: Demonstrate known breakage during recursive merge · 72251b7d
      Brad King authored
      Since commit 68d03e4a (Implement automatic fast-forward merge for
      submodules, 2010-07-07) we try to suggest submodule commits that resolve
      a conflict.  Consider a true recursive merge case
         / \ /
        o   X
         \ / \
      in which the two heads themselves (bc,cb) had resolved a submodule
      conflict (i.e. reference different commits than their parents).  The
      submodule merge search runs during the temporary merge of the two merge
      bases (b,c) and prints out a suggestion that is not meaningful to the
      user.  Then during the main merge the submodule merge search runs again
      but dies with the message
        fatal: --ancestry-path given but there are no bottom commits
      while trying to enumerate candidates.  Demonstrate this known breakage
      with a new test in t7405-submodule-merge covering the case.
      Signed-off-by: Brad King's avatarBrad King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  2. 31 Mar, 2011 1 commit
    • Nicolas Morey-Chaisemartin's avatar
      submodule: process conflicting submodules only once · 313ee0d6
      Nicolas Morey-Chaisemartin authored
      During a merge module_list returns conflicting submodules several times
      (stage 1,2,3) which caused the submodules to be used multiple times in
      git submodule init, sync, update and status command.
      There are 5 callers of module_list; they all read (mode, sha1, stage,
      path) tuple, and most of them care only about path.  As a first level
      approximation, it should be Ok (in the sense that it does not make things
      worse than it currently is) to filter the duplicate paths from module_list
      output, but some callers should change their behaviour when the merge in
      the superproject still has conflicts.
      Notice the higher-stage entries, and emit only one record from
      module_list, but while doing so, mark the entry with "U" (not [0-3]) in
      the $stage field and null out the SHA-1 part, as the object name for the
      lowest stage does not give any useful information to the caller, and this
      way any caller that uses the object name would hopefully barf.  Then
      update the codepaths for each subcommands this way:
       - "update" should not touch the submodule repository, because we do not
         know what commit should be checked out yet.
       - "status" reports the conflicting submodules as 'U000...000' and does
         not recurse into them (we might later want to make it recurse).
       - The command called by "foreach" may want to do whatever it wants to do
         by noticing the merged status in the superproject itself, so feed the
         path to it from module_list as before, but only once per submodule.
       - "init" and "sync" are unlikely things to do while the superproject is
         still not merged, but as long as a submodule is there in $path, there
         is no point skipping it. It might however want to take the merged
         status of .gitmodules into account, but that is outside of the scope of
         this topic.
      Acked-by: default avatarJens Lehmann <[email protected]>
      Thanks-to: Junio C Hamano <[email protected]>
      Signed-off-by: Nicolas Morey-Chaisemartin's avatarNicolas Morey-Chaisemartin <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  3. 03 Sep, 2010 1 commit
  4. 07 Jul, 2010 2 commits
    • Heiko Voigt's avatar
      Implement automatic fast-forward merge for submodules · 68d03e4a
      Heiko Voigt authored
      This implements a simple merge strategy for submodule hashes. We check
      whether one side of the merge candidates is already contained in the
      other and then merge automatically.
      If both sides contain changes we search for a merge in the submodule.
      In case a single one exists we check that out and suggest it as the
      merge resolution. A list of candidates is returned when we find multiple
      merges that contain both sides of the changes.
      This is useful for a workflow in which the developers can publish topic
      branches in submodules and a separate maintainer merges them. In case
      the developers always wait until their branch gets merged before tracking
      them in the superproject all merges of branches that contain submodule
      changes will be resolved automatically. If developers choose to track
      their feature branch the maintainer might get a conflict but git will
      search the submodule for a merge and suggest it/them as a resolution.
      Signed-off-by: Heiko Voigt's avatarHeiko Voigt <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Heiko Voigt's avatar
  5. 29 Apr, 2009 1 commit
  6. 05 Apr, 2009 2 commits