I added a directory to a repository but did not commit the change. Then I removed it, not realizing it would delete the entire directory. To be clear this is exactly what I did:
svn add directory/
svn remove directory/ --force
Is there any way to recover the file or am I SOL?
P.S. Who the hell decided SVN should have two different commands delete and remove that do the exact same thing?
There is no way, through svn, to recover a file that was not committed to svn.
Related
I have a CRUD app that will be used to track trucking appointments. I'm ready to deploy the app, but I'm worried about merging a future branch into the main branch without overwriting the existing information in the database. How can I use CLI git commands to avoid overwriting the data?
These are the general steps I've been using to merge a branch that I've made edits to into the main branch:
>git checkout main
>git merge <branch_name>
>git branch -d <branch_name>
>git push origin --delete <branch_name>
Note: putting test.db within my .gitignore configuration file is not enough.
If it was tracked, you would need to "untrack" it with:
git rm --cached -- test.db
Then you can check your new .gitignore rule is effective with:
git check-ignore -v -- test.db
Production data should not be stored in the same directory as code for many reasons other than worrying that git will overwrite your data. For one, your software shouldn't have permissions to modify itself, even though it needs permissions to overwrite its database. You'll need to search/ask how best to package Python and set up a service on the operating system you'll be using.
git has some safety features that protect untracked files. checkout and switch won't clobber them. But clean is designed to delete untracked files. Worse: reset --hard will overwrite untracked files without warning. Do not put important data in a working directory unless it's part of the project.
I included test.db within my .gitignore configuration file.
I have started developing a website, saved in my local folders, and I am trying to save it to a GitLab repository. I created a new repository on GitLab and then did the following:
cd existing_folder
git init --initial-branch=main
git remote add origin https://gitlab.com/...
git add .
git commit -m "Initial commit"
git push -u origin main
The project comprises two folders, Server and Client, the Client is a React App. However the Client folder is appearing as a red folder icon that can't be opened:
When I click on the initial commit it says that Client has been added as a Subproject commit:
I don't know what this means, I have built websites with a similar structure before and Gitlab has not done this. I just want the contents of both Client and Server folders to be saved in the repo.
What you did:
Created a Git repository holding the client side of the app, and committed stuff to that. This repository resides in client/.git/. It contains files that are presumably named things like main.js and so on (or main.ts and so on, if TypeScript, etc.).
Created, in .git, a second, over-arching Git repository holding the server side of the app, and committed stuff to that. This repository resides in .git/ and contains files named server/functions.js and so on. Git will be calling this second over-arching repository a superproject. It's just a Git repository though, albeit one with one special property.
Note that as far as Git is concerned, folders don't even exist: files just have names with embedded slashes—always forward slashes, never backslashes—in them. Git will convert these to the folder-and-file arrangements that your OS requires, as needed. This deals with any backslash things that the OS requires as well (e.g., converting names from foo/bar.js to foo\bar.js on Windows). But for the most part this is invisible and we can pretend that we have folders full of files; we're going to work with OS-level files extracted from commits anyway, and those really are files-in-folders. So for the rest of this we'll pretend we do have folders.
Anyway, for good (security) purposes, Git refuses to ever store anything named .git. So all the files in client/.git/* literally cannot be stored: you cannot put the sub-repository in client into the superproject in ., even though ./.git holds server/ and all those files just fine.
Instead, Git will add to the superproject something that Git calls a gitlink. This is an entry that says: After you have cloned and checked out a commit for the superproject, clone another Git repository too. In that new, additional Git repository, I have saved the raw hash ID of the commit you should check out in that sub-project.
This is why you see that instruction:
Subproject commit 327f06...88c
That's the thing that makes this superproject Git repository a superproject: it contains a gitlink named client, and the gitlink itself—which is otherwise just like a file—says 327f06...88c. That 327f06...88c hash ID is the hash ID of a commit in the Git repository that Git should clone and place into a client folder within the superproject.
Now, the trick here is that for Git to run:
git clone <url> client && (cd client && git checkout 327f06...88c)
Git is going to need to know the url to use on this command-line. The gitlink records only the commit hash ID and the path name client. The URL goes into a separate file, as chickahoona mentioned, named .gitmodules.
The thing is, when you ran:
git add .
this will not have created the .gitmodules file for you. To create that file, you must use git submodule add instead of git add. The git submodule add command takes the same kind of argument as git add—the name client in this case—but also takes a URL, which it will add to the .gitmodules file in the form that Git will need to run the git clone command later.
You won't have to run this git clone command on your computer, because you already have a Git repository in client/.git. So the fact that git add . only does half the job doesn't affect your use of this superproject/gitlink pairing. But it means no one else can use your superproject because the cloning directive is missing.
What's not clear is whether you, personally, want to store your server and client in two separate Git repositories like this—one a superproject and one a submodule—or whether you want to store this in, say, three Git repositories:
one for the server only,
one for the client only, and
one to bind them.1
The last one would be the only superproject in the setup, containing only two gitlinks and a .gitmodules file referring to the two submodules. The server's files would be in a Git repository stored in server/.git and the client's files would be in a Git repository stored in client/.git (as they are now).
Or, perhaps you don't want any submodules at all. In this case, you will need to remove the client/.git folder (or move it elsewhere). This will destroy (or move elsewhere) the entire repository containing the client. You will, however, retain any working tree files from that repository. Now that the inner repository is gone, those working-tree files can be git add-ed to what was the superproject. These files will have named like client/main.js and Git will create a client/ folder and extract them to files named main.js and the like within that client/ folder.
Only you can decide what you want done here. Decide and then proceed: either add the submodule correctly, with git submodule add, or turn the server into a submodule as well and add that, or remove (or move) the client Git repository but not the current version of the client files.
1Three rings for the Elven-kings under the sky,
Seven for the Dwarf Lords in their halls of stone...
My guess would be that you were doing a git init in the wrong folder. Now your Client folder is maybe a submodule of the actual top git repo.
Check if you have in your Client folder a hidden .git directory
To fix that remove the .git folder in the Client directory. Also check for a file called .gitmodules in the top folder and remove it if it exists.
In react-boilerplate I ran the 'clean' command and deleted all of my work accidentally before committing to git.
I thought this would only delete the react-boilerplate related files that were unnecessary. How do I get these files back?
That command is calling the rm delete command on the shell, so unless your work has ended up in your recycle bin I'm pretty sure it's gone forever.
I've spent a whole lot of time on stackoverflow/google trying to figure out a solution for this problem. May be the solution is simple and I am missing something.So I have a pre-commit hook(shell script) which runs few tests on committed files. If a committed file fails a test, it is removed from the stage. I want to printout all the unstated files from inside the script. Here's what I have tried so far from inside the script.
git diff --name-only --diff-filter=M
git ls-files -m
git diff --name-only
All of them throw the same error as shown below:
fatal: This operation must be run in a work tree
P.S. I am running this inside .git folder(since hooks reside there) and hence the error.
Any suggestions would be really helpful.
I asked a colleague of mine and he came up with a solution specifically for shell script. Sometimes you just have to think simple!
Just change the directory using "cd" and run the command once you are outside the .git folder.
add the following at the top of your script assuming your hook .git/hooks/
#! /bin/bash
here=`dirname "$0"`
cd "$here/../.."
I have jenkin's job, which copy tar file from linux user folder and then copy binary file (compiled) from another job and make new tar file. Then jenkins user can copy that new tar file from jenkin's workspace.
It doesn't build anything or take files from SCM. Then after a while, suddenly tar file has been deleted from workspace, I have to run job again. How I can prevent that?
You really shouldn't rely on your workspace existing after a job has completed, as the workspace can be overwritten by another build starting, or when someone deletes a build, by a slave going offline, etc...
Since you want to save the file for later use, you should use the "Archive the artifacts" option in your job's post-build configuration. If you enter **/*.tar, for example, Jenkins would save all TAR files at the end of the build.
Then you can use Jenkins' permalinks to access the artifacts, e.g.:
http://JENKINS/job/JOB_NAME/lastSuccessfulBuild/artifact/bin/my-app.tar
As the URL suggests, this would give you the file from the last successful build.
As a sidenote, if you then want to copy archived files to another build, the best way to do this is with the Copy Artifact plugin.
That way Jenkins handles the file copying for you, even across multiple Jenkins slaves, and you don't have to do anything nasty like hard-coding paths to other Jenkins workspaces.