I'm using the following method to populate a tags file in my repositories' .git directories:
https://tbaggery.com/2011/08/08/effortless-ctags-with-git.html
So, for any given git repo, I will have a .git/tags file in it. How do I configure my tags option to recursively look up from my current directories in a repo to find these tags files?
I currently have this:
set tags^=./.git/tags,*/.git/tags;~
As I understand it, that should look for ./.git/tags and if it exists use that. Else, it will go up one directory and look for .git/tags there. Failing that, it will go up two directories, and so on, stopping once it hits my home directory (~).
That seemed to work until I had another git repository in the mix. What I find is that if I have two repos at $HOME like so:
~/my_repo_2910
~/my_repo
If I am in ~/my_repo, things work fine. That is, tag resolutions happen via ~/my_repo/.git/tags. However, if I'm in a subdirectory of ~/my_repo, say ~/my_repo/dir, then running my tag commands will resolve to files in ~/my_repo_2910. I'm not sure how that is possible, but it is very dangerous for me to unexpectedly jump repos via my :tag lookups.
Clearly I'm not setting the tags option correctly. Can someone point out what I'm doing wrong.
Update
Knoble's answer works for me if I update my CentOS 7 vim to version 8 following the instructions here:
https://vi.stackexchange.com/a/21697/25433
Then his tags specification works for me fine.
With the recent fugitive updates, I had to fix my tags setup (fugitive no longer sets tags).
I have this line now:
set tags^=.git/tags;~
Note the lack of * wildcard
As sussed out in comments, there appears to be a difference between my version (8+ on macOS) and the OP version (7.4 RHEL)
Related
I've encountered a problem long time ago which I couldn't solve, but I'm curious whether it's possible to fulfill ALL of the below listed criteria at once or not.
The solution what I was looking for can:
somehow refer to an existing file or folder from another folder of the same git repo
basically reach the content of the file or folder from another subfolder, see the content(s) as if they were on the another path as well
e.g.: if ./path/to/folder is referred from ./another_path/different_folder, then every file in ./path/to/folder/* is visible on path ./another_path/different_folder/*
e.g.: if ./path/to/file is referred by ./another_path/different_file, then by reading/writing content of the different_file, the original file is read/modified
store the referred file only once in git repo
don't want to make a copy of the file to another path and maintain changes in both files simultaneously
be able to use multiple references for a single file
be able to use relative paths
make it work on both Windows and Linux
As if I can remember, some of the problems were while experimenting with this:
the paths were broken after the repository was pulled to a different path (I assume they were not relative, but absolute)
the Windows style links are special files, were not working on Linux
the symlinks can't handle relative paths correctly on the Windows system
the hardlinks resulted duplicating files in Windows
(I can't remember exactly which if these might be incorrect, but I'll experiment with the problem again and try to update this question.)
Is there any workaround for this problem?
Thank you for any help!
Please note (in case you would like to mark this question as a duplicate), that there are other similar questions here, but none of those questions define this set of the criteria, therefore it can't be a duplicate.
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.
I currently have a project which I want to add to SVN but I don't want to version certain file types. (e.g. .png) or a folder (images).
I know there's the svn:ignore, but this will not work if there's no .svn file in the directory which I'm trying to perform the ignore operation. I get the following errors :
property 'svn:ignore' set on '.'
svn: 'common' is not under version control
I'm looking for someone to inform me as to how to do this or direct me in the right place.
Any time I'm trying this, its like I have to add the file/directory to svn using 'svn add' and then run the ignore. I've a lot of directories and I'm looking to do this recursively also.
Is there a simple way to do this?
Set global-ignores in Subversion configuration file (normally found on Linux at ~/.subversion/config). See the manual for more info.
I've happily installed the vim Align plugin on my home computer, but on the Red Hat servers at work, the installation doesn't work. The servers at work have a very old copy (2006) of vimball, which from Googling I know doesn't support more recent vimballs, including Align. I can't get the systems group (IT department) to upgrade vimball, so I thought perhaps I could simply copy the various files into ~/.vim/plugin by hand. I copied the 3 files from my home system AlignMapsPlugin.vim AlignPlugin.vim cecutil.vim, but when I attempt to use Align from within vim I get the following error message
E117: Unknown function: Align#Align
I know that it's seeing the plugin, because when I remove the plugin the error message is different (it says "Not an editor command Align").
Is there a workaround for this? I love "Align" and would sure like to use it at work as well as at home.
{rtp}/plugin is not the only location where plugin files can be placed. The name of the function suggests that there is at least one file in {rtp}/autoload named Align.vim (autoloaded functions must have names looking like path#to#file#with#function#without#leading#autoload#function_name(), this example is for function located in {rtp}/autoload/path/to/file/with/function/without/leading/autoload.vim). But I strongly suggest that if #LucHermitte’s solution is not acceptable, you should use something that supports holding plugins in separate directories. If you used VAM all you needed to do (assuming that you have already installed align using VAM) is to look for files in ~/.vim/vim-addons/Align%294 and copy all of them.
Update: Forgot to say, you may try to install newer vimball plugin into your ~/.vim. In order to do this you need copy a file placed in /usr/share/vim/vim73/autoload/vimball.vim to ~/.vim/autoload (there is another related file, /usr/share/vim/vim73/plugin/vimballPlugin.vim, but it is not likely to be changed). No need to make IT department to upgrade anything, unless the newest version uses the newest vim features.
Install a recent (/the latest) vim in your $HOME. I've been doing this for ages now. It's the easiest way to get the job done (i.e. to have a proper environment).
I have a settings file that is under version control using subversion. Everybody has their own copy of this file, and I need this not to be ever committed. However, like I said, there is already a copy under version control. My question is: how do I remove this file from version control without deleting everyone's file, then add it to the ignore list so it won't be committed? I'm using linux command line svn.
Make a clean checkout, svn delete the file and add the ignore. Then commit this. Everyone else will have to take care (once) that their local copy isn't deleted on the next svn update, but after that, the local file would stay undisturbed and ignored by SVN.
If you remove the file from version control, how does a developer new to the project (or the one who accidentally deleted his local copy) get it after initial checkout? What if there are additions to the settings file?
I would suggest the following: Keep a default settings file (with no passwords, hostnames, connection strings, etc.) in SVN, name it something like settings.dist, and let the code work with a copy of this, named settings. Every developer has to make this copy once, and can then work with her personalized settings. If there are additions, add them to settings.dist – everyone else will get them with a update and can merge then into her personalized copy.
After you delete the file, your users will have to recover the file from the repository using svn export.
$ svn export -r x path ./
Where x is a revision where the file existed before it was deleted, path is the full path to the file, and ./ is where the file will be placed.
See svn help export for more information.
simply define a file containing settings that will override the default ones. This file is not checked into Subversion and each developer is responsible for maintaining this file according to their environments.
In an Ant-based world, you would have the files:
settings.properties
settings-local.properties (ignored for Subversion)
and in your build.xml file
<property file="settings-local.properties"/>
<property file="settings.properties"/>
For those who couldn't connect the dots:
modify the build.xml file like proposed
set the setting-local.properties as ignored
in an init target of your build, copy the settings.properties to settings-local.properties
wait a couple of days until everyone had the chance to run this target
delete the setting.properties from Subversion
Voila, every developer has its own setting-local.properties and everything was done automatically (and no developer lost his or her settings, which happens if you brutally delete the file from Suvbersion and there is no "Everyone else will have to take care...")
I have a similar issue. In my case it's an auto-generated user settings file (visual studio) that was accidentally checked in very early in the project. While just deleting it might work, it seems more correct to have it removed from the history, as it was never supposed to be in there in the first place.
I came across this, which might be a new feature since this question was originally posted 7.5 years ago:
https://stackoverflow.com/a/6025750/779130
Seems like an idea would be to:
1) create a dump of the project.
2) filter the dump using `svndumpfilter` to exclude the unwanted file(s).
3) load the dump as a new project.
This might be the only way to completely get rid of the file. In most cases the "delete and ignore" approach might be good enough.
[[ I'm new to subversion, so maybe this doesn't make sense. marking this as wiki -- if you know the right answer, please APPEND in the later section ]]
Couldn't you have a custom set of checkout steps so each user gets a different settings folder?
$ svn checkout http://example.com/project project
..
$ dir project
original_settings\ folder1\ folder2\
$ svn checkout http://example.com/project/aaron_settings project\settings
..
$ dir project
original_settings\ folder1\ folder2\ settings\
Or for new users
$ svn import project\settings http://example.com/project/aaron_settings
What I'm getting at is you want each user to have a custom view of the repository. In other version control systems, you could set up a custom listing of which projects you were using and which you weren't and which you put in odd places.
Does this work in subversion? The above code looks really risky, but maybe i'm doing it wrong.
WIKI:
(nothing yet)