I have two git local repositories. Both share an identical file, under a different path and under a different name. Currently, when I make changes I have to copy the file from one directory to another.
Is there an alternative way to keep them in sync without manually overwriting the file? I don't want to create a separate repository for this file. I thought one of the following things would work, but apparently, they don't:
git submodule
git subtree
symlink soft
symlink hard
What else is there?
The only other alternative would be a post-commit hook on repoA, which would, on each commit:
check if the file is part of said commit
copy it in repoB with the right path.
Related
I completed MyProject1 and have uploaded it in git in fine way with commits after adding each new features. And now I'm starting MyProject2 and was trying to add the URL for the remote repository. But then I found out that I had mistakenly added the URL in Documents instead of MyProject1 folder because of which MyProject2 folder is also being tracked in MyProject1. And I'm not being able to add URL to MyProject2 but instead facing merge issues.
Is there any way to detach the track from my Document folder without deleting any of my files from Documents.
Structure is this way(I'm using Linux):
Documents
(And inside Documents there is:)
MyProject1
MyProject2
And other folders which are also being tracked.
We can manually do it with below steps
create a file .gitignore in base directory.
If MyProject1 and MyProject2 are already part of git tracking, Please run commands
git rm -r --cached MyProject1/
git rm -r --cached MyProject2/
Open the file in text editor and add below lines in file
MyProject1/
MyProject2/
Best way:
Create a .gitignore file following #Vinayagam R
Ignore file locally
Those methods won't affect other contributors working on the same remote repository:
Use update-index:
If you want to stop tracking a file at certian point.
git update-index --assume-unchanged yourDirectoryName
--assume-unchanged is the flag which means the files should not change locally. In other words, it is used when ignore files that you do not need to change locally (or should not change).
To revert it use update-index --no-assume-unchanged yourDirectoryName
Using .exclude
In your working directory edit .git/info/exclude
I just arrived in a company which does not have access to GitHub or similar.
I was wondering about ways to backup my code using the private OneDrive which is given to each employee.
I just thought of moving my folder from the "document" directory to the "OneDrive" directory. But I was wondering whether changing the path will break my code.
Will it preserve the .git directory? Should I rerun git init (loosing the past history)?
You can move a Git repository from one path to another without affecting it. A Git repo is a self-contained entity (with the exception of global Git config) and the .git folder containing all Git files is just like any other folder (so it can be moved, deleted, etc.).
If you want to use OneDrive as a backup, there are better options than simply copying your project over. Tools like restic or similar would allow you to keep your backup up to date in an efficient way.
Note that you can also set OneDrive as a Git remote. Since it sounds like you are missing options such as GitHub or Bitbucket for your company, this is probably your best option.
To add a remote called onedrive on OneDrive, you can run:
git init --bare ~/OneDrive/<project>.git
git remote add onedrive ~/OneDrive/<project>.git
And then you can use onedrive as you would any other remote. For instance:
git push --set-upstream onedrive master
I have a symlinked directory within my repository, which links to files elsewhere on the filesystem. For whatever reason, the symlink breaks every now and then, and it turns into a regular empty folder. So I deleted the empty folder, and recreated the symlink with ln -s ../../ ext, which appears to have worked as I can browse that folder and see the contents. But when I run git status, it appears all the files that should be visible within the ext folder are missing. How can I make git see that they are there again, within the symlinked directory?
This is on Ubuntu 18 by the way.
Your setup is odd, because Git does not follow symlinks, it just stores them.
That is, if you have a symbolic link ext -> ../.. and you run git add ext, Git creates, in the index, an entry with mode 120000 (symlink) to store the blob contents ../... Committing will create a commit that, when extracted, will create the symbolic link ext pointing to ../... Git will not store any files within ext when it is storing this symbolic link.
If, on the other hand, you have an existing commit that contains files named ext/foo and ext/bar, and you clone this repository at this commit, or extract this commit into a new and otherwise empty work-tree, Git will see that in order to write to files named ext/foo and ext/bar, your OS requires that ext exists as a directory. It will therefore create the empty directory ext, in which it will then create files foo and bar as your OS requires, so as to create files that to Git are merely named ext/foo and ext/bar. These two names, ext/foo and ext/bar, will now be in the index, so that the next commit you make will also contain these two files.
It sounds like you:
cloned a repository (perhaps with git clone --no-checkout?);
manually created a symbolic link in the work-tree named ext, pointing to some existing directory (perhaps one with some files inside it);
convinced git checkout to create ext/foo and ext/bar without first removing the symbolic link ext and replacing it with a directory ext.
This is not a supported mode of operation1 and you should not be surprised when it goes wrong.
1It leads to security issues: Git is meant not to write any files "outside" the work-tree area, and writing to files "under" a symbolic link to a directory outside the work-tree would allow this to occur. Rather than carefully limit symbolic link usage, Git just generally doesn't store files "beyond" any link in the first place—though it's probably possible, through careful manipulation of the index and, at the OS level, the file system in which your work-tree resides, to trick Git manually.
just dont put a repo in a repo, its not worth it
My understanding is that when I perform git annex add somefile, it creates a symlink for that file and places it in the .git/annex/objects folder. Then, when I initialize git-annex in some different location and sync it with the previous one, it downloads a broken symlink, unless I do git annex sync --content, which makes a full copy of the file.
I need to have large files in one location, lets say on a USB Drive, and multiple git repositories that use the large files. So I want to have just the symlinks to the large files in those git repos. How to perform the sync so git-annex downloads a valid symlink that points to a file in a single location ?
There are two ways to do that.
First is using hard-links, second is using symlinks. I recommend hard-links if all your files are going to be in the same filesystem/volume/partition, otherwise the good ol' cp --link is just going to copy the entire thing.
Using hard-links:
git clone --shared main_repo/ new_repo/
Explained by git-annex author himself
Using symlinks:
On main_repo:
git worktree add -b branch_name path_to_new_repo/
Since git-worktree uses a pointer file (which git-annex replaces with a symlink), this will work across different file systems. Changes to "different repos" will be stored in different branches. If you want them all to remain in sync, keep them in sync with standard git commands like git merge. Or you could only make changes to the master branch and git rebase master from the different branches frequently.
I am attempting to create a git repository to store all of my dotfiles and config files. My idea was to simply create hard links to all of the files I cared about and store those links in their own directory that I could turn into a repository.
I've hit a bit of a snag though with my ~/.gitconfig file. It seems that whenever I run the 'git config' command the link that I created no longer points to the right location e.g. the file in the repository no longer updates properly.
Here is an example using the shell and interactive ruby to determine the files linked state.
# Create the link
$ ln .gitconfig .conf_files/gitconfig # Create the link
# The files are in fact linked
[1] pry(main)> File.identical?('.gitconfig', '.conf_files/gitconfig')
=> true
# Update the gitconfig file by running a 'git config' command
$ git config --global alias.last 'log -1 HEAD'
# The files are no longer linked.
[2] pry(main)> File.identical?('.gitconfig', '.conf_files/gitconfig')
=> false
I assume this has something to do with the way that git is writing the .gitconfig file. Does anyone know why this would happen, or have any creative ideas for a workaround?
Try Eli Barzilay's solution in his comment at http://www.xxeo.com/archives/2010/02/16/dotfiles-in-git-finally-did-it.html:
So I’ve finally found a solution that takes the best of both: put the repo
in a subdirectory, and instead of symlinks, add a configuration option for
“core.worktree” to be your home directory. Now when you’re in your home
directory you’re not in a git repo (so the first problem is gone), and you
don’t need to deal with fragile symlinks as in the second case. You still
have the minor hassle of excluding paths that you don’t want versioned (eg,
the “*” in “.git/info/exclude” trick), but that’s not new.
This is completely normal, and is in fact the recommended way to overwrite config files. Git creates a temporary file, writes out the config, and then moves the new file over the old one. This way, you don't get an incomplete config file (data loss) if Git gets interrupted.
You can always write a script to copy or link your config files into your central repository.
Checkout this answer, perhaps it may be of help:
https://stackoverflow.com/a/3731139/1431696
In the meantime, have you considered doing the links in reverse? Create your repository full of config files, etc, and then in the place that you actually use your files, create a hard link to the 'real' file, which sits in the repository.
Thanks to Dietrich Epp's answer and advice I have decided to approach this problem from a different angle by creating the repository at the root of my filesystem, and using .gitignore to track only the files I am interested in.
My .gitignore file now looks like this:
/*
!/etc/
/etc/*
# etc files
!/etc/rc.conf
!/etc/asound.conf
!/etc/mercurial/
!/home/
!/home/matt/
/home/matt/*
# Home files
!/home/matt/.xinitrc
!/home/matt/.gitconfig
!/home/matt/.bashrc
# Vim files
!/home/matt/.vimrc
!/home/matt/.vim/
.netrwhist
In addition to not having to copy the files separately and keep them in two separate locations this has the benefit that should I need I can easily revert the changes without having to manually copy the files as well.
Thanks for the help guys!