If I try to delete a repo in kallithea/rhodecode I get this message:
Cannot delete it still contains attached forks
I know that there is a fork of this project. The fork should survive, but the original should be deleted?
How to delete the repo?
I found the answer myself.
Go to the fork (example foorepo-new): Options/Settings/Advanced.
Set "fork of" to empty.
Now deleting of the original repo is possible.
In RhodeCode Enterprise 3 we also added now option to detach, or delete forks when deleting origin repo.
This way you can decide what to do with a when you have a lot of forks
Related
I'm new to git and have a git repository that I use with GitKraken.
In this repository I have multiple branches, and can move from branch to branch in order make modifications where necessary.
I am now in a situation where I'll be making some large modifications to 1 branch that I do not want to commit but in the meantime I would like to make some minor modifications to another branch.
I'm used to work with TFS and there I can just checkout branch to another folder.
I've tried to just copy the folder and my first impression is that this should work....
But, I have seen online remarks that say that I should clone a repository instead.
The git version is lower then 2.5 so I can't use Git-worktree.
Is it ok to just copy the folder or can this have an unexpected effect?
Yes, if you copy the whole folder from the root of the checkout, including the hidden .git folder, then you can make changes to each working copy independently. Each contains their own copy of the repository objects and they will behave exactly as if you have run two separate clones.
As discussed in the comments this isn't necessarily a good use case for this, though: it would be easier (and more disk-space-efficient) to commit your large changes to a local branch so that you can then switch and make other changes. There's no real downside to this; if you do want to remove that temporary commit later then that's easily done as well.
However if you are going to do this, then you probably want to
run a git repack -ad first, so that there are fewer files in the objects tree to copy
consider using git clone --reference instead, which might be slightly more disk-space-efficient
or you want a clean working copy you can create a new working copy folder, copy only the hidden .git folder into the new working copy and then git reset --hard to check out all of the files there too.
You may want to see if git stashing will work for you. I don't recommend copying to a new folder. Mostly because I don't know if it's even possible and I've never seen that as a recommendation. Cloning should also work but it sounds like you are interested in shelving/stashing vs. committing your changes in branch1 before checking out branch2.
https://git-scm.com/book/en/v1/Git-Tools-Stashing
After working on something for a while, I thought I should put it in a git repo. Using gitlab, I created a new repo and cloned it from the command line onto my Windows 7 machine. This created a folder with a .git folder in it. I then copied all the files I'd been working on into the folder. I then noticed that the command line where I had cloned the repo was asking for a password. I entered the wrong password a couple of times and stupidly hit ctrl+c. Next thing I knew, the folder with all my files was gone. It is not in the recycle bin. Is there any way to restore these files?
Unfortunately, they are lost and git won't help you here. You should rely on file recovery tools to help you recover the files (long, hard and boring process) if you can afford to rewrite your code from scratch.
Buy I could tell you what you did wrong with git and what you should have done to never have been in such a situation...
You should have done :
1. Create a local repository in your project directory with 'git init'.
2. Do as much development and commits as you want (but at least one...). You are now protected against file deletion!
3. Once you think it worth to be shared, like you do, create the repository in gitlab.
4. Add the gitlab repository as a remote in your local repository.
5. Push the history to the gitlab central repository.
Like that, you should have avoided all the risky action you did and your work is secured at all times.
Standard methods for removed file restoration apply:
Suspend any user operations on the HD (don't create/copy/remove files). This will increase your chances when trying to restore.
Check if you have the file copies/originals in other folders. You mentioned that you had copied them previously into git folder. May you have them in the original directory?
Do you have any backup system running (like Crashplan, etc) ? Check if you have a backup of the files
If nothing of the previous helped proceed to the undelete operation - use dedicated utilities like this one for ex.: http://www.ntfsundelete.com
I am new to Git. I wrongly uploaded my code into GitHub repository with push command using Xcode source control. Then I asked a question that how can I delete the content of the master, because I thought that deleting files is enough to have a fresh start. (NB: I cannot delete the repository and create a new one) so I deleted every single file in repository with push command and the repository is empty now. When I try to pull my local working copy this time, my local working copy got deleted.
Does anyone know how can I pull my code?
There are two ways to go about fixing this problem.
Rewrite your history and push the rewrite to master (not recommended, because it will screw up everyone else's history as well, but has the benefit if making it appear that you never made a mistake)
Make a new commit reverting your changes and push this new commit. This keeps your old code in the repository but removes it from subsequent versions. It also has the added benefit of not screwing up everyone else's history.
To accomplish #1, simply run git log and find the commit ID number, then run git reset NUMBER to revert your tree to the working state. Then push your changes with git push RemoteName BranchName --force
As I mentioned, I strongly recommend against doing that unless you have some major privacy concerns over your mistake. A much better way to handle the problem is to run git revert CommitID to create a new commit that "undoes" your previous mistake. Check out this Atlassian blurb for a bit on how to do that.
I opened a project yesterday via Open From Subversion
I accidentally saved the project to C:\Users\blahblah....
I then immediately closed the project, and Opened From Subversion again, saving it to the correct directory.
Now I'm trying to commit the changes I made since opening the correct project and I'm getting this message:
Is there a risk that I can screw things up if I deselect C:\etc and instead select D:\etc and commit that?
There are no changes to the C:\ project. Also, I now have to merge the changes from yesterday into another branch.
This dialog appears whenever more than one working copy is involved and is mostly seen when changing your code and an external. It means it will commit your code and the external separate because this is dealt like different working copies and so this must be done.
In your case your solution was partly saved somewhere else making a second working copy (from the same repository). Guess you did the right think when deleting the mistakenly created files.
I deleted the C:... solution. It seems to have done the trick because the D:.. solution committed ok after that.
In showing a colleague how to use SVN yesterday, we created a test folder and file within our existing Visual Studio Solution. We'll call it "Test" folder with two files, "Test.ascx" and "Test.ascx.cs". We added it (or Visual SVN added it, 'cos it's awesome), and committed it. We also added and committed other files elsewhere in the project.
We can see it in the repository (and the other files).
Doing an update on my own machine to pull down these new files resulted in the other files being pulled down correctly, BUT the Test folder does not appear. No matter how many times I try Updating from various points in VS and in TortoiseSVN (urgh) Repo browser, it can't see that there are any changes to pull down.
Where am I going wrong?
This is a known problem.
You can use
$ svn update --depth=infinity
to force the update. With TortoiseSVN, use the "Update to revision" command in the Submenu, then change the depth combobox to "fully recursive".
I've had ghost errors like this before and found the easiest work around is to delete the parent folder and update it's parent:
Project Root
Project
NewFolder
Delete Project, then Update Project Root
We can see it in the repository (and the other files).
...
No matter how many times I try Updating from various points in VS and in TortoiseSVN (urgh) Repo browser, it can't see that there are any changes to pull down.
So you can or cannot see it in the repository browser?
Did you commit and update the parent folder of your Test folder?
I don't know, svn is always telling me to clean, did you try that?
It's not an answer, I know, but I have tried all the solutions you guys have kindly suggested and I just end up with conflicts, crashed TortoiseSVN and built up Karma. Therefore, a trusty edit in the .svn/entries file sorted it.
I have until now been a single developer using SVN just to manage my source code. Other people don't have problems, and I just check in stuff. I use Visual SVN as a layer to frig SVN for .NET (which it isn't great with) and I seem to constantly run into issues. I am performing very simple operations, not even branching/tagging. Simple simple simple. And yet I have issues with it?