tag:blogger.com,1999:blog-7609658525941194126.post8342497138134867176..comments2022-12-04T23:15:49.314-05:00Comments on Flavor-iffic: Managing Git Submodules With git.rakeMikehttp://www.blogger.com/profile/01750555903559042849noreply@blogger.comBlogger15125tag:blogger.com,1999:blog-7609658525941194126.post-20159619316360276432011-01-17T17:56:06.727-05:002011-01-17T17:56:06.727-05:00We just setup our dev env in git with submodules s...We just setup our dev env in git with submodules so that we can get partial workspaces and versions for each of our dependent modules. Everyone doesn't need everything. Now I came across this post. Is this still the situation with submodules? Is there any better way to have sparse workspaces?<br />Thanks.Marlenehttps://www.blogger.com/profile/13408191088116025640noreply@blogger.comtag:blogger.com,1999:blog-7609658525941194126.post-15340829408454828272009-11-19T06:22:29.014-05:002009-11-19T06:22:29.014-05:00It was very interesting for me to read this blog. ...It was very interesting for me to read this blog. Thanx for it. I like such themes and anything that is connected to them. I would like to read a bit more on that blog soon.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7609658525941194126.post-56780191655887375742009-11-18T19:43:52.317-05:002009-11-18T19:43:52.317-05:00It is extremely interesting for me to read this po...It is extremely interesting for me to read this post. Thanks for it. I like such topics and anything connected to them. I definitely want to read a bit more soon.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7609658525941194126.post-81135615863126990812009-09-14T12:31:30.413-04:002009-09-14T12:31:30.413-04:00Sorry, I renamed my github account from 'mdale...Sorry, I renamed my github account from 'mdalessio' to 'flavorjones'. I'll update the article in a moment, but for now you can see this repo at:<br /><br /> http://github.com/flavorjones/git-rakeMikehttps://www.blogger.com/profile/01750555903559042849noreply@blogger.comtag:blogger.com,1999:blog-7609658525941194126.post-80137936794089082072009-09-11T23:39:09.402-04:002009-09-11T23:39:09.402-04:00Wahh, this disappeared off github?
Forked here:
h...Wahh, this disappeared off github?<br /><br />Forked here:<br />http://github.com/rmatei/git-rake/tree/masterRoberthttps://www.blogger.com/profile/01230447051692550025noreply@blogger.comtag:blogger.com,1999:blog-7609658525941194126.post-63611117437981173672008-05-30T04:45:00.000-04:002008-05-30T04:45:00.000-04:00We now use the following sequence to clone a repo:...We now use the following sequence to clone a repo:<BR/><BR/>git clone whatever<BR/>cd whatever_dir<BR/>git submodule init<BR/>git submodule update<BR/>rake git:sub:checkout_master<BR/>rake git:update<BR/>rake git:commit<BR/>rake git:push<BR/><BR/>The checkout_master step is crucial of course, as it ensures that the submodules are all on the master branch. It is something of a precaution. <BR/><BR/>This complicated sequence (which we have turned into a shell script) would not be necessary if all submodules are switched to the master branch as they are added to the project, before the commit.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7609658525941194126.post-46602387007673049852008-05-21T12:38:00.000-04:002008-05-21T12:38:00.000-04:00@pat: I understand the issue as you've described, ...@pat: I understand the issue as you've described, and was able to reproduce it, and it's clarified some things for me.<BR/><BR/>The reason I (and my company) have not walked into this spinning propeller of submodule hell is because of two reasons:<BR/><BR/> 1) We always make sure our submodules are on a branch, and not on the (default) detached HEAD. This allows us to ...<BR/><BR/> 2) Always pull changes from the shared repo before committing local changes.<BR/><BR/>Now, this is only feasible on branches with relatively low update frequencies.<BR/><BR/>That is, if you can't be reasonably sure that the shared repository hasn't changed between the times you do a 'git pull' and a 'git push' on your submodule, then (proverbially speaking) you're F-ed in the A.<BR/><BR/>So, I acknowledge that there is no reasonable way to make submodules work for frequently-updated projects, even with git.rake.<BR/><BR/>Many thanks to you and dysinger for pointing this out. It's definitely an issue. I'll be updating the documentation in git.rake's github repo to alert people.Mikehttps://www.blogger.com/profile/01750555903559042849noreply@blogger.comtag:blogger.com,1999:blog-7609658525941194126.post-38972351185485374752008-05-21T10:30:00.000-04:002008-05-21T10:30:00.000-04:00dsyinger was right when he said that the RSpec pro...dsyinger was right when he said that the RSpec project had a lot of trouble with submodules and found them unsuitable for active development.<BR/><BR/>They seem to work fine, as does git-rake, until you have more than one developer. Then the submodules become a real PITA.<BR/><BR/>Let's say you've got a super project with submodule a. I make changes to some file in a and commit my changes, and update the submodule reference to be commit abc123. Now you make some changes to a file in a, commit your changes and update the submodule ref to be def456. When either of us updates, there will be a merge conflict on the submodule reference, because we're both saying that the submodule reference has a different commit ID. You can just accept your own SHA, because you know you've already merged the submodules. But it's annoying to have to do that every time. On top of that, it's way too easy to blow away local changes by doing "git submodule update". So submodules, for us, had no upsides and plenty of downsides.<BR/><BR/>I experimented with git-rake for a bit and it doesn't appear to handle this problem. Are you using it on a team with multiple active developers, or are you using it alone, managing external dependencies?<BR/><BR/>As far as how we solved it in the RSpec codebase, we just check out the "child" repos into the proper dirs and use .gitignore to ignore their files from the "parent" repo. But there's no direct relationship between them, so we don't have any of the headaches of submodules.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7609658525941194126.post-80217289768374390372008-05-15T13:25:00.000-04:002008-05-15T13:25:00.000-04:00Hi Mike.I've just posted a new article with a work...Hi Mike.<BR/><BR/>I've just posted a new article with a work-around using Git's sub-project. <BR/><BR/>It was inspired by your work.<BR/><BR/>More info: http://panthersoftware.com/articles/view/4/git-svn-dcommit-workaround-for-git-submodules<BR/><BR/>Thanks.Unknownhttps://www.blogger.com/profile/16677891063396401864noreply@blogger.comtag:blogger.com,1999:blog-7609658525941194126.post-41190901635199883402008-05-12T00:21:00.000-04:002008-05-12T00:21:00.000-04:00I understand where you're coming from. However, gi...I understand where you're coming from. However, git-rake automatically pulls your commit logs from the submodule into the superproject ... without a hassle. That's the whole point.<BR/><BR/>I don't spend any more time managing my submodules than I would if I had all my code in a single project. If I make a change, I run "rake git:commit", and whatever changes were made in my submodules gets committed, pushed upstream, and the superproject pulls the commit logs into its own log. Easy, peasy.<BR/><BR/>I will take another look at subtrees, however your descriptions of pushing changes back upstream sounds like more work than I'm doing now with git-rake.<BR/><BR/>But really, that's the wonderful thing about git. There's a workflow for everyone's taste.Mikehttps://www.blogger.com/profile/01750555903559042849noreply@blogger.comtag:blogger.com,1999:blog-7609658525941194126.post-65930755900544673452008-05-12T00:07:00.000-04:002008-05-12T00:07:00.000-04:00I have used both and both work to be fair. I just...I have used both and both work to be fair. I just like sub-trees better. I think it's cleaner.dysingerhttps://www.blogger.com/profile/13310783563646722381noreply@blogger.comtag:blogger.com,1999:blog-7609658525941194126.post-30042194932186252052008-05-12T00:05:00.000-04:002008-05-12T00:05:00.000-04:00I think the exact opposite. I think submodules ar...I think the exact opposite. I think submodules are for code that is not edited often. Everytime you edit code in the submodule you have to make an additional commit in the parent module so that everyone can see the latest changes in the submodule = hassle.<BR/><BR/>You can do two things for working on projects with sub-trees where you need to edit the sub-tree project.<BR/><BR/>1 - branch the sub-tree's remote just like you would branch any remote. Commit to them and push them back to their origin repo (which has already been added as a remote).<BR/><BR/>2 - you can always work on the sub-treed project in another directory where you have the project cloned on it's own just like any git project. When you are done push to the remote, pull back (merge) into your "parent" project.<BR/><BR/>It works and is less cumbersome than submodules IMO. It's just branches and merging - active development as it's supposed to be.dysingerhttps://www.blogger.com/profile/13310783563646722381noreply@blogger.comtag:blogger.com,1999:blog-7609658525941194126.post-51391906897951222782008-05-11T23:45:00.000-04:002008-05-11T23:45:00.000-04:00@dysinger - After reading up on subtrees in the Ho...@dysinger - After reading up on subtrees in the <A HREF="http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html" REL="nofollow">How-To</A>, it seems like they're not appropriate for the situation git-rake was developed to handle -- namely, code <EM>under active development</EM>.<BR/><BR/>Specifically, subtrees are great for merging upstream changes into your local (downstream) repository. But it does not provide functionality for commit changes back upstream to the (shared) repository.<BR/><BR/>If your big complaint with submodules is that they're a hassle, and git-rake makes handling submodules easy, then that's problem solved, no?Mikehttps://www.blogger.com/profile/01750555903559042849noreply@blogger.comtag:blogger.com,1999:blog-7609658525941194126.post-40595621814175664002008-05-08T14:41:00.000-04:002008-05-08T14:41:00.000-04:00@dysinger - I'll be looking into subtrees. Thanks ...@dysinger - I'll be looking into subtrees. Thanks for the feedback!Mikehttps://www.blogger.com/profile/01750555903559042849noreply@blogger.comtag:blogger.com,1999:blog-7609658525941194126.post-16051309772961988522008-05-06T22:03:00.000-04:002008-05-06T22:03:00.000-04:00I don't use submodules anymore. They are a hassle...I don't use submodules anymore. They are a hassle when dealing with a bunch of inter-related sub-projects. Instead I use subtree and merge. It's much more like merging a branch (because that's exactly what it is). The branch just get's placed in a sub-directory. Read about it here http://dysinger.net/2008/04/29/replacing-braid-or-piston-for-git-with-40-lines-of-rake/ The rspec project had a disaster which luckily they recovered from where they lost 15 days of commits due to a submodule mess-up. Anyway submodules are good for some things. But that list is pretty small IMO.dysingerhttps://www.blogger.com/profile/13310783563646722381noreply@blogger.com