I am currently doing an end of year project and we're using GitLab. This is the first time I am using this and was confident about it until the following problem occurred.
After creating the clone, I've been working on my project and committed quite a few files to the school server by using git push after doing the prerequisites of git add and etc.
Now, I've decided to completely start again. I deleted everything manually from GitLab and then all the files from within the folder where the clone directs to. I started working on my new work in a separate folder - while still working on my new file, I decided to move all the files to the previous file where I deleted everything, where the clone was originally set for GitLab to save my files within the schools server.
When typing git status, the following appears (Please excuse the picture instead of me inserting the code in here. I tried entering the output on the console in here but was having editing problems).
I don't understand how to fully delete everything. So, I want to get rid of all Changes to be committed: and Untracked files:.
If you want to push there nothing to do with git status . git status only shows what been added to your repository before commit.
Related
I currently work on solutions / projects within a single GIT repository, in Visual Studio. The commits I make are to a local folder on the Visual Studio server, and then I use the command 'git push origin master' (after having changed directory to my local folder / repository) to push commits to a Gitlab in my company's corporate space. The purpose of this is less about using branches and software development (as I am the only person who does any work on this), and more about having a way to rollback changes and keep a master copy off the server.
I now want a fresh copy of this GIT repository, so I can use that as a new baseline for an application migration. I will still continue to work on the existing repository too.
What is the best way to make a copy of the existing repository, that I can treat as a totally separate thing, without accidently messing up my existing config on the server? Should I do the clone from the Gitlab? Or clone locally and then push that up to the new space in my Gitlab? Honestly, I'm a bit confused at this point about the proper model for this stuff.
....................
Sounds like you'd like to fork the project: keep the existing repo and start a new, separate repo based on the old one.
Browse to your project in Gitlab
On the main repo screen, click "fork" in the top right
Select a new/ the same organisation as you'd like
The project is now forked!
From here, you can clone the fork to your local machine in a new folder. These are now separate projects, and code updates can be added, committed and pushed to the separate repos.
I want to use the git-branch npm module to detect my branch in the code, but Heroku doesn't show the .git folder, so git-branch displays an error.
Is there a way to make that I can access that file?
If not, can I use a workaround, like copying the file and then restoring it, or stuff like that?
I'm auto-deploying from GitHub a Node.js app.
No, there is no way. Heroku will not send the .git folder to the build.
Even if that folder were kept, you would always see the master branch though, as it's always what you push to.
However, you can still retrieve the pushed GIT commit (not the branch) using the dyno metadata feature, which will set environment variables with various informations about your app. HEROKU_SLUG_COMMIT will be the commit you deployed.
I'm moving my current server contents to a new one, and am currently in the process of setting up SVN. I'm fairly unfamiliar with SVN, typically using it to the extent of commits and updates.
I have two locations that I use SVN on the old server:
PROD location:
/var/www/html/new_dwutils/
and local:
/home/{user_name}/public_html/new_dwutils/
My interaction svn-wise is normally committing and updating at the /new_dwutils/ level.
Note: Running svn --version says I'm at version 1.6.11 for both servers.
I'm now trying to recreate this structure on the new server. My initial thought was to create the svn repo using something like:
svnadmin create /var/www/html/new_dwutils/
This creates the repo dir, but, when I copy my files into the dir, I am unable to do svn commands like status. However, when I go into a sub-dir of the copied data, I can use the svn commands.
This has me thinking that the repo is /new_dwutils/ and the copied data is considered a project? And the sub-dirs are working copies then?
Going off that thought, I deleted the repo, and made the html dir a repo:
svnadmin create /var/www/html/
I then copied my new_dwutils dir, and sure enough, I was able to do svn commands like I use too. What I've noticed is that when creating the repo, a few things are added that were not on the previous server: conf/, db/, format, hooks/, locks/, and README.txt. I get that these are svn files, but I'm not seeing the .svn file. I know that there was an update for svn that "removed" .svn files, but these files are now in /var/www/html/.
Now I want to setup my local working copy.
I've been doing (location /home/{user_name}/public_html/):
svn checkout file:///var/www/html/
Problem is it copies the html/ file, but nothing in it, and I don't want the html/ file I want the html/new_dwutils/ file.
I feel like I'm doing it wrong from the start, and would greatly appreciate some explanation on how to get on the right track. A step by step would be extremely useful, and if further clarification is need for files or directory paths, I would gladly detail.
Thanks!
The Subversion Manual will answer all of your questions.
If you're making a Subversion repository under /var/www.html, I'm assuming you're using Apache httpd as your server. Look at Chapter 6. If you already have a repo, create a dump file, then use that dump file to recreate the repo. Look at Chapter 5 on moving repositories.
If you don't know anything about Subversion, or are confused by the difference between the repository location directory and a working directory, read the on-line manual. It's one of the best pieces of documentation I've seen.
From description of your question it appears that '/var/www/html/new_dwutils/' is your working copy and not a repo.
Go to '/var/www/html/new_dwutils/' on the old server and type "svn info" this should give you location of the old repo. You should simply be able to 'svn co ' into the new location to checkout a copy of all your files from the old server (everything that is checked in - you will not get anything that is not checked in on the old server).
However, if your repo was local on the old server and you want to move it to your new server too. Then you can simply copy the entire folder to the new server and access it directly using its new location in 'svn co' command.
I have been going through documentation and such and have SVN working, but I want to put it on an existing directory. I imported that directory, so do I rename/delete the non SVN directory and then checkout the SVN to the non SVN directory location? I am just trying to understand how to get it to start posting to our website URL.
If so, is there any way to keep the current non SVN and make it SVN rather than import and overwrite?
Thanks, I am trying to understand SVN, but find a lot of the tutorials and such on the web to be confusing.
Yes, you have it exactly. Once your code has been added to the repository, you can get rid of or rename your original code directory. Then checkout the project from the repository into the same location as your previous code and continue working from there.
UPDATE
To make it so that your website is updated from the repository, you actually need two working directories, and a repository.
Repository: The repository stores the code and changesets, but isn't directly accessible as a file system. Keep a backup!.
Working directory 1: You develop and test your code from a working directory checked out from the repository. Commit changes back to the repository.
Working directory 2: Rename the code directory on your webserver. Checkout a copy of the code to your web server in its place. Technically it is now a working directory, since it contains the .svn metadata directories, though you won't usually make changes here.
Make changes to your code from your development working directory (1) and commit them back to the repository. When you are satisfied that they are working correctly and have been properly tested, on the web server's code copy (2) do svn update (or if you're using Tortoise SVN on the web server, do an update). This will synchronize the server code with the current development version.
Subversion will not automatically push updates to your web server. You will need to pull them in with an update when you need to. It is possible to use what's called a "post-commit hook" to cause Subversion to execute a script when commits are made, and that script could update or export code to your production web server. However, you would need to write the script and it's kind of an advanced usage of Subversion. I would recommend trying out the method I described with a working copy on the web server to get accustomed to the workflow befrore trying anything more complicated.
Addendum If you really want to do this (and I don't really recommend it unless you really test well) a very easy method would be to schedule a cron job that does svn update every couple of hours (or minutes) on your production site.
Don't forget that if you do happen to modify your code directly on the web server, you must commit it back to the repository from there, and do an update on your development working copy.
In subversion I'm trying to commit a project but running into an issue.
The error I get is
Illegal repository URL ''
How come I can run update, but commit on the same tree shows that?
Try this, it worked for me:
Create a folder.
Right button over folder and create repo here.
When pop up appears select create folder structure and then open folder.
When repository browser appears you see tags branch etc, right button again and create folder but now with tool tortoise.
Update you file to folder.
After some hunting around it seems that a few other people have experienced some sort of local corruption at the top level their checked out project directory which is where I was committing from.
I followed the same procedure that was used to solve those cases which is to back up the sources. Check out the project again. Finally copy the changed files back over the freshly checked out copy. Check it builds correctly. And then commit that.
It seemed to solve it for me.