{"thread":{"id":"46422","subject":"subrepo vs submodule","startedAt":"2017-07-19T14:27:39Z","lastAt":"2017-07-19T17:43:27Z","messageCount":2,"participants":["Robert Dailey","Stefan Beller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"324764","messageId":"CAHd499BovefnyWjauE0vNaofmvL8JBZCSzJ7w-cJ8Sm3eoJ4=w@mail.gmail.com","threadId":"46422","inReplyTo":null,"subject":"subrepo vs submodule","fromName":"Robert Dailey","fromEmail":"rcdailey.lists@gmail.com","sentAt":"2017-07-19T14:27:32Z","receivedAt":"2017-07-19T14:27:39Z","isPatch":false,"sender":{"key":"rcdailey.lists@gmail.com","avatar":null},"body":"So I found out about \"subrepo\" today: https://github.com/ingydotnet/git-subrepo\n\nI'm still reading about how it works internally, but what do you guys\nthink about it? Is it a more or less perfect alternative to\nsubmodules? What would be a reason not to use it?\n"},{"id":"324771","messageId":"CAGZ79kas6jm8+1BhhHqOe4PzFObLVEASXEQfV0H9j=4oLvz7Lw@mail.gmail.com","threadId":"46422","inReplyTo":"CAHd499BovefnyWjauE0vNaofmvL8JBZCSzJ7w-cJ8Sm3eoJ4=w@mail.gmail.com","subject":"Re: subrepo vs submodule","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-07-19T17:43:20Z","receivedAt":"2017-07-19T17:43:27Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Jul 19, 2017 at 7:27 AM, Robert Dailey <rcdailey.lists@gmail.com> wrote:\n> So I found out about \"subrepo\" today: https://github.com/ingydotnet/git-subrepo\n>\n> I'm still reading about how it works internally, but what do you guys\n> think about it?\n\nNice find!\n\nFrom reading the toplevel ReadMe.pod, I have the impression\nthat it is closer to subtree than submodules as the content is\nstored in the main repository using a .gitrepo file to indicate that\nit is a special directory.\n\n> Is it a more or less perfect alternative to submodules?\n\nMaybe to subtrees. It does not offer the workflows that\nsubmodules allow you:\n  \" Users get your repo and all your subrepos just\n  by cloning your repo.\"\n\nSubmodules allow you to *not* get the content of a submodule.\nThere are multiple reasons for not wanting the content, including\n* not needing it (e.g. documentation, hardware specific code\n  for an architecture you don't have)\n* not wanting it (e.g. large binary files yield bandwidth concerns)\n\n\"Upstream history (clone/pull) is condensed into a single commit.\"\n\nSame for submodules, not so(?) for subtrees.\n\nDepending on the point of view this is either a feature or a bug.\nFor clean history you may view this as a feature, but as soon as\nyou want to git-bisect, you'd wish for the most fine grained history\navailable.\n\n> What would be a reason not to use it?\n\nThere are multiple things that should drive a decision. some:\n* What do you need in terms of workflow (even just talking about\n  \"submodule vs subtree\" you get different answers for different\n  workflows), and then seeing how subrepo compares to the others.\n* Can you use it? (does it work on your platform? subrepo is bash,\n  whereas submodule, subtree are posix shell; how is it distributed?\n  Some people are uneasy installing from random github repos on\n  the web, so do you install it via the package manager of your\n  distribution, has your organisation a package to use?)\n* Ease of use, do you need to explain the workflow\n  to collaborateurs?\n"}]}