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!
On Mon, Jun 17, 2013 at 8:39 AM, Joel McGahen [off-list ref] 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".
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 [off-list ref] wrote:
On Mon, Jun 17, 2013 at 8:39 AM, Joel McGahen [off-list ref] wrote:
quoted
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".
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: iveqy@iveqy.com
On Mon, Jun 17, 2013 at 9:56 AM, Joel McGahen [off-list ref] 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.