![]() It is a tool to write infrastructure as code, or more descriptively, as human readable instructions to define resources that can be run on any cloud provider. Then, some time after that, you need to spin up a new instance, and have to go through all of the manual clicking through the AWS console described before.Įnter terraform. Kept the EC2 for some time and then decided to terminate it, since after all, even stopped, it still incurs some costs. Let me know in the comments if you’re aware of a way to convert it, effectively bypassing this re-cloning step.In the previous post I wrote about how to spin up a EC2 instance with Rstudio server, so some of the more computational heavy R processing can be moved on AWS infrastructure. This last step is necessary because the clone performed in step (1) was a mirrored clone that can’t be used as such for further commits. Replace new-repo-url and new-repo with your new repository. rm -rf new-repo git clone new-repo-url new-repo ④ Push everything to the new repository git push -all git push -tags It goes without saying that you should have had the new repo created beforehand in your favourite Git management system. Replace new-repo-url with the Git URL of your new repository. ![]() ③ Add the remote reference for the new repository git remote add origin new-repo-url Technically speaking, this step is not necessary since as discussed above you can have multiple remotes, however, it makes future commands a bit simpler to type and completely detaches you from the original repository. You may get a warning if your original repository contains branches but you can ignore it. ② Remove the remote reference to the original/old repository cd new-repo git remote remove origin Replace old-repo-url with the Git URL of your old repo and give an appropriate name to the new-repo folder on which it will be cloned. ① Start by creating a mirrored clone of your old repository git clone -mirror old-repo-url new-repo The approach suggested next may not necessarily be “the best out there”, however, it has been tested on repositories with thousands of commits and is honouring two basic principles: 1/ Keeping the complete commit history including all branches and tags, and 2/ not interfering with the original repository. If you search for how to transfer a Git repository you’ll end up with several different suggestions, ranging from simple sequences of Git commands to pure Git black magic. For example, you can search previous commit messages to find an explication that sheds light into an issue you’re investigating if you realise a specific developer is prone to the same type of mistakes, you can easily filter out his/her commits to re-check them, and many more. Keeping historyĬopying resources from one repository to another while keeping commit history intact not only acknowledges everybody else’s original work but might come with useful perks. Any previous commit history, kept in the source repository, is now lost forever and the whole project looks like it has been created by a single person (you).ĭeveloper-god syndrome satisfied original authors pissed off. ![]() Since you are the one committing all the files to the new repository, you are now becoming the sole author of every single file of the source repository. Although that approach might save you a few minutes and doesn’t require any other than the standard Git commands you already know, it comes with a severe drawback. The quick and dirty way is to just clone the new, empty repository, copy/paste the files from the source repository, and commit/push. So, how can we leverage this feature of Git to transfer files from one remote to another? Losing all history (developer-god mode) ![]() We’ve established so far that you can have as many remotes as you wish and that their name doesn’t have any significant role in Git’s ecosystem. ![]()
0 Comments
Leave a Reply. |