{"thread":{"id":"26765","subject":"gut submodule update and merge","startedAt":"2011-03-17T20:16:47Z","lastAt":"2011-03-18T14:13:24Z","messageCount":2,"participants":["Carl Fürstenberg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"163591","messageId":"AANLkTimneYSkr11yDt1eL5d-r6pJrt2EMLGEOBfOxOoD@mail.gmail.com","threadId":"26765","inReplyTo":null,"subject":"gut submodule update and merge","fromName":"Carl Fürstenberg","fromEmail":"azatoth@gmail.com","sentAt":"2011-03-17T20:16:47Z","receivedAt":"2011-03-17T20:16:47Z","isPatch":false,"sender":{"key":"azatoth@gmail.com","avatar":"https://gravatar.com/avatar/0fc9395b8ebd847c13aff2af7b18661fa677054257d81a894c5ecc1c0a72a7cb?d=mp&s=160"},"body":"Hello,\n\nI've tried to setup in a n makefile a way to easy initialize and\nupdate submodules and at the same time keep eventual changes in the\nsubmodules. I though an \"git submodule update --init --recursive\n--merge\" would work,\nbut  this i notices created strange result if the submodules hadn't\nbeen checked out in the first place. the result then was that it\nmarked in index all files to be deleted.\n\nThis behavior wasn't what I had in mind, and it resulted in I did\nfollowing \"fix\" to resolve the issue (ugly):\nhttps://github.com/azatoth/jquery/commit/9977732a26820dd7f3ced2ce4554edadd62ae52c\n\nIs this the intended behavior? logically I think an clean \"git\nsubmodule update --init --merge\" should not try to merge if there\nwasn't anything to begin with.\n\n/Carl\n"},{"id":"163636","messageId":"AANLkTinK_ftV7rCHM2Q0PNRZQXLwCRzfoqogb=dkzXZM@mail.gmail.com","threadId":"26765","inReplyTo":"AANLkTimneYSkr11yDt1eL5d-r6pJrt2EMLGEOBfOxOoD@mail.gmail.com","subject":"Re: gut submodule update and merge","fromName":"Carl Fürstenberg","fromEmail":"azatoth@gmail.com","sentAt":"2011-03-18T14:13:24Z","receivedAt":"2011-03-18T14:13:24Z","isPatch":false,"sender":{"key":"azatoth@gmail.com","avatar":"https://gravatar.com/avatar/0fc9395b8ebd847c13aff2af7b18661fa677054257d81a894c5ecc1c0a72a7cb?d=mp&s=160"},"body":"2011/3/17 Carl Fürstenberg <azatoth@gmail.com>:\n> Hello,\n>\n> I've tried to setup in a n makefile a way to easy initialize and\n> update submodules and at the same time keep eventual changes in the\n> submodules. I though an \"git submodule update --init --recursive\n> --merge\" would work,\n> but  this i notices created strange result if the submodules hadn't\n> been checked out in the first place. the result then was that it\n> marked in index all files to be deleted.\n>\n> This behavior wasn't what I had in mind, and it resulted in I did\n> following \"fix\" to resolve the issue (ugly):\n> https://github.com/azatoth/jquery/commit/9977732a26820dd7f3ced2ce4554edadd62ae52c\n>\n> Is this the intended behavior? logically I think an clean \"git\n> submodule update --init --merge\" should not try to merge if there\n> wasn't anything to begin with.\n>\n> /Carl\n>\n\nIf my question wasn't clear I'm sorry, All I'm wondering is if using\n--merge when cloning an new submodule should behave this way or not. I\ndon't think most peoples intentions when using merge on an\nnon-existent repo should be to delete all file :)\n\n/Carl\n"}]}