matthewmccullough · September 29, 2011 03:45
diff --git a/September-28-2011-GitHub-Office-Hours-Transcript.txt b/September-28-2011-GitHub-Office-Hours-Transcript.txt
 MatthewMcC	And hello everyone! Welcome to the first of many future GitHub office hours. For those of you new to Campfire, it is best if you @matthewmcc if you want to catch my attention directly. We're open to any and all questions on Git and GitHub during the hour and will try to spread the attention to everyone participating and answer as many questions as possible.
 I'm Matthew McCullough, GitHub's trainer for all things Git. (https://github.com/training/online)
 Mike	What is the main use for submodules?
 MatthewMcC	@Mike Great first question. It is a multipart answer.
 3:05 PM
 MatthewMcC	@Mike First, submodules are best for organizing an "uber app" that is composed of subcomponents. For example, some big site that has a chat module, a shopping cart, some resources, and some APIs.
 @Mike Lets say that this is big enough that there are multiple teams, and each team is assigned one of those components.
 @Mike The teams are likely innovating like crazy, but we can't just take their code at any time -- we need it to be stable. So, the "uber app" aggregates all the components into the shipping "site" that is everything put together.
 @Mike Each submodule can continue innovating like crazy and getting commits added to it, but the uber-app can use any SPECIFIC hash (version) of the submodule, thus locking it into a specific point in time when it was stable, even though the subcomponent continues to get commits.
 @Mike That way, you could actually have several Uber App projects, each of which aggregate different versions of the subcomponents. One aggregation uses really old versions of the components (super stable), one uses newer (more cutting edge) and another aggregates the super-newest (beta)
 @Mike A Submodule is more-or-less a pointer to a independent Git project, so it has very little "weight" on the uber-app that aggregates them. It just stores the URL to acquire the submodule from and a pointer to the specific hash (version) that this Uber-App wants to use from that submodule.
 3:10 PM
 Brian S.	has left the room
 Mike	So each submodule needs to be in its own repo?
 James A.	has left the room
 MatthewMcC	@Mike The best public resource for info on this is: http://progit.org/book/ch6-6.html and then you saw Kevin's link to the shell script today too: http://j.mp/r7O3Q0
 Matt R.	has entered the room
 MatthewMcC	@Mike Correct. Each submodule is a stand alone repo, commonly representing some "component" or library.
 @Mike Each submodule is represented as a folder within the "uber app" project.
 RobJ	has entered the room
 MatthewMcC	@Mike Within the uber-app Git project, you would type `git submodule add <URL> <FOLDERNAME>`
 Mike	What is the best way to handle repos that have large binaries?
 Robert S.	has entered the room
 MatthewMcC	@Mike That's a challenge, as Git wasn't really designed for it. Let me harvest a few resources for a moment though. There are a few solutions (hybrids)... Gathering... BRB.
 Konstantin D.	has entered the room
 3:15 PM
 MatthewMcC	http://git-annex.branchable.com/
 http://stackoverflow.com/questions/540535/…
 https://github.com/apenwarr/bup
 @Mike Annex is one of the most-used tools to accomplish this. Though, to be certain, Git really doesn't optimize for large files.
 @Mike I've been able to decently commit up to 100MB files that are infrequently changing, but beyond that, it becomes cumbersome.
 @Mike Git's penchant for giving you all the branches and all the commits all the time is awesome -- right up until you need binaries committed.
 Nick E.	has entered the room
 Mike	What is the benefit of the github rubygem you spoke about this morning?
 MatthewMcC	@Mike Interestingly, Annex lets you store pointers to objects in S3 or SVN and mix-and-match that with Git for the primary source code. Linux has a thread on the Git mailing list saying "can't optimize for everything, and mine is for speed with source files, not binaries" (just sharing, not yelling like he sometimes does)
 3:20 PM
 David	has left the room
 MatthewMcC	@Mike I love the hub gem because it offers a simple enhancement to allow me to type less when working with GitHub frequently.
 @Mike https://github.com/defunkt/hub
 @Mike You can just `sudo gem install hub` and grab it.
 patrick	what's the second part of the answer to the submodules question? :)
 MatthewMcC	@Mike you can shortcut standard invocations like `git clone git@github.com:this/that` to a mere `hub clone -p hellogitworld` and it assumes your local github username
 @Patrick The second use case for Submodules that I've personally leveraged is for partially open sourcing a big project.
 @Patrick The Gradle book that I wrote for O'Reilly -- well, I wanted to OSS it. They said, not while it was in Beta. I said, I will OSS the code samples then.
 patrick	oh, interesting usage, thanks!
 MatthewMcC	@Patrick So, we made the book repo private, but put the examples into it as a subdirectory (submodule) that was a public repo.
 @Patrick The beauty of this is we were getting public contributions and pull requests to the examples from the second day we had them in the public domain whilst still satisfying O'Reilly's requirement of a closed source book until it was completed.
 3:25 PM
 patrick	nice!
 as a freelance, I find github's pricing plans a bit expensive for me,
 as I need to maintain many little private projects
 MatthewMcC	@Patrick Ah. So it is the project count that causes you to have to be in a higher-priced bracket? How many?
 lifo	has entered the room
 patrick	right now I maintain about 30 small projects
 some of them are actually customized versions of others, but still need to manage them apart
 JZ	has entered the room
 MatthewMcC	@Patrick Ah. I see. I'll mention this to the GH guys. I've heard this a few times.
 patrick	is there any planned update to the pricing plans?
 themcgruff	has entered the room
 Guillaume V.	At our company, we work primarily with websites, and although we, in the office, use git for the versioning.. There are times where someone at home might not have a repo while they're working, and just work directly off the FTP. What's the best method for when they reenter the office with their laptop (or a flash drive) and want to merge those code changes into the master? Could they just make a repo on their machine, and then.. on my repo try to merge theirs in? Make a branch, copy their files in.. and try to merge that against my master? Or something to those effects?
 MatthewMcC	@Patrick They keep me kind of out of that, but I certainly will bring that concern to them.
 patrick	thanks a lot Matthew!
 MatthewMcC	@Patrick I get the need to have many repos, but low disk usage and low user count
 @Patrick Is it just you accessing them?
 3:30 PM
 patrick	usually yes, though occasionally need one or two more users
 Robert S.	has left the room
 Konstantin D.	has left the room
 David	has entered the room
 MatthewMcC	@GuillaumeV Good question. So basically, what's a good approach for merging live FTP updates with what's in the canonical repo.
 Guillaume V.	Yeah, because, the #1 issue we've of course had.. Is overwriting those FTP changes.
 And then a lot of swearing at the fact that git wasn't used... but they sort of couldn't, because they weren't near the repo (which might only be in-office) to grab it.
 MatthewMcC	@GuillaumeV Well, first and foremost, I would recommend not doing those edits directly, but I understand I can't prescriptively just say that. ;) Second, I would suggest that
 Guillaume V.	haha, of course
 MatthewMcC	@GuillaumeV as soon as they get into the office to:
 @GuillaumeV `git clone THEPROJECT`, then `git checkout -b myoffsitechanges1`
 @GuillaumeV Then, ftp wget them down into the current git repo (now a branch)
 Guillaume V.	yeah
 MatthewMcC	@GuillaumeV Then `git add -A .` which will pick up all the changes, whether they be deletes or adds or renamed
 @GuillaumeV Then `git commit -m"Changes made via FTP for XXX project work"
 @GuillaumeV Then git push those back to your master/central repo.
 Kevin M.	has entered the room
 Guillaume V.	right, so very similar to the normal workflow for normal changes, only after-the-fact
 MatthewMcC	@GuillaumeV I think with a post-commit hook, you could make people want to use Git, even remotely more than FTP.
 @GuillaumeV For example, I have such a hook for http://gradleware.com
 3:35 PM
 MatthewMcC	@GuillaumeV When I make a local change to code, I just git commit and push it to GitHub and it triggers a deploy on the FTP server which is actually faster and more efficient for me.
 @GuillaumeV I can also, in absence of tools, change the code through the GitHub Cloud9IDE editor and that also
 Guillaume V.	hmmm, that's a very good idea
 MatthewMcC	@GuillaumeV results in a post-receive hook firing and deploying the site.
 Guillaume V.	and GitHub allows for these hooks to do the uploading, or is a little tinkering needed?
 MatthewMcC	@GuillaumeV Even folks who were without tools, and previously determined to make FTP-direct changes are LOVING the fact they get a web based editor with syntax highlighting and no need for FTP tools. Literally, from "web page" edits and directly site deployes.
 @GuillaumeV I can point you at a few common scripts in my sample repo -- Github just needs to be able to "ping" a URL on your server side that triggers the behavior. Typically a call to a PHP file, or similar.
 Mike	In a Github private repo, is there a way to increase the storage size for the account but not the repos count. And is there a upgrade charge?
 Guillaume V.	Yeah, and on the server's site.. perform the export of the repo's files-- but that's a very excellent idea.
 MatthewMcC	@GuillaumeV And the best part is that there doesn't need to be any risk of attack on that public URL. It only "tells" the remote FTP server to get the code from github, which is very trusted.
 Guillaume V.	server's side*
 MatthewMcC	@GuillaumeV Yup.
 Guillaume V.	Thank you very much!
 MatthewMcC	@Mike The size limit is pretty soft. If you don't triple it, we are pretty lax. And if you push that soft limit by 3x, you'll get a polite email about it before it becomes a problem. No sudden cut-offs.
 3:40 PM
 MatthewMcC	@Mike We try to make you love us. We aren't MegaCorp rule-driven, even if a few rules are posted around the poolside. ;)
 lifo	has left the room
 JZ	has left the room
 Guillaume V.	Re: the size limit: That's very cool.
 MatthewMcC	@GuillaumeV Indeed. It really is just to keep folks from backing up their hard disk to GitHub. ;) We love you to host lots and lots of code with us.
 Excellent questions and discussions so far. Anyone that has just joined -- dive right in and ask something. Anything. I'll take a good stab at answering. It can be Git, command line, GUIs, GitHub...
 3:45 PM
 bovine	has entered the room
 David	I'll be "the one". :D Any plans for Github for Linux?
 Mike	How do you push to different remote branch?
 3:50 PM
 MatthewMcC	@David I truly (not playing dumb) don't know on that one. I think it needs some helpful pushes via comments on that GitHub for mac blog entry and emails to support@github.com. I will back you up on it.
 @David I do know that the Windows one is baking...
 Kevin M.	has left the room
 MatthewMcC	@David Of the 10,000 folks that I've taught Git to (I can't believe that number myself, but it is accurate), some vast, vast majority of the Linux users, as I do, love the command line the mostest.
 Fuh	has entered the room
 MatthewMcC	@David That's not to say they are ignored, but they are largely, largely satisfied with TIG, SmartGit for Linux, Git-Gui, GitK, etc.
 @David but I will still put in a good word, but could use your vote as well via a quick email to support@github.com with that one-line request. ;)
 http://www.delicious.com/search?p=git+gui+linux
 @Mike As for pushing precision...
 @Mike `git push <REMOTENAME> <BRANCHNAME>` For example, `git push origin master`, then `git push otherremote master:myotherbranchname`
 David	MatthewMcC: Interesting, thanks. I'll shoot in an email soon
 3:55 PM
 MatthewMcC	@Mike The names before and after the colon on the branch names are the "local name" and the "upstream name" respectively. In Git, you can push any local branch contents to a different name on the upstream side.
 Mike: Does that help? Or can I add more precision to that answer for you?
 LOL	has entered the room
 Mike	That helps, Thank you.
 Guillaume V.	One thing I've recently started was an open-source project (which is hosted on GitHub), and it is the basis for a closed-source project.. So as I make advancements for the closed-source one, the open-source code progresses inside it... But, what sort of method should I use to push the code back to the open-source one? As I'd want to exclude portions of overwritten configuration files or exclude entire folders.
 Keeping in mind that I'm not afraid to go through a giant patchfile or something, but just am unsure how to apply it.
 4:00 PM
 MatthewMcC	@GuillaumeV A very common use case and easy to do, I think.
 I'd keep a branch for the "public" version of it and that would be your branch you publish to GitHub.
 @GuillaumeV You can checkout the public branch and then
 @GuillaumeV `git merge --no-commit privatebranch`
 @GuillaumeV That would give you all the code, dropped into the branch and staged, but not committed. You could then prune out the closed source and then finish the commit
 @GuillaumeV You could, if only a small portion of the closed source one would go back, use two other approaches.
 suds	has entered the room
 MatthewMcC	@GuillaumeV You could make all the "OSS" commits to a public branch and then merge those to the closed source (these would still be two branches in the same repo)
 Guillaume V.	right
 MatthewMcC	@GuillaumeV Or, if it is too hard to tease those out in advance, you could `git cherry-pick <REV>` one commit at a time FROM the closed source over to the OSS branch.
 @GuillaumeV That gives you a OPEN -> CLOSED and a CLOSED -> OPEN and a CLOSED -> OPEN with manual choosing of the commits if using the --no-commit option on a traditional merge.
 @GuillaumeV Additionally, if you turn on rerere (a nice option, to be sure) you can "save" the merge conflict resolution, which is your case, is a misnomer, but still means, "what do you want to keep" after the merge
 4:05 PM
 MatthewMcC	@GuillaumeV This would allow for continued merging from one branch to the other without duplication of effort the 3rd, 5th, and 10th times you merged the CLOSED branch into the OPEN branch.
 Guillaume V.	Just googled that really quick
 MatthewMcC	http://progit.org/2010/03/08/rerere.html
 Guillaume V.	It would allow for me to make a lot more human intervention choices?
 MatthewMcC	@GuillaumeV It basically is recording how _you_ decide to handle merge conflicts. E.g. "If I see this on the LEFT and this on the RIGHT then I should put THIS on the result and ask the commiter if he likes it"
 @GuillaumeV It will be helpful, I think, in this case you are describing.
 Guillaume V.	yeah, that sounds exactly what I've been looking for
 MatthewMcC	@GuillaumeV I have also tried another supplemental strategy in which I mark the commits with "OSS: " when I'm typing the commit message and then
 I have a shell script that searches for all of those and cherry-picks them into the OSS branch.
 Guillaume V.	riiight
 that would also work very well
 MatthewMcC	@GuillaumeV Lots of ideas, all of which I have used. Hopefully that provides you with a smorgasboard of choices that might fit.
 Guillaume V.	I think it will also just require a lot finer detail on paying attention to what is going to be going into a merge as well
 MatthewMcC	@GuillaumeV Indeed. It definitely does. But I think it pays off in terms of later ease (more brain effort at commit time and authoring time, less at OSSing-time)
 4:10 PM
 Fuh	has left the room
 LOL	has left the room
 MatthewMcC	Well folks, we've come to the end of our first Office Hours session. Since this is a new idea and can be formed by your inputs, please send any compliments, complaints or mild-mannered suggestions for topics, timing, frequency, length and all manner of how-we-should-do-it to training@github.com. I and my GitHub colleages are all ears in helping our community out. I hope this session was useful!
 patrick	it was indeed, thanks MatthewMcC!
 joe	Thanks for doing it Matthew!
 MatthewMcC	@Joe You bet. Tell any and all colleagues if they have stumper Git and GitHub questions to bring them to these sessions. We're here to help.
 @Patrick Thanks for hanging around and asking questions too!
 Jordan	has entered the room
 MatthewMcC	We'll try to hold these about every week or two
 Guillaume V.	Thank you very much for taking the time to answer questions and your original webinar. Very helpful stuff.
 MatthewMcC	@GuillaumeV My pleasure to share knowledge.
 Guillaume V.	It's so strange going from closed-source and secretive to more.. open sharing and stuff.
 Very liberating.
 4:15 PM
 patrick	this idea is pretty sweet, thanks!
 MatthewMcC	@GuillaumeV I couldn't agree more. And Coder Wall proves it: http://coderwall.com/matthewmccullough
	MatthewMcC And hello everyone! Welcome to the first of many future GitHub office hours. For those of you new to Campfire, it is best if you @matthewmcc if you want to catch my attention directly. We're open to any and all questions on Git and GitHub during the hour and will try to spread the attention to everyone participating and answer as many questions as possible.
	I'm Matthew McCullough, GitHub's trainer for all things Git. (https://github.com/training/online)
	Mike What is the main use for submodules?
	MatthewMcC @Mike Great first question. It is a multipart answer.
	3:05 PM
	MatthewMcC @Mike First, submodules are best for organizing an "uber app" that is composed of subcomponents. For example, some big site that has a chat module, a shopping cart, some resources, and some APIs.
	@Mike Lets say that this is big enough that there are multiple teams, and each team is assigned one of those components.
	@Mike The teams are likely innovating like crazy, but we can't just take their code at any time -- we need it to be stable. So, the "uber app" aggregates all the components into the shipping "site" that is everything put together.
	@Mike Each submodule can continue innovating like crazy and getting commits added to it, but the uber-app can use any SPECIFIC hash (version) of the submodule, thus locking it into a specific point in time when it was stable, even though the subcomponent continues to get commits.
	@Mike That way, you could actually have several Uber App projects, each of which aggregate different versions of the subcomponents. One aggregation uses really old versions of the components (super stable), one uses newer (more cutting edge) and another aggregates the super-newest (beta)
	@Mike A Submodule is more-or-less a pointer to a independent Git project, so it has very little "weight" on the uber-app that aggregates them. It just stores the URL to acquire the submodule from and a pointer to the specific hash (version) that this Uber-App wants to use from that submodule.
	3:10 PM
	Brian S. has left the room
	Mike So each submodule needs to be in its own repo?
	James A. has left the room
	MatthewMcC @Mike The best public resource for info on this is: http://progit.org/book/ch6-6.html and then you saw Kevin's link to the shell script today too: http://j.mp/r7O3Q0
	Matt R. has entered the room
	MatthewMcC @Mike Correct. Each submodule is a stand alone repo, commonly representing some "component" or library.
	@Mike Each submodule is represented as a folder within the "uber app" project.
	RobJ has entered the room
	MatthewMcC @Mike Within the uber-app Git project, you would type `git submodule add <URL> <FOLDERNAME>`
	Mike What is the best way to handle repos that have large binaries?
	Robert S. has entered the room
	MatthewMcC @Mike That's a challenge, as Git wasn't really designed for it. Let me harvest a few resources for a moment though. There are a few solutions (hybrids)... Gathering... BRB.
	Konstantin D. has entered the room
	3:15 PM
	MatthewMcC http://git-annex.branchable.com/
	http://stackoverflow.com/questions/540535/…
	https://github.com/apenwarr/bup
	@Mike Annex is one of the most-used tools to accomplish this. Though, to be certain, Git really doesn't optimize for large files.
	@Mike I've been able to decently commit up to 100MB files that are infrequently changing, but beyond that, it becomes cumbersome.
	@Mike Git's penchant for giving you all the branches and all the commits all the time is awesome -- right up until you need binaries committed.
	Nick E. has entered the room
	Mike What is the benefit of the github rubygem you spoke about this morning?
	MatthewMcC @Mike Interestingly, Annex lets you store pointers to objects in S3 or SVN and mix-and-match that with Git for the primary source code. Linux has a thread on the Git mailing list saying "can't optimize for everything, and mine is for speed with source files, not binaries" (just sharing, not yelling like he sometimes does)
	3:20 PM
	David has left the room
	MatthewMcC @Mike I love the hub gem because it offers a simple enhancement to allow me to type less when working with GitHub frequently.
	@Mike https://github.com/defunkt/hub
	@Mike You can just `sudo gem install hub` and grab it.
	patrick what's the second part of the answer to the submodules question? :)
	MatthewMcC @Mike you can shortcut standard invocations like `git clone git@github.com:this/that` to a mere `hub clone -p hellogitworld` and it assumes your local github username
	@Patrick The second use case for Submodules that I've personally leveraged is for partially open sourcing a big project.
	@Patrick The Gradle book that I wrote for O'Reilly -- well, I wanted to OSS it. They said, not while it was in Beta. I said, I will OSS the code samples then.
	patrick oh, interesting usage, thanks!
	MatthewMcC @Patrick So, we made the book repo private, but put the examples into it as a subdirectory (submodule) that was a public repo.
	@Patrick The beauty of this is we were getting public contributions and pull requests to the examples from the second day we had them in the public domain whilst still satisfying O'Reilly's requirement of a closed source book until it was completed.
	3:25 PM
	patrick nice!
	as a freelance, I find github's pricing plans a bit expensive for me,
	as I need to maintain many little private projects
	MatthewMcC @Patrick Ah. So it is the project count that causes you to have to be in a higher-priced bracket? How many?
	lifo has entered the room
	patrick right now I maintain about 30 small projects
	some of them are actually customized versions of others, but still need to manage them apart
	JZ has entered the room
	MatthewMcC @Patrick Ah. I see. I'll mention this to the GH guys. I've heard this a few times.
	patrick is there any planned update to the pricing plans?
	themcgruff has entered the room
	Guillaume V. At our company, we work primarily with websites, and although we, in the office, use git for the versioning.. There are times where someone at home might not have a repo while they're working, and just work directly off the FTP. What's the best method for when they reenter the office with their laptop (or a flash drive) and want to merge those code changes into the master? Could they just make a repo on their machine, and then.. on my repo try to merge theirs in? Make a branch, copy their files in.. and try to merge that against my master? Or something to those effects?
	MatthewMcC @Patrick They keep me kind of out of that, but I certainly will bring that concern to them.
	patrick thanks a lot Matthew!
	MatthewMcC @Patrick I get the need to have many repos, but low disk usage and low user count
	@Patrick Is it just you accessing them?
	3:30 PM
	patrick usually yes, though occasionally need one or two more users
	Robert S. has left the room
	Konstantin D. has left the room
	David has entered the room
	MatthewMcC @GuillaumeV Good question. So basically, what's a good approach for merging live FTP updates with what's in the canonical repo.
	Guillaume V. Yeah, because, the #1 issue we've of course had.. Is overwriting those FTP changes.
	And then a lot of swearing at the fact that git wasn't used... but they sort of couldn't, because they weren't near the repo (which might only be in-office) to grab it.
	MatthewMcC @GuillaumeV Well, first and foremost, I would recommend not doing those edits directly, but I understand I can't prescriptively just say that. ;) Second, I would suggest that
	Guillaume V. haha, of course
	MatthewMcC @GuillaumeV as soon as they get into the office to:
	@GuillaumeV `git clone THEPROJECT`, then `git checkout -b myoffsitechanges1`
	@GuillaumeV Then, ftp wget them down into the current git repo (now a branch)
	Guillaume V. yeah
	MatthewMcC @GuillaumeV Then `git add -A .` which will pick up all the changes, whether they be deletes or adds or renamed
	@GuillaumeV Then `git commit -m"Changes made via FTP for XXX project work"
	@GuillaumeV Then git push those back to your master/central repo.
	Kevin M. has entered the room
	Guillaume V. right, so very similar to the normal workflow for normal changes, only after-the-fact
	MatthewMcC @GuillaumeV I think with a post-commit hook, you could make people want to use Git, even remotely more than FTP.
	@GuillaumeV For example, I have such a hook for http://gradleware.com
	3:35 PM
	MatthewMcC @GuillaumeV When I make a local change to code, I just git commit and push it to GitHub and it triggers a deploy on the FTP server which is actually faster and more efficient for me.
	@GuillaumeV I can also, in absence of tools, change the code through the GitHub Cloud9IDE editor and that also
	Guillaume V. hmmm, that's a very good idea
	MatthewMcC @GuillaumeV results in a post-receive hook firing and deploying the site.
	Guillaume V. and GitHub allows for these hooks to do the uploading, or is a little tinkering needed?
	MatthewMcC @GuillaumeV Even folks who were without tools, and previously determined to make FTP-direct changes are LOVING the fact they get a web based editor with syntax highlighting and no need for FTP tools. Literally, from "web page" edits and directly site deployes.
	@GuillaumeV I can point you at a few common scripts in my sample repo -- Github just needs to be able to "ping" a URL on your server side that triggers the behavior. Typically a call to a PHP file, or similar.
	Mike In a Github private repo, is there a way to increase the storage size for the account but not the repos count. And is there a upgrade charge?
	Guillaume V. Yeah, and on the server's site.. perform the export of the repo's files-- but that's a very excellent idea.
	MatthewMcC @GuillaumeV And the best part is that there doesn't need to be any risk of attack on that public URL. It only "tells" the remote FTP server to get the code from github, which is very trusted.
	Guillaume V. server's side*
	MatthewMcC @GuillaumeV Yup.
	Guillaume V. Thank you very much!
	MatthewMcC @Mike The size limit is pretty soft. If you don't triple it, we are pretty lax. And if you push that soft limit by 3x, you'll get a polite email about it before it becomes a problem. No sudden cut-offs.
	3:40 PM
	MatthewMcC @Mike We try to make you love us. We aren't MegaCorp rule-driven, even if a few rules are posted around the poolside. ;)
	lifo has left the room
	JZ has left the room
	Guillaume V. Re: the size limit: That's very cool.
	MatthewMcC @GuillaumeV Indeed. It really is just to keep folks from backing up their hard disk to GitHub. ;) We love you to host lots and lots of code with us.
	Excellent questions and discussions so far. Anyone that has just joined -- dive right in and ask something. Anything. I'll take a good stab at answering. It can be Git, command line, GUIs, GitHub...
	3:45 PM
	bovine has entered the room
	David I'll be "the one". :D Any plans for Github for Linux?
	Mike How do you push to different remote branch?
	3:50 PM
	MatthewMcC @David I truly (not playing dumb) don't know on that one. I think it needs some helpful pushes via comments on that GitHub for mac blog entry and emails to support@github.com. I will back you up on it.
	@David I do know that the Windows one is baking...
	Kevin M. has left the room
	MatthewMcC @David Of the 10,000 folks that I've taught Git to (I can't believe that number myself, but it is accurate), some vast, vast majority of the Linux users, as I do, love the command line the mostest.
	Fuh has entered the room
	MatthewMcC @David That's not to say they are ignored, but they are largely, largely satisfied with TIG, SmartGit for Linux, Git-Gui, GitK, etc.
	@David but I will still put in a good word, but could use your vote as well via a quick email to support@github.com with that one-line request. ;)
	http://www.delicious.com/search?p=git+gui+linux
	@Mike As for pushing precision...
	@Mike `git push <REMOTENAME> <BRANCHNAME>` For example, `git push origin master`, then `git push otherremote master:myotherbranchname`
	David MatthewMcC: Interesting, thanks. I'll shoot in an email soon
	3:55 PM
	MatthewMcC @Mike The names before and after the colon on the branch names are the "local name" and the "upstream name" respectively. In Git, you can push any local branch contents to a different name on the upstream side.
	Mike: Does that help? Or can I add more precision to that answer for you?
	LOL has entered the room
	Mike That helps, Thank you.
	Guillaume V. One thing I've recently started was an open-source project (which is hosted on GitHub), and it is the basis for a closed-source project.. So as I make advancements for the closed-source one, the open-source code progresses inside it... But, what sort of method should I use to push the code back to the open-source one? As I'd want to exclude portions of overwritten configuration files or exclude entire folders.
	Keeping in mind that I'm not afraid to go through a giant patchfile or something, but just am unsure how to apply it.
	4:00 PM
	MatthewMcC @GuillaumeV A very common use case and easy to do, I think.
	I'd keep a branch for the "public" version of it and that would be your branch you publish to GitHub.
	@GuillaumeV You can checkout the public branch and then
	@GuillaumeV `git merge --no-commit privatebranch`
	@GuillaumeV That would give you all the code, dropped into the branch and staged, but not committed. You could then prune out the closed source and then finish the commit
	@GuillaumeV You could, if only a small portion of the closed source one would go back, use two other approaches.
	suds has entered the room
	MatthewMcC @GuillaumeV You could make all the "OSS" commits to a public branch and then merge those to the closed source (these would still be two branches in the same repo)
	Guillaume V. right
	MatthewMcC @GuillaumeV Or, if it is too hard to tease those out in advance, you could `git cherry-pick <REV>` one commit at a time FROM the closed source over to the OSS branch.
	@GuillaumeV That gives you a OPEN -> CLOSED and a CLOSED -> OPEN and a CLOSED -> OPEN with manual choosing of the commits if using the --no-commit option on a traditional merge.
	@GuillaumeV Additionally, if you turn on rerere (a nice option, to be sure) you can "save" the merge conflict resolution, which is your case, is a misnomer, but still means, "what do you want to keep" after the merge
	4:05 PM
	MatthewMcC @GuillaumeV This would allow for continued merging from one branch to the other without duplication of effort the 3rd, 5th, and 10th times you merged the CLOSED branch into the OPEN branch.
	Guillaume V. Just googled that really quick
	MatthewMcC http://progit.org/2010/03/08/rerere.html
	Guillaume V. It would allow for me to make a lot more human intervention choices?
	MatthewMcC @GuillaumeV It basically is recording how _you_ decide to handle merge conflicts. E.g. "If I see this on the LEFT and this on the RIGHT then I should put THIS on the result and ask the commiter if he likes it"
	@GuillaumeV It will be helpful, I think, in this case you are describing.
	Guillaume V. yeah, that sounds exactly what I've been looking for
	MatthewMcC @GuillaumeV I have also tried another supplemental strategy in which I mark the commits with "OSS: " when I'm typing the commit message and then
	I have a shell script that searches for all of those and cherry-picks them into the OSS branch.
	Guillaume V. riiight
	that would also work very well
	MatthewMcC @GuillaumeV Lots of ideas, all of which I have used. Hopefully that provides you with a smorgasboard of choices that might fit.
	Guillaume V. I think it will also just require a lot finer detail on paying attention to what is going to be going into a merge as well
	MatthewMcC @GuillaumeV Indeed. It definitely does. But I think it pays off in terms of later ease (more brain effort at commit time and authoring time, less at OSSing-time)
	4:10 PM
	Fuh has left the room
	LOL has left the room
	MatthewMcC Well folks, we've come to the end of our first Office Hours session. Since this is a new idea and can be formed by your inputs, please send any compliments, complaints or mild-mannered suggestions for topics, timing, frequency, length and all manner of how-we-should-do-it to training@github.com. I and my GitHub colleages are all ears in helping our community out. I hope this session was useful!
	patrick it was indeed, thanks MatthewMcC!
	joe Thanks for doing it Matthew!
	MatthewMcC @Joe You bet. Tell any and all colleagues if they have stumper Git and GitHub questions to bring them to these sessions. We're here to help.
	@Patrick Thanks for hanging around and asking questions too!
	Jordan has entered the room
	MatthewMcC We'll try to hold these about every week or two
	Guillaume V. Thank you very much for taking the time to answer questions and your original webinar. Very helpful stuff.
	MatthewMcC @GuillaumeV My pleasure to share knowledge.
	Guillaume V. It's so strange going from closed-source and secretive to more.. open sharing and stuff.
	Very liberating.
	4:15 PM
	patrick this idea is pretty sweet, thanks!
	MatthewMcC @GuillaumeV I couldn't agree more. And Coder Wall proves it: http://coderwall.com/matthewmccullough
No results found