I'm am running macOS Sierra, and am in the process of moving all dotfiles into one directory. I have successfully exported many environment variables for various installations (vagrant, composer, oh-my-zsh etc) that allow me to install to a sub-directory of my choice.
Unfortunately, programs like npm, subversion, homestead, git, and others do not offer such configurations.
I use a dotfiles repository, where I keep my configuration files under git. The idea is not new. What I did is move them to another directory and them create a symlink to them in the home directory. It does not clean the home directory as you wanted, since it's the standard place for configuration files, as stated by Norman Gray, but at least you can version them and share them across machines.
Example:
cd ~
mkdir dotfiles
mv .gitconfig dotfiles/.gitconfig
ln -s ~/dotfiles/.gitconfig ~/.gitconfig
Check out stow. That's what I use.
I have a ~/dotfiles/ directory which has folders in it like vim/ X/, etc.
Now for example vim/ will have a .vimrc file in it, and from ~/dotfiles I can run stow vim/ and it will automatically manage the symlinks to the home directory.
I can also run
cd ~/dotfiles
for folder in ./
do [[ -d $folder ]] && stow -R $folder
done
To update all my dotfiles (the -R deletes old symlinks that don't exist anymore)
There is a good introduction here: http://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to-manage-your-dotfiles.html
Related
I have a directory structure like this:
.git/
.gitignore
main/
...
tools/
...
...
Inside main and tools, and any other directory, at any level, there can be a 'bin' directory, which I want to ignore (and I want to ignore everything under it too). I've tried each of these patterns in .gitignore but none of them work:
/**/bin/**/*
/./**/bin/**/*
./**/bin/**/*
**/bin/**/*
*/bin/**/*
bin/**/*
/**/bin/* #and the others with just * at the end too
Can anyone help me out? The first pattern (the one I think should be working) works just fine if I do this:
/main/**/bin/**/*
But I don't want to have an entry for every top-level directory and I don't want to have to modify .gitignore every time I add a new one.
This is on Windows using the latest msysgit.
EDIT: one more thing, there are files and directories that have the substring 'bin' in their names, I don't want those to be ignored :)
Before version 1.8.2, ** didn't have any special meaning in the .gitignore. As of 1.8.2 git supports ** to mean zero or more sub-directories (see release notes).
The way to ignore all directories called bin anywhere below the current level in a directory tree is with a .gitignore file with the pattern:
bin/
In the man page, there an example of ignoring a directory called foo using an analogous pattern.
Edit:
If you already have any bin folders in your git index which you no longer wish to track then you need to remove them explicitly. Git won't stop tracking paths that are already being tracked just because they now match a new .gitignore pattern. Execute a folder remove (rm) from index only (--cached) recursivelly (-r). Command line example for root bin folder:
git rm -r --cached bin
The .gitignore of your dream seems to be:
bin/
on the top level.
I think it is worth to mention for git beginners:
If you already have a file checked in, and you want to ignore it, Git
will not ignore the file if you add a rule later. In those cases, you
must untrack the file first, by running the following command in your
terminal:
git rm --cached
So if you want add to ignore some directories in your local repository (which already exist) after editing .gitignore you want to run this on your root dir
git rm --cached -r .
git add .
It will basically 'refresh' your local repo and unstage ignored files.
See:
http://git-scm.com/docs/git-rm,
https://help.github.com/articles/ignoring-files/
The ** never properly worked before, but since git 1.8.2 (March, 8th 2013), it seems to be explicitly mentioned and supported:
The patterns in .gitignore and .gitattributes files can have **/, as a pattern that matches 0 or more levels of subdirectory.
E.g. "foo/**/bar" matches "bar" in "foo" itself or in a subdirectory of "foo".
In your case, that means this line might now be supported:
/main/**/bin/
[Bb]in/
matches both upper and lower case
I didn't see it mentioned here, but this appears to be case sensitive. Once I changed to /Bin the files were ignored as expected.
Step 1: Add following content to the file .gitignore.
# User-specific files
*.suo
*.user
*.userosscache
*.sln.docstates
# Build results
[Dd]ebug/
[Dd]ebugPublic/
[Rr]elease/
[Rr]eleases/
x64/
x86/
bld/
[Bb]in/
[Oo]bj/
# Visual Studio 2015 cache/options directory
.vs/
Step 2: Make sure take effect
If the issue still exists, that's because settings in .gitignore can only ignore files that were originally not tracked. If some files have already been included in the version control system, then modifying .gitignore is invalid.
To solve this issue completely, you need to open Git Bash or Package Manager Console (see screenshot below) to run following commands in the repository root folder.
git rm -r --cached .
git add .
git commit -m "Update .gitignore"
Then the issue will be completely solved.
[Bb]in will solve the problem, but...
Here a more extensive list of things you should ignore (sample list by GitExtension):
#ignore thumbnails created by windows
Thumbs.db
#Ignore files build by Visual Studio
*.user
*.aps
*.pch
*.vspscc
*_i.c
*_p.c
*.ncb
*.suo
*.bak
*.cache
*.ilk
*.log
[Bb]in
[Dd]ebug*/
*.sbr
obj/
[Rr]elease*/
_ReSharper*/
If you're looking for a great global .gitignore file for any Visual Studio ( .NET ) solution - I recommend you to use this one: https://github.com/github/gitignore/blob/master/VisualStudio.gitignore
AFAIK it has the most comprehensive .gitignore for .NET projects.
Literally none of the answers actually worked for me; the only one that worked for me was (on Linux):
**/bin
(yes without the / in the end)
git version 2.18.0
for 2.13.3 and onwards,writing just bin in your .gitignore file should ignore the bin and all its subdirectories and files
bin
As a notice;
If you think about .gitignore does not work in a way (so added foo/* folder in it but git status still showing that folder content(s) as modified or something like this), then you can use this command;
git checkout -- foo/*
Adding **/bin/ to the .gitignore file did the trick for me (Note: bin folder wasn't added to index).
In addition to #CB Bailey's answer:
I tried to remove multiple folders (in subfolders) named et-cache (caching folder from Wordpress divi theme) from the index and from being tracked.
I added
et-cache/
to the .gitignore file. But
git rm -r --cached et-cache
resulted in an error:
fatal: pathspec 'et-cache' did not match any files
So the solution was to use powershell:
Get-ChildItem et-cache -Recurse |% {git rm -r --cached $_.FullName}
This searches for all subfolders named et-cache. Each of the folders path (fullname) is then used to remove it from tracking in git.
If the pattern inside .gitignore ends with a slash /, it will only find a match with a directory.
In other words, bin/ will match a directory bin and paths underneath it, but will not match a regular file or a symbolic link bin.
If the pattern does not contain a slash, like in bin Git treats it as a shell glob pattern (greedy). So best would be to use simple /bin.
bin would not be the best solution for this particular problem.
In my case encoding of gitignore file was problematic, check if it is UTF-8
I just created my first Github Repo through the Github Bash on Windows 10.
I ran:
$ mkdir Projects
$ mkdir Projects/DataScientistsToolbox
$ mkdir Projects/DataScientistsToolbox/sample
$ cd Projects/DataScientistsToolbox/sample
$ git init
Initialised empty Git repository in /home/osboxes/Projects/DataScientistsToolbox/sample/.git/
$ ls -la
I am really struggling with understanding this code. So I created three directories: projects, datascientiststoolbox, and sample.
What does the cd command on my code do?
Does the git init code run the creation?
What does the ls -la do?
Lastly, I can't seem to find where the repo is saved on my computer, is it located on the desktop or in a special spot?
Thank you, sorry about the large amount of questions.
The cd command lets you change your working directory.
Yes, git init creates (initalizes) a new repository on your machine in your current working directory.
ls displays all files and directories in the current working directory. -la changes the way they are printed.
pwd makes your machine print the working directory. Use it to find out where your repository was created.
Read here about how to create a GitHub Repository. And this is a list of basic unix commands - it may help you to get started with unix systems.
You created only one repository with git init. cd stands for change directory, it's like when you double-click a folder to open it.
So basically your repo is in Projects/DataScientistsToolbox/sample.
ls is used for listing all files in the current directory you're in. -la are flags for different styles of displaying (try running just ls).
Also, all these commands have nothing to do with GitHub. They're a part of git.
I would like to put directory C:\WorkDir under Mercurial version control, but have the repository located somewhere else than C:\WorkDir\.hg perhaps D:\Repositories\WorkDir.hg. Is that possible in Mercurial?
This answer on the Mercurial mailing list by Martin Geisler is quite clear about it:
You cannot move the .hg folder outside of where your working files
reside. That is by definition: the "working copy" is the parent
directory of the .hg folder. So if you want to version files in
C:\inetpub\laravel\app
you must have
C:\inetpub\laravel\app\.hg
If you want to avoid having the drive with the "real" working copy filled up with the repository data, you can use the share extension: https://www.mercurial-scm.org/wiki/ShareExtension .
E.g. if you want to version control C:\WorkingDir, but want the big repository data to reside on D:\Repositories\WorkDir, just do the following:
cd D:\Repositories
hg init WorkDir
cd C:\
hg share D:\Repositories\WorkDir WorkingDir
You will still have a .hg directory on C:, but it will remain really small (around 1MB), while the repo on D: will be the one that grows with time.
Have you tried creating a Junction?
Let's say your repo is c:\test\.hg but you want to put .hg directory in c:\shadow
mkdir c:\shadow
mv c:\test\.hg c:\shadow\.hg
mklink /j c:\test\.hg c:\shadow\.hg
I meant, I don't need all the ".bzr" folders under each directory (I may have hundreds of nested ".bzr" folders); I want to check out those actual files only. Thanks!
Are you really sure you have hundreds of nested ".bzr" folders? There should be only ONE .bzr folder per project, right at the top level directory of the project, no additional .bzr folders in subdirectories. (You might be mixing it up with Subversion?)
It seems that maybe you want to get all the project files without any .bzr folders or Bazaar files. If that's the case, cd to your project and run any of these commands:
bzr export /tmp/project-as-dir # export files into a directory
bzr export /tmp/project.tar # export files into a tar file
bzr export /tmp/project.tar.gz # export files into a tar.gz file
Simply remove the folders, e.g. using find -type d -name .bzr -exec rm -rf {} +
Note that you won't be able to use bzr in that copy anymore (i.e. you can't commit stuff etc.).
I've been using ComponentSoftware's CS-RCS Basic for many years now to manage my various single-developer projects. It's worked very well for me, but now I want to migrate to a modern revision-control system, and after studying my options I decided on Mercurial.
The problem is that I've always used a central repository for CS-RCS, and I'd now like to use individual Mercurial repositories for individual projects, keeping the history from my RCS repository.
After some in-depth Googling I concluded that the only way to do this is to convert my RCS repository to individual CVS repositories, then convert those to Mercurial. These two sites were probably the most helpful:
Converting a directory from RCS to Mercurial
Convert Extension for Mercurial
In keeping with Jeff Atwood's idea of asking and answering my own question, I'm going to answer this for anyone else stuck in this situation, and in case I have to find it again later. As you'll see, though I did find a solution, it's clunky and has at least one significant problem. If anyone else has any better method I'd certainly like to hear about it.
Here's the method I came up with, warts and all. It's a bit 'cargo culty', since I basically know nothing about CVS and not much (yet) about Mercurial:
I have a Windows XP virtual machine that I can take snapshots of, so I did that and then installed CVSNT and the Windows command-line version of Mercurial (I use TortoiseHg on my main machine). I did this in a VM so I could easily get rid of CVSNT, Mercurial, and anything else I had to create while doing this one-time migration. Yeah, I probably didn't have to do this, but the VM was already available and I've already got enough odd bits of apps left over from install/uninstall cycles over the years. :-)
As far as I could tell, CVSNT was the only program available that could easily set up a CVS server on a Windows machine. It seems that this was free at one time but the owner's current site now asks for money. That's not a bad thing, but I really couldn't justify spending money just to do a one-time conversion. I did eventually track down an older version of CVSNT with a Google search and installed that without problems.
Here are the notes I took while learning how to make this conversion work:
The Long Version
Copy the source-code folder you need from the main computer's drive to the VM's drive. Copy the various ",v" files from the C:\RCS folder structure to this same source-code folder on the VM. Just copy the ,v files from the corresponding folder in C:\RCS.
Open a Command Prompt box on the VM and type the following:
path %PATH%;C:\Program Files\cvsnt
mkdir \cvs-repo [or clean the folder out if it already exists]
cvs -d \cvs-repo init
[A DIR of \cvs-repo should show a CVSROOT folder in there.]
Make a copy of your source code folder in \cvs-repo. \cvs-repo should now just have two folders: CVSROOT and your new folder. Copy in the appropriate ",v" files as well.
mkdir \cvs-checkout [or clean that folder out if it already exists]
cd \cvs-checkout
cvs -d \cvs-repo co name_of_your_source_code_folder
A DIR of "\cvs-checkout\name_of_your_source_code_folder" should show all of your source code files, which are now checked out of CVS.
If you haven't already done so, download Mercurial from https://www.mercurial-scm.org/ and install it. Open a copy of Notepad and drag the file "C:\Program Files\Mercurial\hgrc.d\Mercurial.rc" into it. Under "[extensions]", remove the semicolon at the start of the line ";convert =". Save the file to "C:\Documents and Settings\user_name\Mercurial.ini"
Back at the VM command line:
path %PATH%;C:\Program Files\Mercurial
mkdir \my-repo.hg [or clean that folder out if it already exists]
hg convert --datesort \cvs-checkout\source_code_folder_name \my-repo.hg
cd \my-repo.hg
[A DIR of \my-repo.hg should show a new ".hg" folder.]
hg update
[A DIR should now show the ".hg" folder and all the checked-out files.]
Copy the ".hg" folder from \my-repo to the source code folder on your main computer's hard drive. The destination folder will now show up in TortoiseHg with all of the appropriate change history, but all files marked as Changed (icon overlay of an exclamation mark in a red circle). This is because the new Mercurial repository thinks the files were checked in with Unix line endings (0x0A) instead of Windows (0x0D,0x0A). This seems to happen in the "hg convert" process, and I haven't found any way around it.
The Short Version
Once everything's set up in the VM, here's what to do:
Delete everything in \cvs-repo, \cvs-checkout, and \my-repo.hg.
At the command line, cvs -d \cvs-repo init.
Back on your main machine, copy the source-code folder into your Virtual Machine's shared folder (that's how you do it in VirtualBox; other VM software might let you just drag-and-drop the folder into the VM).
Copy the appropriate ",v" files into the source-code folder in the Virtual Machine shared folder.
Back in the VM, move the source-code folder to \cvs-repo.
cd \cvs-checkout
cvs -d \cvs-repo co name_of_your_source_code_folder
hg convert --datesort \cvs-checkout\name_of_your_source_code_folder \my-repo.hg
cd \my-repo.hg
hg update
Copy the .hg folder from \my-repo to the L: drive on the VM (L is the mapped drive letter of my VM shared folder).
Move that folder from the Virtual Machine transfer folder to the final source-code folder on the host computer.
Handy Batch File
Once I got this working, I set up this batch file on the VM to automate the process as much as possible:
#echo off
rem Converts source code under RCS control to a Mercurial repository.
rem This batch takes one argument: the name of the source-code folder (in quotes if necessary).
rem
rem This is for a VirtualBox VM that already has CVSNT and Mercurial installed, and has a Shared Folder mapped to drive L.
#echo On the host, copy the source-code folder into the Virtual Machine Transfer folder. Copy the appropriate ",v" files into the source-code folder in the Virtual Machine Transfer folder.
pause
#echo on
cd \
rmdir /S/Q \cvs-repo
mkdir \cvs-repo
rmdir /S/Q \cvs-checkout
mkdir \cvs-checkout
rmdir /S/Q \my-repo.hg
mkdir \my-repo.hg
cvs -d \cvs-repo init
xcopy L:\%1 \cvs-repo\%1 /E/I
cd \cvs-checkout
cvs -d \cvs-repo co %1
hg convert --datesort %1 \my-repo.hg
cd \my-repo.hg
hg update
xcopy \my-repo.hg\.hg L:\.hg /E/I
Conclusion
So, this all worked but left me with files that had the wrong line endings. Looking at this question, I see I'm not the only one with this problem. I can live with this, but I'd still like to fix it if anyone knows of a solution.
If Mercurial has fast-import/fast-export support, and if your multi-file repositories do not use branches, you can probably try using my rcs-fast-export tool (available # http://git.oblomov.eu/rcs-fast-export ). Although I've only used it to export from RCS to git so far, I am not aware of any git-specific fast-export commands being used so it might work.