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

> 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

Reply via email to