At some point during my adventures with Linux, I decided that it would be a good idea to put everything in my home directory into source control. I'm not asking whether that was a good idea or not -- I'm asking how to undo it.
The reason for removing the repository is that I recently installed Oh My Zsh, and I really like it. The rub is that my home directory has a big git:(master) stuck behind it, and I'm just not a huge fan of that.
So what I would like to do is remove the git repository itself, so that the git:(master) is no longer displayed, without deleting all of my files.
Just remove (or rename) the .git subdirectory. That subdirectory is the whole of the repository. This will not delete your files, but it will delete their history.
Additionally, there might be files like .gitignore and .gitattributes that are not necessary anymore.
Make sure that all your files are present in the working tree before removing/renaming .git.
Your repository resides in the .git directory, you can delete it easily. But if only the prompt disturbs you, it is enough to search where PROMPT gets new value in your environment and modify it to something else.
Removing the directory .git in a repository removes the history, and keeps the files currently checked out - it does not keep all files.
Warning: this may not be what you need!
The history contains earlier states of files, files that were removed at some time, and other branches, containing similar, up to date files similar to the currently checked out, or completely different ones.
That means, in the general case, removing the .git affects files that where in the repository tree earlier, and files that currently - in the newest version - exist in other branches. All these would be deleted too!
The answers proposing to just delete .git apply only in the simplest case,
where you only added files to the master branch since creating the repository, and master is checked out.
Related
If your repository has a few paths that are synced by the repo tool using a manifest-file/group/branch & you run the repo commands (init->sync->checkout) again in the same repository but with some other manifest-file/group/branch having a different set of project paths then the current execution of the repo command will remove/delete the unnecessary project paths.
At least, what I expected from the repo tool was that the project paths which were not relevant to the current execution to be kept as is.
But, instead, you'll see a sequence of log lines saying the obsolete paths have been deleted as they were not necessary.
Deleting obsolete path /path/to/other/project1
Deleting obsolete path /path/to/other/project2
Deleting obsolete path /path/to/other/project3
Deleting obsolete path /path/to/other/project4
Repo tool has this by design.
I looked at multiple problems over the internet for solutions but couldn't find any.
Finally, I could design my own WAR.
Internally, the repo tool decides which paths to keep & which to delete in 2 ways.
If the paths to be deleted has some changes then it ignores deleting them.
By comparing the project.list file in the .repo folder & only keeps the ones listed in it.
Method 1 wasn't much useful for me as before the checkout I happen to reset the entire working tree.
On the other hand, Method 2 was what I needed.
WAR
Update the project.list file in .repo folder of the repository to remove the paths that you think the repo tool should not delete.
Let's say I don't want repo tool to mess up my path "/path/to/other/project3" then I would remove this line from project.list file.
My request may look strange but it'd make more sense after I explain why I'm doing it.
So I have my person projects under /path/to/myprojects. Underneath maybe C, Perl, Shell, Tcl, etc. Now I want to put those project groups (C, Perl, etc) under git, but in different location, e.g., /path/to/mygits/.
The reason that I want to do this is that, traditionally I backup my /path/to/myprojects to other locations by rar them first. Since they are all text based, rar them up will yield excellent compression ratio. Now I want to keep the same practice, even I've introduced git. Thus I need to keep the binary git repository out of the way of my text base folder into a separate binary base folder.
All my findings on stackoverflow indicate impossible, or I "have to use submodules which can be quite painful":
Git: Different Working Directory and Repository location,
git repository with folders in different locations,
Add Separate Directories/Projects/Files to Git Repository
However, there is one answer that says it is possible to decouple the git working directory and git repository directory:
how do I change the location of a Git repository
but it says something about git reset --hard which I want to know the details.
Also Using GIT_DIR seems to be another solution.
Anybody can help?
Thanks
Alright, enough waiting, let me answer my own question.
As DCoder has pointed out, the answer is at Can I store the .git folder outside the files I want tracked?.
I.e., there are many git based solutions listed there, all needs some extra
git configuration. You might have to do them if under Windows. However, under Linux, symlinking the .git directory to somewhere else is the easiest and cleanest solution.
I have added a file (say SomeFile.cs) to a specific folder. I did not commit as I wanted to do commit at once after achieving the functionality. An svn update worked just fine on this until someone changed the folder name and changed the names of files under it.
Now the next day when I did svn checkout, resulted in tree level conflicts, so I copied my newly added files to this "new" location and did as "Resolve using theirs".
The resolve deleted all my local files and replaced with new folder and files. I could not find my local files (which were in my working copy) in my entire computer (includint recycle bin).
Now is there at least an option to retrieve the files which were added ("Add" option) to svn and NOT committed to svn using "Commit"?
Regards
AFAIK, only files committed to svn will be recoverable. But if you merge the conflict with theirs, then it would have overriden the changes locally.
Try to "Update to revision", but as your files were NOT committed it will most likely restore your directory structure in best case scenario.
Generally "Resolve using theirs" option is an equivalent of saying "I screwed up, they are right" -> whatever I have is wrong, and what they have is right -> overwrite my copy.
What you are asking for is pretty much against the workflow of SVN. Things don't get stored in the repository until they are committed, and are thus not "safe". You are supposed to commit often.
If you are trying to work but worried about other people's tree changes getting in your way, consider making a branch.
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.html
However, SVN should never overwrite files in your local working copy that have modifications. If you do an svn update, and someone has added/changed something, you will get a "conflict", which you will have to resolve manually. You resolved these conflicts manually, and accidentally overwrote you work. This is why you should commit often. Anything you commit can be recovered.
I am trying to figure out svn:ignore. I am using:
svn propedit svn:ignore file://path/myrepository/project
Within there I am adding 'files' to that and then saving. It commits the revision fine. When I now go to a machine to SVN Update it, it downloads the files directory. How come that isn't applied? With SVN, do you need to apply things by doing some sort of restart? I am using a Red Hat Linux box.
Thanks.
EDIT:
Looks like I misunderstood ignore.
svn:ignore only works for untracked files. once you have added a file to your repository it cannot be ignored again (unless removed again). Why should you ignore a file that you initially wanted to track?
svn:ignore only saves you from accidentally adding garbage (build products, backup/swap-files, log files, etc.). It will not forbid downloading of files from the repository (if I understood your last sentence)
I am working on a shared project which is put in SVN. The directory structure of the project is as follows:
ParentDir
- Child_Dir_1
+ GrandChild_Dir_1
+ GrandChild_Dir_2
- Child_Dir_2
Child_Dir_1 contains configuration files (Eclipse's .LAUNCH files), and people put all sorts of file in this folder.
So each time I update my source code (by right clicking on ParentDir and picking Update), I got a lot of configurations that I don't really need, and I have to delete them manually.
I still need to have the children of Child_Dir_1 (which are GrandChild_Dir_1 and GrandChild_Dir_2) to be updated.
I have tried to go to set the "ignore" property of the of Child_Dir_1 to exclude *.LAUNCH files, but each time I update the source code, the ones that I manually deleted are restored to Child_Dir_1.
Since you are using TortoiseSVN:
Go into Child_Dir_1, select GrandChild_Dir_1 and GrandChild_Dir_2 and right click, TortoiseSVN -> Update.
That will update only those two folders.
Ignore is so that you can "ignore" ( from commit, status etc.) untracked files, files that are not checked in.
It could be that manojlds' answer is the solution for you, but I have doubts. The problem here is that those files are really part of the project. They are kind of unavoidable, and must be in sync with the rest of working copy.
Option 1 (best): Remove all configuration files form repository, or better yet have in repository only configuration template files (with, say, $ as first character in file names). Each user could copy those template files to true configuration files and change them accordingly. Configuration files should not ever be committed. Only template files should, but updating template files will not mess with current configuration files of any user.
Option 2 (second best): Ignore those configuration files. Use your own files for your own configuration, with names that don't clash with existing. You may even add your files to SVN, but you may just as well not add them. Does not matter, as long as you don't need your configuration on another machine.
Option 3: Use ignore-on-commit group. Use those configuration files that already exist. Change them to your likings, but don't ever commit them. To ensure that you don't commit them by accident flag them as non-committable (go to commit window, select all non-committable files, right click > Move to changelist > ignore-on-commit). The problem with this is your files are not protected from other users' updates, but may actually be a good thing.
Option 4: Chop the folder out (a horrible hack). Remove Child_Dir_1 from working copy (Right click on it > Update to revision > set Working depth to Exclude). Save the folder elsewhere first, because it will disappear. After that create it again, inside it checkout all subfolders (GrandChild_Dir_1 and GrandChild_Dir_2), and copy your configuration files. Now you have complete control over folder's contents, but update and commit become more complicated.
Edit: There is option 5 in theory, but I doubt it can be implemented successfully. You can try: Use NTFS hard links. Copy the whole tree with all files as hard links to existing files, except .svn folders and their contents. Original directory is used for SVN operations update, commit, add and delete, and new directory is used for editing files. From new directory delete all the files you don't need, and insert all the files you do need that are not the part of SVN. The problem here is minor extra work when deleting files from and adding them to SVN.