Re: [git-users] Regarding cloning and best practices
There was a tutorial'ish post here on the list a few days ago about named remotes. If you clone a remote repository, a named remote is created, called origin, and your local master (or whatever) branch is set to track origin/master. Now if you change origin's URL (git remote --set-url user@host:new-repo.git), and do a git push, your changes will go to the new repo. Best, Gergely On 28 Aug 2013 16:55, Jaace jb5...@gmail.com wrote: Here's my situation and I need advice on what the best way to handle it is as I'm newer to Git. I'm using these repositories as my own and I'm not working in tandem with anyone else but I want to keep my workflow clean and able to incorporate anybody I add to the project later. Here goes: I made a repo as a starting point for all my projects -- the idea here is to clone this repo to use as a base for any new project I start. I want to be able to clone it and then never check it back into the repo I cloned it from, but instead create a *new* repo for that specific project. When you clone a repo, it sets up a .git directory and all that but if I were to push any changes, that would push them back to the original I cloned it from, right? So is the proper way to go about doing what I want to simply delete the .git directory that comes with the cloned copy and just git init a new one or is there a better way to do this? Thanks, Jason -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Regarding cloning and best practices
Thanks for the quick reply Gergely! I will look into doing this On Wednesday, August 28, 2013 11:00:10 AM UTC-4, Gergely Polonkai wrote: There was a tutorial'ish post here on the list a few days ago about named remotes. If you clone a remote repository, a named remote is created, called origin, and your local master (or whatever) branch is set to track origin/master. Now if you change origin's URL (git remote --set-url user@host:new-repo.git), and do a git push, your changes will go to the new repo. Best, Gergely On 28 Aug 2013 16:55, Jaace jb5...@gmail.com javascript: wrote: Here's my situation and I need advice on what the best way to handle it is as I'm newer to Git. I'm using these repositories as my own and I'm not working in tandem with anyone else but I want to keep my workflow clean and able to incorporate anybody I add to the project later. Here goes: I made a repo as a starting point for all my projects -- the idea here is to clone this repo to use as a base for any new project I start. I want to be able to clone it and then never check it back into the repo I cloned it from, but instead create a *new* repo for that specific project. When you clone a repo, it sets up a .git directory and all that but if I were to push any changes, that would push them back to the original I cloned it from, right? So is the proper way to go about doing what I want to simply delete the .git directory that comes with the cloned copy and just git init a new one or is there a better way to do this? Thanks, Jason -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Regarding cloning and best practices
On Wed, 28 Aug 2013 07:55:11 -0700 (PDT) Jaace jb5...@gmail.com wrote: [...] I made a repo as a starting point for all my projects -- the idea here is to clone this repo to use as a base for any new project I start. I want to be able to clone it and then never check it back into the repo I cloned it from, but instead create a *new* repo for that specific project. When you clone a repo, it sets up a .git directory and all that but if I were to push any changes, that would push them back to the original I cloned it from, right? No. `git clone`, being a pretty high-level command, does certain convenience magic with the local repository it creates and populates, which ties it to the original repository. But in fact these ties are very loose, and are rooted in a single bit of the local repository configuration, which is the named remote -- origin. `git clone` goes like this: 1) Initializes a local repo (possibly creating a directory for it first). 2) Adds a single remote named origin to the repository's configuration. 3) Runs `git fetch origin` which makes Git fetch all the branches the remote repository has, and create a single so-called remote branch (these are those origin/master, origin/devel etc branches you can list by running `git branch -r`) for each branch the remote repository has. 4) It then asks the remote where its HEAD reference points, and, if it points to a branch (true in 99.9% cases), creates a local branch in your repository which is linked to the matching remote branch in it (created in step 3). Most of the time remote repositories, being bare, have their HEAD point to a branch named master, and that's why `git clone` most of the time ends up creating a local branch master which is set to track the remote branch origin/master. If you feel yourself lost in these remotes, remote branches and remote-tracking branches, then read [1] and [2], in this order (reading the whole book before embarking on using Git is highly recommended); also see [3]. So is the proper way to go about doing what I want to simply delete the .git directory that comes with the cloned copy and just git init a new one or is there a better way to do this? It's so simple it's ridiculous -- just do git remote set-url origin GIT_URL_OF_ANOTHER_REPOSITORY and then all Git commands to which you supply the name origin would reach for that new URL. That URL, obviously, should be of a new repository (supposedly created somewhere using `git init --bare`). 1. http://git-scm.com/book/en/Git-Basics-Working-with-Remotes 2. http://git-scm.com/book/en/Git-Branching-Remote-Branches 3. http://gitready.com/beginner/2009/03/09/remote-tracking-branches.html -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Regarding cloning and best practices
Awesome, thanks! On Wednesday, August 28, 2013 11:23:22 AM UTC-4, Konstantin Khomoutov wrote: On Wed, 28 Aug 2013 07:55:11 -0700 (PDT) Jaace jb5...@gmail.com javascript: wrote: [...] I made a repo as a starting point for all my projects -- the idea here is to clone this repo to use as a base for any new project I start. I want to be able to clone it and then never check it back into the repo I cloned it from, but instead create a *new* repo for that specific project. When you clone a repo, it sets up a .git directory and all that but if I were to push any changes, that would push them back to the original I cloned it from, right? No. `git clone`, being a pretty high-level command, does certain convenience magic with the local repository it creates and populates, which ties it to the original repository. But in fact these ties are very loose, and are rooted in a single bit of the local repository configuration, which is the named remote -- origin. `git clone` goes like this: 1) Initializes a local repo (possibly creating a directory for it first). 2) Adds a single remote named origin to the repository's configuration. 3) Runs `git fetch origin` which makes Git fetch all the branches the remote repository has, and create a single so-called remote branch (these are those origin/master, origin/devel etc branches you can list by running `git branch -r`) for each branch the remote repository has. 4) It then asks the remote where its HEAD reference points, and, if it points to a branch (true in 99.9% cases), creates a local branch in your repository which is linked to the matching remote branch in it (created in step 3). Most of the time remote repositories, being bare, have their HEAD point to a branch named master, and that's why `git clone` most of the time ends up creating a local branch master which is set to track the remote branch origin/master. If you feel yourself lost in these remotes, remote branches and remote-tracking branches, then read [1] and [2], in this order (reading the whole book before embarking on using Git is highly recommended); also see [3]. So is the proper way to go about doing what I want to simply delete the .git directory that comes with the cloned copy and just git init a new one or is there a better way to do this? It's so simple it's ridiculous -- just do git remote set-url origin GIT_URL_OF_ANOTHER_REPOSITORY and then all Git commands to which you supply the name origin would reach for that new URL. That URL, obviously, should be of a new repository (supposedly created somewhere using `git init --bare`). 1. http://git-scm.com/book/en/Git-Basics-Working-with-Remotes 2. http://git-scm.com/book/en/Git-Branching-Remote-Branches 3. http://gitready.com/beginner/2009/03/09/remote-tracking-branches.html -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
