kernel/git - git - PowerEL Git System

Author	SHA1	Message	Date
Brad King	80988783c8	submodule: Search for merges only at end of recursive merge 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: B---BC / \ / A X \ / \ C---CB 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 <brad.king@kitware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Brad King	72251b7de6	submodule: Demonstrate known breakage during recursive merge 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 b---bc / \ / o X \ / \ c---cb 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 <brad.king@kitware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Nicolas Morey-Chaisemartin	313ee0d69f	submodule: process conflicting submodules only once 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: Jens Lehmann <Jens.Lehmann@web.de> Thanks-to: Junio C Hamano <gitster@pobox.com> Signed-off-by: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Jens Lehmann	1e2847634e	t7405: cd inside subshell instead of around Instead of using `cd dir && (...) && cd..` use `(cd dir && ...)` This ensures that the test doesn't get caught in the subdirectory if there is an error in the subshell. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Heiko Voigt	68d03e4a6e	Implement automatic fast-forward merge for submodules 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 <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Heiko Voigt	420432d434	add missing && to submodule-merge testcase Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Junio C Hamano	0c44c94309	merge-recursive: do not die on a conflicting submodule We cannot represent the 3-way conflicted state in the work tree for these entries, but it is normal not to have commit objects for them in our repository. Just update the index and the life will be good. Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Clemens Buchacher	0eb6574c24	update cache for conflicting submodule entries When merging merge bases during a recursive merge we do not want to leave any unmerged entries. Otherwise we cannot create a temporary tree for the recursive merge to work with. We failed to do so in case of a submodule conflict between merge bases, causing a NULL pointer dereference in the next step of the recursive merge. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Clemens Buchacher	f37ae35e73	add tests for merging with submodules Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago