{"thread":{"id":"44410","subject":"Submodules: two confusing situations","startedAt":"2016-11-01T22:13:42Z","lastAt":"2016-11-01T22:56:17Z","messageCount":2,"participants":["David Turner","Stefan Beller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"305274","messageId":"6533af94ebd74952b75e51c5609d8c20@exmbdft7.ad.twosigma.com","threadId":"44410","inReplyTo":null,"subject":"Submodules: two confusing situations","fromName":"David Turner","fromEmail":"david.turner@twosigma.com","sentAt":"2016-11-01T22:13:18Z","receivedAt":"2016-11-01T22:13:42Z","isPatch":false,"sender":{"key":"david.turner@twosigma.com","avatar":null},"body":"Consider the following two cases:\n\nWe have commit X and commit Y.  X is an ancestor of Y.\n\nWe're at X and doing get checkout Y -- or we're at Y and we're doing\ngit checkout X.\n\nCase 1: Between X and Y, we have deleted a submodule.\nIn order to move from X to Y, git removes the submodule\nfrom the working tree.\n\nCase 2: Between X and Y, we have instead added a submodule.  In order\nto move from Y to X (that is, the opposite direction), git *does not*\nremove the submodule from the tree; instead, it gives a warning and\nleaves the submodule behind.\n\nI don't understand why these two cases are not symmetric.\n\n-- \n\nPerhaps relatedly, consider the attached shell-script, which I have not yet made into a full git test because I'm not sure I understand the issues fully.\n\nIt creates three commits:\n\nCommit 1 adds a submodule\nCommit 2 removes that submodule and re-adds it into a subdirectory (sub1 to sub1/sub1).\nCommit 3 adds an unrelated file.\n\nThen it checks out commit 1 (first deinitializing the submodule to avoid case 2 above), and attempts to cherry-pick commit 3.  This seems like it ought to work, based on my understanding of cherry-pick.  But in fact it gives a conflict on the stuff from commit 2 (which is unrelated to commit 3).\n\nThis is confusing to me, and looks like a bug.  What am I missing?\n\n"},{"id":"305275","messageId":"CAGZ79kbqVphQpDSEKFs=_6E1XNsn6rz=1ifRx9iEHFhRd9ZPOA@mail.gmail.com","threadId":"44410","inReplyTo":"6533af94ebd74952b75e51c5609d8c20@exmbdft7.ad.twosigma.com","subject":"Re: Submodules: two confusing situations","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-11-01T22:56:10Z","receivedAt":"2016-11-01T22:56:17Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Nov 1, 2016 at 3:13 PM, David Turner <David.Turner@twosigma.com> wrote:\n> Consider the following two cases:\n>\n> We have commit X and commit Y.  X is an ancestor of Y.\n>\n> We're at X and doing get checkout Y -- or we're at Y and we're doing\n> git checkout X.\n>\n> Case 1: Between X and Y, we have deleted a submodule.\n> In order to move from X to Y, git removes the submodule\n> from the working tree.\n>\n> Case 2: Between X and Y, we have instead added a submodule.  In order\n> to move from Y to X (that is, the opposite direction), git *does not*\n> remove the submodule from the tree; instead, it gives a warning and\n> leaves the submodule behind.\n>\n> I don't understand why these two cases are not symmetric.\n\nBecause you are using git-submodule.sh that is only an approximation of\nwhat is supposed to happen. (\"git checkout [X | Y] && git submodule update\"\nI'd guess).\n\n\"git submodule update\" only *updates* the submodules and doesn't *delete*\nthem at all. I think this originated from the historic behavior of\nhaving the submodules\n.git directory inside the submodule and not in the superprojects .git/module.\nWhen having the .git dir inside the submodule, you cannot delete the submodule\nas you'd potentially loose information (local commits) from the submodule.\n\nI am currently working on implementing a flag --recurse-submodules for\ngit-checkout\nthat would be symmetrical from X -> Y and back, but that feature hasn't seen\nthe mailing list yet as I discovered yet another bug locally.\nI think I found a reviewer though. ;)\n\nThe problem with doing a propoer checkout, i.e. update and deletion of\na submodule,\nyou need to be sure the submodule in its state can go away:\n* no untracked files that are lost (except for gitignored files)\n* clean index in the submodule and\n* the submodule points at the recorded sha1 (i.e. there are no\n  commits that would be dangling)\n\n>\n> Perhaps relatedly, consider the attached shell-script, which I have not yet made into a full git test because I'm not sure I understand the issues fully.\n>\n> It creates three commits:\n>\n> Commit 1 adds a submodule\n> Commit 2 removes that submodule and re-adds it into a subdirectory (sub1 to sub1/sub1).\n> Commit 3 adds an unrelated file.\n>\n> Then it checks out commit 1 (first deinitializing the submodule to avoid case 2 above), and attempts to cherry-pick commit 3.  This seems like it ought to work, based on my understanding of cherry-pick.  But in fact it gives a conflict on the stuff from commit 2 (which is unrelated to commit 3).\n\nThat sounds like a bug indeed.\n\n>\n> This is confusing to me, and looks like a bug.  What am I missing?\n>\n"}]}