{"thread":{"id":"26759","subject":"[PATCH] git-submodule: Remove duplicate entries during merge with conflict","startedAt":"2011-03-17T08:09:14Z","lastAt":"2011-07-15T21:41:41Z","messageCount":14,"participants":["Nicolas Morey-Chaisemartin","Junio C Hamano","Jens Lehmann","funeeldy","Marlene Cote"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"163541","messageId":"4D81C1AA.5010008@morey-chaisemartin.com","threadId":"26759","inReplyTo":null,"subject":"[PATCH] git-submodule: Remove duplicate entries during merge with conflict","fromName":"Nicolas Morey-Chaisemartin","fromEmail":"devel-git@morey-chaisemartin.com","sentAt":"2011-03-17T08:09:14Z","receivedAt":"2011-03-17T08:09:14Z","isPatch":true,"sender":{"key":"devel-git@morey-chaisemartin.com","avatar":"https://avatars.githubusercontent.com/u/108326?v=4"},"body":"During a merge with conflict on a submodule, the submodule appears 3 times in git ls-files (stage 1,2,3) which causes the submodule to be used 3 times in git submodule update or status command.\nThis patch filters the results of git ls-files and only shows submodule in stage 0 or 1 thus removing the duplicates.\n\nSigned-off-by: Nicolas Morey-Chaisemartin \n---\n git-submodule.sh | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 3a13397..5ef0f9d 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -72,7 +72,7 @@ resolve_relative_url ()\n #\n module_list()\n {\n-\tgit ls-files --error-unmatch --stage -- \"$@\" | sane_grep '^160000 '\n+\tgit ls-files --error-unmatch --stage -- \"$@\" | sane_grep '^160000 ' | awk '{ if (($3 == 0) || ($3 == 1)) print $0}'\n }\n \n #\n"},{"id":"163573","messageId":"7v1v254ma7.fsf@alter.siamese.dyndns.org","threadId":"26759","inReplyTo":"4D81C1AA.5010008@morey-chaisemartin.com","subject":"Re: [PATCH] git-submodule: Remove duplicate entries during merge with conflict","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-17T18:47:12Z","receivedAt":"2011-03-17T18:47:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Morey-Chaisemartin writes:\n\n> During a merge with conflict on a submodule, the submodule appears 3\n> times in git ls-files (stage 1,2,3) which causes the submodule to be\n> used 3 times in git submodule update or status command. This patch\n> filters the results of git ls-files and only shows submodule in stage 0\n> or 1 thus removing the duplicates.\n\nThat is a wrong thing to do. What if both sides added a submodule at the\nsame directory after forked from an ancestor that did not have it? You\nwill have only stage #2 and stage #3, no?\n"},{"id":"163592","messageId":"7vhbb1320t.fsf@alter.siamese.dyndns.org","threadId":"26759","inReplyTo":"7v1v254ma7.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git-submodule: Remove duplicate entries during merge with conflict","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-17T20:50:10Z","receivedAt":"2011-03-17T20:50:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Nicolas Morey-Chaisemartin writes:\n>\n>> During a merge with conflict on a submodule, the submodule appears 3\n>> times in git ls-files (stage 1,2,3) which causes the submodule to be\n>> used 3 times in git submodule update or status command. This patch\n>> filters the results of git ls-files and only shows submodule in stage 0\n>> or 1 thus removing the duplicates.\n>\n> That is a wrong thing to do. What if both sides added a submodule at the\n> same directory after forked from an ancestor that did not have it? You\n> will have only stage #2 and stage #3, no?\n\nIt is not very friendly to say a solution is wrong without hinting what\nthe right thing to do, so let's try.\n\nThere are 5 callers of module_list; they all read (mode, sha1, stage,\npath) tuple, and most of them care only about path. As a first level\napproximation, it should be Ok (in the sense that it does not make things\nworse than it currently is) to filter the duplicate paths from module_list\noutput.\n\nBut a bigger question is, shouldn't some callers _care_ when the\nsuperproject is still unmerged? What does it mean to say \"submodule\nupdate\" when your superproject is unmerged, you haven't resolved it so you\ndon't know if you are going to take the commit your branch points at, or\nthe commit their branch points at, or a commit completely different from\neither? If submodule.$name.update is set to detach and checkout the\ncommit registred at the superproject, which stage do you want to get the\ncommit to update the submodule with? If it is set to \"rebase\" or \"merge\",\nwhich stage do you take the commit to rebase/merge your history onto?\n\nI think \"update\" should not touch the submodule repository in such a case.\n\"status\" might want to recurse into the submodule repository, but there is\nno information at the superproject level to compare the submodule status\nagainst, so we should at least skip that part for submodule entries that\nare unmerged in the superproject.\n\nPerhaps something along the lines of (as usual, totally untested, just to\nillustrate the concept) the attached patch?\n\nThe idea is to notice the higher-stage entries, and emit only one record\nfrom module_list, but while doing so, mark the entry with \"U\" (not [0-3])\nin $stage field and null out the SHA-1 part, as the object name for the\nlowest stage does not give any useful information to the caller, and this\nway any caller that uses the object name would hopefully barf.\n\nFine points:\n\n - The command called by foreach may want to do whatever it wants to do by\n noticing the merged status in the superproject itself, so I made no\n change to the function;\n\n - Init is an unlikely thing to do, but as long as a submodule is there in\n $path, there is no point skipping it. It might however want to take the\n merged status of .gitmodules into account, but that is outside of the\n scope of this topic;\n\n - Update should refrain from touching the submodule itself. It may want\n to recurse into the submodule of the unmerged one, but people involved\n in submodule work should think things through;\n\n - Status does not have anything to report for an unmerged submodule. It\n may want to recurse into the submodule of the unmerged one, but people\n involved in submodule work should think things through; and\n\n - Sync should be Ok for the same reason as Init.\n\n\n\n git-submodule.sh | 29 ++++++++++++++++++++++++++++-\n 1 files changed, 28 insertions(+), 1 deletions(-)\n\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 3a13397..8ecd311 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -72,7 +72,24 @@ resolve_relative_url ()\n #\n module_list()\n {\n-\tgit ls-files --error-unmatch --stage -- \"$@\" | sane_grep '^160000 '\n+\tgit ls-files --error-unmatch --stage -- \"$@\" |\n+\tperl -e '\n+\tmy %unmerged = ();\n+\tmy ($null_sha1) = (\"0\" x 40);\n+\twhile () {\n+\t\tchomp;\n+\t\tmy ($mode, $sha1, $stage, $path) =\n+\t\t\t/^([0-7]+) ([0-9a-f]{40}) ([0-3])\\t(.*)$/;\n+\t\tnext unless $mode eq \"160000\";\n+\t\tif ($stage ne \"0\") {\n+\t\t\tif (!$unmerged{$path}++) {\n+\t\t\t\tprint \"$mode $null_sha1 U\\t$path\\n\";\n+\t\t\t}\n+\t\t\tnext;\n+\t\t}\n+\t\tprint \"$_\\n\";\n+\t}\n+\t'\n }\n \n #\n@@ -427,6 +444,11 @@ cmd_update()\n \tmodule_list \"$@\" |\n \twhile read mode sha1 stage path\n \tdo\n+\t\tif test \"$stage\" = U\n+\t\tthen\n+\t\t\techo >&2 \"Skipping unmerged submodule $path\"\n+\t\t\tcontinue\n+\t\tfi\n \t\tname=$(module_name \"$path\") || exit\n \t\turl=$(git config submodule.\"$name\".url)\n \t\tupdate_module=$(git config submodule.\"$name\".update)\n@@ -767,6 +789,11 @@ cmd_status()\n \tmodule_list \"$@\" |\n \twhile read mode sha1 stage path\n \tdo\n+\t\tif test \"$stage\" = U\n+\t\tthen\n+\t\t\techo >&2 \"Skipping unmerged submodule $path\"\n+\t\t\tcontinue\n+\t\tfi\n \t\tname=$(module_name \"$path\") || exit\n \t\turl=$(git config submodule.\"$name\".url)\n \t\tdisplaypath=\"$prefix$path\"\n"},{"id":"163873","messageId":"4D870FAB.4050307@morey-chaisemartin.com","threadId":"26759","inReplyTo":"7vhbb1320t.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git-submodule: Remove duplicate entries during merge with conflict","fromName":"Nicolas Morey-Chaisemartin","fromEmail":"devel-git@morey-chaisemartin.com","sentAt":"2011-03-21T08:43:23Z","receivedAt":"2011-03-21T08:43:23Z","isPatch":true,"sender":{"key":"devel-git@morey-chaisemartin.com","avatar":"https://avatars.githubusercontent.com/u/108326?v=4"},"body":"On 03/17/2011 09:50 PM, Junio C Hamano wrote:\n> Junio C Hamano writes:\n>\n>> Nicolas Morey-Chaisemartin writes:\n>>\n>>> During a merge with conflict on a submodule, the submodule appears 3\n>>> times in git ls-files (stage 1,2,3) which causes the submodule to be\n>>> used 3 times in git submodule update or status command. This patch\n>>> filters the results of git ls-files and only shows submodule in stage 0\n>>> or 1 thus removing the duplicates.\n>> That is a wrong thing to do. What if both sides added a submodule at the\n>> same directory after forked from an ancestor that did not have it? You\n>> will have only stage #2 and stage #3, no?\nAfter a quick check, you're right on that ;)\n> It is not very friendly to say a solution is wrong without hinting what\n> the right thing to do, so let's try.\n\nThanks for taking the time to point me in the right direction !\n> There are 5 callers of module_list; they all read (mode, sha1, stage,\n> path) tuple, and most of them care only about path. As a first level\n> approximation, it should be Ok (in the sense that it does not make things\n> worse than it currently is) to filter the duplicate paths from module_list\n> output.\n>\n...\n> - Status does not have anything to report for an unmerged submodule. It\n> may want to recurse into the submodule of the unmerged one, but people\n> involved in submodule work should think things through; and\n>\nI agree that the actual behavior of status is definitely wrong and it should be changed.\nBut I think there needs to be a simple way for a user to know whats happening to a conflicted submodule.\nWhen merging a file, editing the conflicting area in the code is often enough.\nFor a submodule, I think the user needs an easy access to which branch used what SHA1.\n\nGit submodule status is probably not the right place to do that.\ngit ls-files --stage allows that but it's not part of the standard porcelain commands...\n\nI guess a first step should be to apply the patch you proposed and discuss a later solution to get the submodule SHA1 (well except if there's already one I just don't know about !)\n\nI'll check/test the patch you proposed as soon as possible and repost it if it's allright !\n\nNicolas Morey-Chaisemartin\n"},{"id":"163976","messageId":"4D87B51A.4060609@web.de","threadId":"26759","inReplyTo":"7vhbb1320t.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git-submodule: Remove duplicate entries during merge with conflict","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-03-21T20:29:14Z","receivedAt":"2011-03-21T20:29:14Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 17.03.2011 21:50, schrieb Junio C Hamano:\n> The idea is to notice the higher-stage entries, and emit only one record\n> from module_list, but while doing so, mark the entry with \"U\" (not [0-3])\n> in $stage field and null out the SHA-1 part, as the object name for the\n> lowest stage does not give any useful information to the caller, and this\n> way any caller that uses the object name would hopefully barf.\n\nExcellent idea.\n\n> Fine points:\n> \n> - The command called by foreach may want to do whatever it wants to do by\n> noticing the merged status in the superproject itself, so I made no\n> change to the function;\n> \n> - Init is an unlikely thing to do, but as long as a submodule is there in\n> $path, there is no point skipping it. It might however want to take the\n> merged status of .gitmodules into account, but that is outside of the\n> scope of this topic;\n\nBoth make sense.\n\n> - Update should refrain from touching the submodule itself. It may want\n> to recurse into the submodule of the unmerged one, but people involved\n> in submodule work should think things through;\n\nI don't think recursing would make any sense here. It might be unknown\nto what commit the sub-submodules should be updated to if their commits\ndiffer in the unmerged branches. So I'd vote for not recursing at all in\nthis case (which is what your patch does).\n\n> - Status does not have anything to report for an unmerged submodule. It\n> may want to recurse into the submodule of the unmerged one, but people\n> involved in submodule work should think things through; and\n\nI do think status does have something to report here. First its job is to\nlist all submodules, so currently unmerged submodules should show up too,\nand then it tells the user something about the state of the submodule. So\nI would propose to print a line for the submodule starting with a special\ncharacter that tells the user the submodule has a merge conflict. We\ncould e.g. use a '*' here (additionally to '-' for uninitialized and '+'\nfor those submodules where the HEAD differs from the commit recorded in\nthe superproject).\n\n> - Sync should be Ok for the same reason as Init.\n\nYup.\n\n\n\n\n> @@ -767,6 +789,11 @@ cmd_status()\n> \tmodule_list \"$@\" |\n> \twhile read mode sha1 stage path\n> \tdo\n> +\t\tif test \"$stage\" = U\n> +\t\tthen\n> +\t\t\techo >&2 \"Skipping unmerged submodule $path\"\n\nAs said above I would like to mimic the output for other submodule\nstates here. Maybe something like this (where $sha1 will expand to\nthe null sha as we don't have anything better here):\n\n+\t\t\tsay \"*$sha1 $prefix$path\"\n\n> +\t\t\tcontinue\n> +\t\tfi\n> \t\tname=$(module_name \"$path\") || exit\n> \t\turl=$(git config submodule.\"$name\".url)\n> \t\tdisplaypath=\"$prefix$path\"\n"},{"id":"163982","messageId":"4D87BAC7.4010505@web.de","threadId":"26759","inReplyTo":"4D870FAB.4050307@morey-chaisemartin.com","subject":"Re: [PATCH] git-submodule: Remove duplicate entries during merge with conflict","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-03-21T20:53:27Z","receivedAt":"2011-03-21T20:53:27Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 21.03.2011 09:43, schrieb Nicolas Morey-Chaisemartin:\n> I agree that the actual behavior of status is definitely wrong and it should be changed.\n\nYup.\n\n> But I think there needs to be a simple way for a user to know whats happening to a conflicted submodule.\n> When merging a file, editing the conflicting area in the code is often enough.\n> For a submodule, I think the user needs an easy access to which branch used what SHA1.\n\nYou can see the sha1s using \"git diff\":\n\ndiff --cc submod\nindex bd4cfe7,7128fbd..0000000\n--- a/submod\n+++ b/submod\n\n(But the sha1s don't tell you much about what differing commits you\nhave in the submodule branches, which would be really helpful for\ndeciding how to solve the merge conflict. Unfortunately \"git diff\n--submodule\" doesn't work for merge conflicts yet, another issue on\nmy ToDo-list ...)\n\n> Git submodule status is probably not the right place to do that.\n\nI agree.\n\n> git ls-files --stage allows that but it's not part of the standard porcelain commands...\n\nAnd it shows you three sha1s, one of them being the current state of\nthe submodule. Me thinks the output of \"git diff\" is easier to digest.\n\n> I'll check/test the patch you proposed as soon as possible and repost it if it's allright !\n\nCool!\n"},{"id":"163984","messageId":"7voc54nqak.fsf@alter.siamese.dyndns.org","threadId":"26759","inReplyTo":"4D87B51A.4060609@web.de","subject":"Re: [PATCH] git-submodule: Remove duplicate entries during merge with conflict","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-21T20:59:15Z","receivedAt":"2011-03-21T20:59:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann writes:\n\n> I do think status does have something to report here. First its job is to\n> list all submodules, so currently unmerged submodules should show up too,\n> and then it tells the user something about the state of the submodule. So\n> I would propose to print a line for the submodule starting with a special\n> character that tells the user the submodule has a merge conflict. We\n> could e.g. use a '*' here (additionally to '-' for uninitialized and '+'\n> for those submodules where the HEAD differs from the commit recorded in\n> the superproject).\n\nThanks.\n\nAs everybody knows, you are a lot more deeply involved in this than I do,\nso please take the discussion and implementation from here. For example,\nI don't know if '*' or 'U' is more intuitive, and I'd rather not have to\nmake such decisions ;-)\n"},{"id":"163986","messageId":"4D87C467.3090907@morey-chaisemartin.com","threadId":"26759","inReplyTo":"4D87B51A.4060609@web.de","subject":"Re: [PATCH] git-submodule: Remove duplicate entries during merge with conflict","fromName":"Nicolas Morey-Chaisemartin","fromEmail":"devel-git@morey-chaisemartin.com","sentAt":"2011-03-21T21:34:31Z","receivedAt":"2011-03-21T21:34:31Z","isPatch":true,"sender":{"key":"devel-git@morey-chaisemartin.com","avatar":"https://avatars.githubusercontent.com/u/108326?v=4"},"body":"On 21/03/2011 21:29, Jens Lehmann wrote:\n> \n>> - Update should refrain from touching the submodule itself. It may want\n>> to recurse into the submodule of the unmerged one, but people involved\n>> in submodule work should think things through;\n> \n> I don't think recursing would make any sense here. It might be unknown\n> to what commit the sub-submodules should be updated to if their commits\n> differ in the unmerged branches. So I'd vote for not recursing at all in\n> this case (which is what your patch does).\n> \n\nAfter a bit of thinking about the way we use git at my company, there is something that could be done here. It may be completely useless for most people (or maybe even stupid and feel free to enlighten me!)\nWe work with continuous integration on two level of git (1 integration which only has submodules and lots of source repositories).\nThe usual thing when a user want to push its diff is:\n- commit in the submodules on his branch\n- Update the submodules refs in the integration repo on his branch\n- Pull master \n- See there are conflicts\n- Blindly pull master in all the conflicted submodules. Push the merge\n- Commit in the integration repo and pray it works !\n\nAlthough in the scheme git submodule update by itself does not make much sense. What people actually do is pretty much a git submodule update --merge of the conflicting SHA1 for each submodule.\n\nFor the moment we used either ruby scripts or a list of commands that users blindly follows without understanding much of it, and seeing something like that (there's probably a nicest way to do it) in git would be great.\n\n>> - Status does not have anything to report for an unmerged submodule. It\n>> may want to recurse into the submodule of the unmerged one, but people\n>> involved in submodule work should think things through; and\n> \n> I do think status does have something to report here. First its job is to\n> list all submodules, so currently unmerged submodules should show up too,\n> and then it tells the user something about the state of the submodule. So\n> I would propose to print a line for the submodule starting with a special\n> character that tells the user the submodule has a merge conflict. We\n> could e.g. use a '*' here (additionally to '-' for uninitialized and '+'\n> for those submodules where the HEAD differs from the commit recorded in\n> the superproject).\n> \nBeing a big user of __git_ps1, my brain now considers '*' has uncached diff and '+' has cached diff. I'd rather have something as 'U' that stands outs. But I like the idea any way !\n\nNicolas Morey-Chaisemartin\n"},{"id":"163990","messageId":"4D87CAC4.2010001@web.de","threadId":"26759","inReplyTo":"4D87C467.3090907@morey-chaisemartin.com","subject":"Re: [PATCH] git-submodule: Remove duplicate entries during merge with conflict","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-03-21T22:01:40Z","receivedAt":"2011-03-21T22:01:40Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 21.03.2011 22:34, schrieb Nicolas Morey-Chaisemartin:\n> On 21/03/2011 21:29, Jens Lehmann wrote:\n>>\n>>> - Update should refrain from touching the submodule itself. It may want\n>>> to recurse into the submodule of the unmerged one, but people involved\n>>> in submodule work should think things through;\n>>\n>> I don't think recursing would make any sense here. It might be unknown\n>> to what commit the sub-submodules should be updated to if their commits\n>> differ in the unmerged branches. So I'd vote for not recursing at all in\n>> this case (which is what your patch does).\n>>\n> \n> After a bit of thinking about the way we use git at my company, there is something that could be done here. It may be completely useless for most people (or maybe even stupid and feel free to enlighten me!)\n> We work with continuous integration on two level of git (1 integration which only has submodules and lots of source repositories).\n> The usual thing when a user want to push its diff is:\n> - commit in the submodules on his branch\n> - Update the submodules refs in the integration repo on his branch\n> - Pull master \n> - See there are conflicts\n> - Blindly pull master in all the conflicted submodules. Push the merge\n> - Commit in the integration repo and pray it works !\n> \n> Although in the scheme git submodule update by itself does not make much sense. What people actually do is pretty much a git submodule update --merge of the conflicting SHA1 for each submodule.\n> \n> For the moment we used either ruby scripts or a list of commands that users blindly follows without understanding much of it, and seeing something like that (there's probably a nicest way to do it) in git would be great.\n\nHmm, I'm not sure if I fully understand your use case. Maybe being able\nto tell pull to run a \"git merge \" in submodules\nwhere the superproject's merge produced conflicts would help you?\n\n>>> - Status does not have anything to report for an unmerged submodule. It\n>>> may want to recurse into the submodule of the unmerged one, but people\n>>> involved in submodule work should think things through; and\n>>\n>> I do think status does have something to report here. First its job is to\n>> list all submodules, so currently unmerged submodules should show up too,\n>> and then it tells the user something about the state of the submodule. So\n>> I would propose to print a line for the submodule starting with a special\n>> character that tells the user the submodule has a merge conflict. We\n>> could e.g. use a '*' here (additionally to '-' for uninitialized and '+'\n>> for those submodules where the HEAD differs from the commit recorded in\n>> the superproject).\n>>\n> Being a big user of __git_ps1, my brain now considers '*' has uncached diff and '+' has cached diff. I'd rather have something as 'U' that stands outs.\n\nThat is a good argument against '*'. I don't have strong feelings about\nthat, I just came up with '*' because \"git submodule status\" already uses\n'-' and '+' in it's output. But anyways, 'U' is fine for me too.\n"},{"id":"164014","messageId":"4D884174.6070700@morey-chaisemartin.com","threadId":"26759","inReplyTo":"4D87CAC4.2010001@web.de","subject":"Re: [PATCH] git-submodule: Remove duplicate entries during merge with conflict","fromName":"Nicolas Morey-Chaisemartin","fromEmail":"devel-git@morey-chaisemartin.com","sentAt":"2011-03-22T06:28:04Z","receivedAt":"2011-03-22T06:28:04Z","isPatch":true,"sender":{"key":"devel-git@morey-chaisemartin.com","avatar":"https://avatars.githubusercontent.com/u/108326?v=4"},"body":"On 21/03/2011 23:01, Jens Lehmann wrote:\n> Hmm, I'm not sure if I fully understand your use case. Maybe being able\n> to tell pull to run a \"git merge \" in submodules\n> where the superproject's merge produced conflicts would help you?\n> \n\nIn short yes. And if it could be recursive (if a conflicting submodules has conflicting submodules) that would be great !\nAnd yes git-merge is probably a better place to do something like that than git submodule update.\n\n> That is a good argument against '*'. I don't have strong feelings about\n> that, I just came up with '*' because \"git submodule status\" already uses\n> '-' and '+' in it's output. But anyways, 'U' is fine for me too.\n> \n\nOK. I'll integrate that with the patch Junio proposed then.\n\nNicolas\n"},{"id":"171354","messageId":"1310668419989-6584432.post@n2.nabble.com","threadId":"26759","inReplyTo":"4D81C1AA.5010008@morey-chaisemartin.com","subject":"Re: [PATCH] git-submodule: Remove duplicate entries during merge with conflict","fromName":"funeeldy","fromEmail":"marlene_cote@affirmednetworks.com","sentAt":"2011-07-14T18:33:39Z","receivedAt":"2011-07-14T18:33:39Z","isPatch":true,"sender":{"key":"marlene_cote@affirmednetworks.com","avatar":null},"body":"How can new users of git submodules learn about merge conflicts? When and\nwhy they occur, and how to resolve them in a way that doesn't lose commits? \nIf I have to choose my version or their version, that isn't really a merge,\nor is it?\nThanks.\n\n--\nView this message in context: http://git.661346.n2.nabble.com/PATCH-git-submodule-Remove-duplicate-entries-during-merge-with-conflict-tp6180061p6584432.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"171421","messageId":"4E2094B4.3090009@web.de","threadId":"26759","inReplyTo":"1310668419989-6584432.post@n2.nabble.com","subject":"Re: [PATCH] git-submodule: Remove duplicate entries during merge with conflict","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-07-15T19:27:48Z","receivedAt":"2011-07-15T19:27:48Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 14.07.2011 20:33, schrieb funeeldy:\n> How can new users of git submodules learn about merge conflicts? When and\n> why they occur, and how to resolve them in a way that doesn't lose commits? \n\nThat is pretty similar to merge conflicts in regular files: They happen\nwhen you merge two branches where both sides changed the recorded submodule\ncommit to another one (and those are not the same). The resolution can be\ndone by finding a submodule commit that has both changes. In most cases that\nwill be based on a merge (maybe even a fast forward) with both commits in\nits history.\n\nIf git finds a fast forward from the merge base to commit1 and commit2\n(let's say they both are on master and newer than the merge base), the\nnewer one is picked automatically. If git finds a single merge from which\nboth commits are reachable, it proposes that as conflict resolution and\ntells you how you can stage that. Only if it doesn't find any or more\nthan two merges, you are on your own and have to resolve the conflict\nmanually by finding an appropriate commit.\n\n> If I have to choose my version or their version, that isn't really a merge,\n> or is it?\n\nIt would be if the merge strategy is \"ours\" or \"theirs\". But in most normal\ncases you would want to have both commits reachable from the merge result.\n"},{"id":"171432","messageId":"1F026B57884A5841B330471696849DE9113122B5@MBX021-W4-CA-5.exch021.domain.local","threadId":"26759","inReplyTo":"4E2094B4.3090009@web.de","subject":"RE: [PATCH] git-submodule: Remove duplicate entries during merge with conflict","fromName":"Marlene Cote","fromEmail":"marlene_cote@affirmednetworks.com","sentAt":"2011-07-15T20:32:59Z","receivedAt":"2011-07-15T20:32:59Z","isPatch":true,"sender":{"key":"marlene_cote@affirmednetworks.com","avatar":null},"body":"How would you find an appropriate commit?\n\n--------------------------\nRegards,\nMarlene Cote\nAffirmed Networks\n978-268-0821 \n\n\n->-----Original Message-----\n->From: Jens.Lehmann@web.de [mailto:Jens.Lehmann@web.de]\n->Sent: Friday, July 15, 2011 3:28 PM\n->To: Marlene Cote\n->Cc: git@vger.kernel.org\n->Subject: Re: [PATCH] git-submodule: Remove duplicate entries during merge with conflict\n->\n->Am 14.07.2011 20:33, schrieb funeeldy:\n->> How can new users of git submodules learn about merge conflicts? When and\n->> why they occur, and how to resolve them in a way that doesn't lose commits?\n->\n->That is pretty similar to merge conflicts in regular files: They happen\n->when you merge two branches where both sides changed the recorded submodule\n->commit to another one (and those are not the same). The resolution can be\n->done by finding a submodule commit that has both changes. In most cases that\n->will be based on a merge (maybe even a fast forward) with both commits in\n->its history.\n->\n->If git finds a fast forward from the merge base to commit1 and commit2\n->(let's say they both are on master and newer than the merge base), the\n->newer one is picked automatically. If git finds a single merge from which\n->both commits are reachable, it proposes that as conflict resolution and\n->tells you how you can stage that. Only if it doesn't find any or more\n->than two merges, you are on your own and have to resolve the conflict\n->manually by finding an appropriate commit.\n->\n->> If I have to choose my version or their version, that isn't really a merge,\n->> or is it?\n->\n->It would be if the merge strategy is \"ours\" or \"theirs\". But in most normal\n->cases you would want to have both commits reachable from the merge result.\n"},{"id":"171443","messageId":"4E20B415.8030004@web.de","threadId":"26759","inReplyTo":"1F026B57884A5841B330471696849DE9113122B5@MBX021-W4-CA-5.exch021.domain.local","subject":"Re: [PATCH] git-submodule: Remove duplicate entries during merge with conflict","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-07-15T21:41:41Z","receivedAt":"2011-07-15T21:41:41Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 15.07.2011 22:32, schrieb Marlene Cote:\n> How would you find an appropriate commit?\n\nThe same way you resolve conflicts for a regular file: If you are unlucky\nand the merge strategy doesn't resolve the conflict for you automatically\n(or at least gives you a hint what /could/ be the resolution), you have\nto use human judgment to find an appropriate resolution. In most cases\nthat will be a commit where both conflicting commits show up in the\nhistory (and maybe you'll even have to create one yourself by doing a\nproper merge in the submodule).\n\nWhere I work we have a simple best practice that guarantees us git will\nalways find a proper resolution itself: We only record commits that are\non the submodules master branch in the superproject. To put it in other\nwords: merge the submodule first before you commit in the superproject.\n"}]}