Two options: http://github.com/evilchelu/braid/tree/master http://github.com/pat-maddox/giternal/tree/master
Possibly useful comment thread featuring authors of both: http://www.rubyinside.com/giternal-easy-git-external-dependency-management-1322.html I haven't had time to figure this out myself yet. On Feb 15, 7:04 am, Tom Locke <[email protected]> wrote: > Thanks for the warning Scott - I'm coming round to that way of > thinking too... > > One more for your list: > > - Change a subdirectory into a sub-module, or vice-versa, and > prepare yourself for a world of pain. > > The question is, what to use instead? Piston? > > Tom > > On 13 Feb 2009, at 17:38, Scott Bronson wrote: > > > > > Reading about Git submodules and Heroku, I figured I'd share my > > experience... Some of you know that I've been playing with > > hobostarter,http://github.com/bronson/hobostarter/tree/master I > > intended to use Git submodules to produce a ready-to-run Hobo > > environment, just clone start writing your app. No need to worry > > about gem dependencies, installing Rails, matching Hobo and Rails > > versions, etc. Nirvana! > > > Well, after using hobostarter with multiple Hobo projects for a few > > months I've decided that, while Hobostarter would be very useful, Git > > submodules are an abject failure. They seem great when you first set > > up the project but they quickly become horrible when trying to do > > day-to-day things... > > > - Submodules prevent bisecting (you can work around this but it's > > laborious) > > - They are painful when merging, or rolling forward or back in time. > > - They can't accept local changes or share objects with the > > superproject. To commit to a submodule, you must host the entire > > subproject yourself. > > - Git doesn't display changes to submodules so they're always > > getting lost... > > - ...and you're always forgetting to push. And when you push your > > project but forget the submodule, the error message is awful... > > - ...and your coworker is hosed until you finish your checkin. It's > > like locking a needed file in Visual Source Safe and then going home > > (without the helpful error message). > > - It's fairly involved to switch to a different repo, which you have > > to do when committing local changes. > > - the three-step clone (clone / init / update) is odd and a fairly > > clear sign submodules aren't intended for this use case. > > - the error messages are utterly uninformative to anyone without deep > > Git knowledge. Error messages tend to crop up a lot. > > > I've pretty much decided not to use Git submodules on anything other > > than my own pet projects. In particular, if anyone else is going to > > be contributing, even if they're a full-on Junioesque Git expert, I > > will not use submodules. > > > For little one-offs or experiments, they're fine. When you start to > > run into merge/bisect issues, you can just replace the submodule with > > a code snapshot and continue. But for any sort of team environment, > > where it's frowned upon to make huge changes like that at a whim, I > > can pretty much guarantee that submodules will eventuallyl cost you > > far more time than they'll save. > > > Sorry if this reads like a rant, I just intended to share my > > experience and maybe got carried away a little. :) > > > - Scott > > > P.S. Interestingly, the original problem that Git submodules were > > intended to solve (creating a distribution repository) is actually > > solved better by Repo,http://source.android.com/download/using-repo. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Hobo Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hobousers?hl=en -~----------~----~----~----~------~----~------~--~---
