Re: New User Question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 17, 2013 at 9:56 AM, Joel McGahen <vin4bacchus@xxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]