My question is.
Why can't we just "git" the entire .config directory? Wouldn't that be a simpler way to manage dotfiles? for e.g. My ".config directory" is about 250 mb which is well below the space limit in Gitlab/hub. Ofcoruse I will keep it private.
What are edge cases? I issue I can think of is that it might generate a lot of Untracked files when you run git. Idk. I am just a noob thinking aloud.
I have checked out several soltions to solving the problem of managing dot files.
Top of them include
Create --bare git repository and create custom git commands
Save preferred dotfiles in another respository like Documents and git it
create symlink to the Dotfiles you need and manage them from #HOME with git
Use Stow or yadm ( yet another dotfiles manager)
[Managing dotfiles] (https://www.atlassian.com/git/tutorials/dotfiles)
Why you Shouldn't:
The problem with dotfiles is their lack of standardization. While usually they store things like my username is billy4, sometimes dotfiles can have authentication information, binaries, cache, temporary files, state data, etc. that you don't want to go to source control.
For example, .npmrc has (at least mine does, I can't say the same for everyone) registration tokens shpotify's .shpotifyrc file has auth tokens, the ~/.config/gh, ~/.config/configstore/firebase-tools.json folder can have logins -- you get the point.
As well, applications sometimes store all of their app data in the config folder, like iTerm2. ~/.config/iterm2 stores all of your settings, cached data, the iTerm window state, shell history, etc..
I can't recall if this is default or not, but I have my environment setup so that my global .yarnrc is in my config folder
Finally, applications can store log/history files there, and if they were checked into source control, while it's not the end of the world, it would make things difficult to maintain and add a lot of complexity. You wouldn't want to check .zsh_history or something similar to source control right? That'd make the repo an extreme pain to push, pull or merge.
Workaround:
This is a solution similar to my dotfile repository (You're probably not interested in what my terminal looks like or what font I use, but it might help you with your solution's file structure and potential setup scripts).
TLDR; you can move the children (that you want in source control) of .config to a different path like ~/.dotfiles, then create a git repo in it, and link each one to ~/.config.
If I were you, I'd put all of the config files that I want in git in a path like ~/.dotfiles, I'd link all of the children (except one) of the ~/.dotfiles source to be in ~. For example: ~/.dotfiles/.zshrc would be linked to ~/.zshrc. The child not to link is ~/.dotfiles/.config. This is because I would run mkdir -p ~/.config (in case it isn't already), then I'd link every child directory of ~/.dotfiles/.config/<child> to ~/.config/<child>. This allows me to put whatever config folder I want in the repo's .config folder to be sent to ~/.config, but I could also have items in ~/.config that are normal folders instead of links.
Here is kind of what I mean:
HOME links to DOTFILES
# Link the whole file # Link
~/.zshrc -> ~/.dotfiles/.zshrc
# Link the whole folder
~/.some-folder/ -> ~/.dotfiles/.some-folder/ # Linked folder
|- dev/ ~/.dotfiles/.some-folder/dev/
| |- hello.txt ~/.dotfiles/.some-folder/dev/hello.txt
| |- world.txt ~/.dotfiles/.some-folder/dev/world.txt
|- fun/ ~/.dotfiles/.some-folder/fun/
| |- foo.txt ~/.dotfiles/.some-folder/fun/foo.txt
# Link the children
~/.config/ ~/.dotfiles/.config/# Real Folder
|- nvim/ -> ~/.dotfiles/.config/nvim/ # Link
|- git/ -> ~/.dotfiles/.config/git/ # Link
There are upsides and downsides to both.
Linking the whole folder gives a lot less control and you will likely have things you don't want to be in your repo. However, it also is a lot simpler, and easier to manage. If I modify any child or grandchild (etc.) of ~/.some-folder from either side (source file vs. link), all of the changes will be reflected. I can update, delete, create, etc.
If you are more specific with your linking (linking children, childrens' children, etc.), you can have more control with what goes to git, and what stays local. By making ~/.config an actual folder, and linking each child to it, I can decide I don't want ~/.config/.auth to go to the repo and just put it in the ~/.config/.auth directory. this all works because ~/.config is a normal folder, it isn't a symlink, and if you put something in it, there won't be any changes in ~/.dotfiles/.config.
Getting too specific with links can make things pretty challenging to manage; let's say, for example, instead of linking the whole .config/git folder, I link .config/git/config and .config/git/aliases. Later, if I decide to add .config/git/some-other-file, I need to create it in the dotfiles source, then link it. If I rename .config/git/config to .config/git/gitconfig, I need to delete the .config/git/config link (it will be pointing to a file that doesn't exist), and add a link for .config/git/gitconfig.
I thought quite a bit about this when I set up my repo, and once you get the right balance of ease and specificity, it is super nice.
I'd recommend making a bash file that will read the contents of the ~/.dotfiles directory and set up the links, so that if you want to update your dotfiles because of a name change, deletion, etc., you can just run something like: ~/.dotfiles/link.sh and it will update the links for you.
Related
Ahoy,
We have a large monolithic repository with all our code in it. We have recently started to use Go, however, are having issues since most tooling for Go assumes that the root directory is src/ but ours is not. Our directory structure is based on product areas and not based on language or tooling. We don't want to have a separate directory just for Go.
How can we setup the Go path to not assume that the directory starts at src?
Thanks!
The safest course of action is to have two worktrees:
one for your current directory structure, based on product areas
one for Go development respecting GOPATH
Each time you will make a commit in the second worktree, you can git pull/update your first worktree to keep it up-to-date.
UPDATE: I missed a layer in the directory structure (the laravel parent folder, specifically). I'm quite embarassed...
I have a Mercurial repository tracking a Laravel project I've built under
IIS 6, with the following directory structure:
inetpub
|--laravel
|--app
|--bootstrap
|--vendor
|--wwwroot
|--Project
|--OtherScript (set to ignore in .hgignore)
I now want to begin work on a second project, and have modified the directory structure accordingly:
inetpub
|--laravel
|--app
|--app2
|--bootstrap
|--bootstrap2
|--vendor
|--wwwroot
|--Project
|--Project2
|--OtherScript (set to ignore in .hgignore)
I've added the "2" folders to the .hgignore for the original repository, but I'm having trouble working out how to set up a separate repository that ignores the original project folders, and will just track the 2s. I thought I could just create a new repository covering inetpub that uses a different .hgignore file, but when I create the repository it automatically references the .hgignore file established for the first repository. I'm presumably missing something, but I'm not sure what. How can I make this work? The project is just starting, so restructuring is entirely viable if that's necessary.
Two repositories residing in the same directory does not work.
There are several options which might suit your needs, though:
a) Use a parent directory in which you organize your projects in sub-directories. This is usually the recommended the standard approach with mercurial; each of the sub-direcoties becomes an independent repository. The parent directory would not contain much, but can be made a separate repository as well, if desired.
b) Use branches for different projects. Switching between projects then requires switching branches in your project.
c) You can extend option (a) and consider using sub-repositories or guest repositories. They come with some rough edges, thus their use will need careful consideration. You can also start with option (a) and convert it to option (c) at any later time. See Subrepository and also the links in the 'Alternatives' section.
As an aid to others fumbling their way to a better understanding of doing this with Sourcetree, here's a quick overview of what I've done based on planetmaker's advice.
Used the "Clone/New" option to created individual new repositories from the app, bootstrap and Project folders (I've determined that there's no point in tracking vendor).
Committed the contents of each of those repositories.
Created a new Project_Repository folder outside of inetpub
Created a new Repository from the Project_Repository folder
With the Project_Repository tab open, selected "Add Subdirectory" from the Repository menu, and selected the app directory.
Repeat 4. for bootstrap and Project
After doing that, I have a current copy of the content of all 3 directories in the Project_Repository folder, along with the appropriate .hg files. I'm optimistic that this will work well for Project2 as well.
I want to pull from a git repo in Windows which has two directories, named Foo and foo. Both the folders have different contents.
As Windows is case insensitive and doesn't allow folders with same name but different case, how do I push to the git repo?
Short answer: You can’t do this easily.
By default, this is a restriction of the Windows subsystem. Unless you use lower level system calls, Windows cannot differ between different casing; so even if Git is able to keep track of the differences, it can’t communicate these difference to the file system.
As pointed out in the comments by phuclv, it is possible to reconfigure the Windows kernel to be case sensitive. In Windows 10, this even works for individual folders, so you could use this to add compatibility where you need it. However, the case sensitivity per folder is not inherited, so you will need to manually change this for the folders that Git creates which might be a bit bothersome and makes this mostly a workaround.
Instead, you could make the whole file system case-sensitive but that might have additional implications, so just be careful if you want to do that.
Also note that even if there is support for case-sensitive content on the lower level, most Windows applications, including built-in Windows tools, will probably not be able to work with this. So this will only allow you to work with these files from certain tools. My guess would for example that most GUI based Git tools simply won’t work here.
If you don’t want to make these modifications, then what you maybe also could do is create partial commits where you just add files to the correct folder (you need to rename it in-between to get the different casing). But that will be very impractical.
In my opinion, the best solution is to simply avoid using multiple files on folders with conflicting names. Even on case-sensitive systems, this will only make things more confusing. By avoiding this completely, you also make it easier for all other developers to interact with the project.
As a follow up to poke's answer, you need to split those directories apart into different names, or merge them correctly into one with the same name, depending on your needs of course. They can't have the same name other the case and have it work in Windows (in a clear and obvious manner anyway).
I accidentally ended up in this same boat. I'm not sure how, as I was using Windows the whole time, but at some point I changed the case on a directory in the repo and some files ended up remaining in a directory with the "old" name and some in one with the "new" name. On my Windows machine they were all under the new name, but I found this problem when I pulled the repo into Linux, and confirmed the split when I looked in my remote repo.
To fix this, I first cloned the to a separate location on my Windows machine. Doing so, all the files were there in one directory again, as apparently the two directories just get merged. I then renamed that problem directory to "temp", (using the TortoiseGit "rename" operation). Then, I cloned the repo to yet another location. At that point, the two directories were in fact split apart in Windows. I had a "temp", plus the directory with the "old" name.
As I really did want them in one directory (on all platforms!), I moved the files out of the old named directory into "temp", then deleted the "old" directory. Next, I renamed temp (using the TortoiseGit "rename" operation again) to the name I wanted everything within, committed and pushed again. Finally, I pulled the changes into my original repo (my Linux one) and checked what was on the remote. Everything was finally in agreement, so I deleted those temp clones and called it a day.
I have some custom filter scripts that I use in my Git repo.
Currently, they are checked in along with my sources which sometimes leads to problems: when I check out a revision older than that where I added the filter scripts to my repo, I get warnings that the filters could not be executed because they cannot be found.
In order to overcome this, I want to put the scripts inside the .git folder so that they are present where I need them but don't make problems when checking out older revisions.
I want to keep them in the repo because the script contents are repo specific, so simply putting them to another location on my machine is not what I'm looking for.
Question is: are there some 'safe' locations inside the .git folder where I could store my scripts?
Safe in the sense that the scripts don't get cleaned up automagically or make problems with further Git versions.
The contents of the .git folder itself aren't very dynamic (what changes rather unpredictably are the refs and the logs, so just stay away from them).
If you take a look at the .git folder of any of your repos, you'll have a pretty good idea what is usually there.
AFAIK, folders in the top level of the .git folder do not usually start with a period, so you could just make a folder .git/.scripts to contain your private script files.
If you want, you can also make that inside the info folder -- that's really up to you and which you find more orderly.
Why not just include the names of the scripts in a .gitignore file? That way, your scripts are not tracked and you can place them anywhere you want in the repo.
I am an inexperienced Mercurial user. I am using VS2010 with Mercurial. I had everything working nicely against a single repository, which contained a solution file and two projects nested within the 'parent' folder. Whenever I changed a file then the commit process would detect the change etc, etc.
Then I added a third project. I added this project in a new folder, where the new folder was a peer of the top-level folder containing the original solution file (with original 2 projects nested within). Although the third project has been added to the solution file, it is not being recognised by Mercurial as 'belonging' to the solution in terms of source control. Indeed, it is not showing as being under source control at all.
How do I add the third project to the same repository, even though it sits 'outside' the original folder which maps to the original Mercurial repository?
Thanks very much.
No, you cannot add anything that is not under the repository root. hg add will abort with X not under root message. Move your files into the repository, or move the repository so that all of your files are under the root (note that this will generate a lot of file moves, and you really shouldn't do that).
I found the best way to manage multiple folders in one repo by just creating a symlink (mklink in windows). I usually work in Visual Studio, so I typically have a code library and a website directory, but they are not in the same parent folder.
You can create a symlink on windows like so:
mklink /J "Target Path" "Source Path"
So I would have a structure like so:
project root
- Code Library
- Solution File
- Web Folder (symlink from locally-hosted website folder)
You should use a different repository for each project. This is because when you do a commit in hg, the commit is for the entire hierarchy, not just the directory (and below) that you are in. For more details have a look at the One last big conceptual difference section of http://hginit.com/00.html