Re: New User Question
On Mon, Jun 17, 2013 at 8:39 AM, Joel McGahen vin4bacc...@me.com wrote: What I need to understand is how to a) Connect my developer's VM local repos to the new remote repo I created so they can continue to work. b) Once the contractual issues are resolved reconnect the developer's local repos back to the original orgin/master repo and merge all their changes. Git stores information about remotes in the .git/config file. You can either edit this file directly to change which URL orgin points to, or you can use the git remote commands to make the same changes. You can read the documentation by typing git help remote. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New User Question
Thanks William. You response is much appreciated. Should I have just changed the origin URL in the first place to point to my new local repo? What I did was to just add another remote with a different name (temp_repo). So if I do git remote I see origin and temp_repo. I then pushed to temp_repo. Or should I have pushed as I did and then change the origin to the new repo location? So If I would git remote i would still only see one (origin) but it would point towards the temp_repo location? On Jun 17, 2013, at 12:51 PM, William Swanson swanson...@gmail.com wrote: On Mon, Jun 17, 2013 at 8:39 AM, Joel McGahen vin4bacc...@me.com wrote: What I need to understand is how to a) Connect my developer's VM local repos to the new remote repo I created so they can continue to work. b) Once the contractual issues are resolved reconnect the developer's local repos back to the original orgin/master repo and merge all their changes. Git stores information about remotes in the .git/config file. You can either edit this file directly to change which URL orgin points to, or you can use the git remote commands to make the same changes. You can read the documentation by typing git help remote. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New User Question
On Mon, Jun 17, 2013 at 11:39:44AM -0400, Joel McGahen wrote: I have a question about GIT remote repos. Here is my scenario. 1. Work client has a repo (origin, branch of master). 2. Due to contractual issues I need to host a remote copy of this repo that my developers can utilize while we get the contractual issues resolved as development must continue. 3. I have a virtual machine from the client which already has a remote of origin setup. 4. I have created a bare repo on a server my developer's have access to. 5. I have added that remote to my copy of the client VM local repo and pushed its contents to my newly created bare repo. What I need to understand is how to a) Connect my developer's VM local repos to the new remote repo I created so they can continue to work. b) Once the contractual issues are resolved reconnect the developer's local repos back to the original orgin/master repo and merge all their changes. I'm fairly new to GIT but have worked with version control for a long time (CVS, PVCS, Subversion etc). Any help would be greatly appreciated! Hi! The short answer is: git remote add (and git help remote for details). It's also possible to manally edit .git/config if it's basically just a adress change you're doing. The long answer is harder. You've experience with centralized systems. Remember that git is decentralized. Every developer you've is a fully functional unit on his own. All you need is a way for the developers to interact with eachothers. It can be done via e-mail, or with them pulling from eachother directly or as you've done, with one central repository that everyone sync to. The questions you've is rather fundamental to git. I tells me that you do not fully utilize the strengths of git. I suggest reading the progit book. Good luck! -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New User Question
On Mon, Jun 17, 2013 at 9:56 AM, Joel McGahen vin4bacc...@me.com wrote: Should I have just changed the origin URL in the first place to point to my new local repo? What I did was to just add another remote with a different name (temp_repo). So if I do git remote I see origin and temp_repo. I then pushed to temp_repo. A remote is just a shorthand for a specific URL. All the commands that take remote names, like push, work just as well with raw URL's. Configuring a remote is basically a way to save time typing the URL. As Fredrik pointed out, Git is completely decentralized, so there is nothing special about the remote repositories. When you do a fetch, the local repository basically says, Hello remote, please send me all the commits you have that I don't have. When you do a push, the local repository basically says, here are all the commits I have. Please take any ones you don't have. The two repositories simply act as peers. Or should I have pushed as I did and then change the origin to the new repo location? So If I would git remote i would still only see one (origin) but it would point towards the temp_repo location? If you look in a repository's .git/config file, you may see some per-branch config options that refer to specific remotes, like this: [branch master] remote = origin In this case, you can just edit the config file to point to temp_repo, either by hand or by using a command like git config. Or, if you prefer, you could change origin to point to your new server. How you configure things is up to you and what works best for your workflow; git is happy either way. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html