{"thread":{"id":"33016","subject":"git subtree workflow","startedAt":"2013-02-26T09:04:28Z","lastAt":"2013-02-27T23:37:10Z","messageCount":2,"participants":["Ben McCann","Paul Campbell"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"210319","messageId":"CAH3cagOtcR3fgoXK-Xd8vm48q0GPQtYMkWiqQGgydb27HeO0wQ@mail.gmail.com","threadId":"33016","inReplyTo":null,"subject":"git subtree workflow","fromName":"Ben McCann","fromEmail":"ben@benmccann.com","sentAt":"2013-02-26T09:04:28Z","receivedAt":"2013-02-26T09:04:28Z","isPatch":false,"sender":{"key":"ben@benmccann.com","avatar":null},"body":"I'm fairly new to git and am trying to determine if git subtree would\nbe helpful for managing our company's codebase, which has several\nrepos some of which depend on each other. All the examples I've seen\nmake sense to me as a one-time operation to merge separate repos into\none monolithic one or to split one monolithic repo into separate\nrepos. I'm having a harder time understanding how this fits into a\nlarger picture and what the workflow for working with subtree would\nbe.\n\nIf I have a bunch of repos on GitHub and some depend on each other,\nhow would I set them up to work with subtree? Would GitHub continue to\nhost them as is, host a merged monolithic repo, or host both a\nmonolithic repo and the splitted out repos? The exact answer probably\nvaries, but I imagine there's basic workflow that would satisfy 80% of\nusers.  If I have GitHub host both monolithic and splitted out repos,\nit seems unclear as to how I keep those repos in sync and make sure\nall the developers in our company push their changes to both repos.\n\nThanks,\nBen\n"},{"id":"210414","messageId":"CALeLG_nNQ_ERa23Or+qmNmsxQDahRtxbejmUHKnGFd8EoQCtww@mail.gmail.com","threadId":"33016","inReplyTo":"CAH3cagOtcR3fgoXK-Xd8vm48q0GPQtYMkWiqQGgydb27HeO0wQ@mail.gmail.com","subject":"Re: git subtree workflow","fromName":"Paul Campbell","fromEmail":"pcampbell@kemitix.net","sentAt":"2013-02-27T23:37:10Z","receivedAt":"2013-02-27T23:37:10Z","isPatch":false,"sender":{"key":"pcampbell@kemitix.net","avatar":"https://gravatar.com/avatar/57584e05501b694929004e43fcd7308f4ad64df2eb0474cd8c7e5f93662bb0f1?d=mp&s=160"},"body":"On Tue, Feb 26, 2013 at 9:04 AM, Ben McCann <ben@benmccann.com> wrote:\n> I'm fairly new to git and am trying to determine if git subtree would\n> be helpful for managing our company's codebase, which has several\n> repos some of which depend on each other. All the examples I've seen\n> make sense to me as a one-time operation to merge separate repos into\n> one monolithic one or to split one monolithic repo into separate\n> repos. I'm having a harder time understanding how this fits into a\n> larger picture and what the workflow for working with subtree would\n> be.\n\nThe git subtree command does support pushing and pulling changes\nto/from a subtree to a remote repo. This operation can be repeated\nover time as the underlying git subtree split command produces an\naccurate extract from the subtree.\n\nFor example:\n\n$ git clone $superrepo super\n$ cd super\n$ git subtree add --prefix=child $childrepo master\n$ split_head=$(git subtree split --prefix=child)\n\ngit subtree split creates a synthetic copy of the child subtree and\nreturns the SHA1 for the head of that subtree.\n\n$ cd ..\n$ git clone $childrepo child\n$ cd child\n$ child_head=$(git rev-parse master)\n\n$split_head and $child_head match.\n\nYou could pass either $*_head to gitk and be able to browse identical\ntrees and histories.\n\n$ gitk $child_head &\n$ cd ../super\n$ gitk $split_head &\n\nThe only difference you should see is that the tree in the super\nproject doesn't have any branches or tags from the child repo.\n\n> If I have a bunch of repos on GitHub and some depend on each other,\n> how would I set them up to work with subtree? Would GitHub continue to\n> host them as is, host a merged monolithic repo, or host both a\n> monolithic repo and the splitted out repos? The exact answer probably\n> varies, but I imagine there's basic workflow that would satisfy 80% of\n> users.  If I have GitHub host both monolithic and splitted out repos,\n> it seems unclear as to how I keep those repos in sync and make sure\n> all the developers in our company push their changes to both repos.\n\nThis is what I'm using git-subtree for. I have a super project which\nholds child repos, some of which hold other child repos.  You can\ndevelop on all of your projects within the super project and still\nperiodically pull and push updates with the remote child repos.\n\nSomeone who doesn't know about your child repos can take the\nmonolithic repo and commit to it as normal. You can then pull their\ncommits and push any changes to the child repos. Probably to a\nnon-master branch so you they can be integrated like other pull\nrequests.\n\nCaveats:\n\n1) I would probably avoid the --squash option as I suspect that might\nmess with $split_head == $child_head. Whether or not it would have any\nimpact of your ability to push or pull I don't know. I've not tried\nit.\n\n2) When you commit you should ideally not commit a set of files that\nare in more than one subtree. You're commit history when you push back\nto the source repo for a subtree might look a bit odd if it's\nreferring to other parts of the super project or it's subtrees.\n\n-- \nPaul [W] Campbell\n"}]}