What files generated by Bit are clear to be included in .gitignore? What are the best practices regarding using Bit and Git combined?
Bitsrc create 3 main assets:
bit.json - should be committed to source control.
.bitmap - should be committed to source control.
.bit if git isn't used or .git/bit folder if git is used. This shouldn't be committed to git and should be synced with bit import command right after a clone.
Related
I am doing unit tests on a python program who, for QA purposes, gets the repository name and the current commit hash from the .git in the directory
For my unit tests on that program I would like to have a dummy .git directory in the tests directory. That .git repository would have a single initialization commit and a remote that would not be used
When attempting to add a .git to my tool's repository, git seems to ignore it and indicates that there are no differences in the status and commit
How can I add the .git directory to my project repository ? Something like tests/.git
You can't do that. It's inherently forbidden by Git.
You can store a tar or ZIP archive that contains the repository, and then have your test routine extract it to a temporary location. If you go that route, I recommend to use an uncompressed archive format, because it allows Git's own compression algorithms to work more efficient.
I think we would need more details about what you want to achieve to provide like the best answer... but I think you should look at git bundle. You can track a bundle file and then use it to regenerate a git repo.
It seems that Git is storing copies of LFS files in .git/lfs. This is taking twice of the space. I know this is a typical way Git handles the files, but I'm still wondering if there is a way to prevent Git from caching copies of them and just download from cloud when trying to revert the files.
If the files are in the lfs folder, it's that git needed them at a moment to populate your working directory.
So, no, there is no way to prevent git to cache them (except maybe by doing a sparse checkout if you really don't need to have the files handled by git-lfs in your working directory).
But you have an easy way to clean this cache directory (git will keep only the currently used files and delete the others unused) with the command:
git lfs prune
I've developed two small programs, both of which include my_lcd_lib.h and my_lcd_lib.c.
To prevent code duplication I moved this "lib" from the include folder in each project to /usr/local/include. So far, so good.
How could I tell Git to include those files when pushing the repo?
So the repos from Prog1 and Prog2 would have their own copies of the header/source files.
I can imagine three ways:
When pushing the program repo from dev pc to gitlab server, git could include those outside files by some tricks. Maybe need to edit some .git* files?
I could make a lib-repo for the stuff in /usr/local/include. I could set up my program repo to load the appropriate files from the lib-repo. Is that what the pipe/cli are meant for?
I could copy the header files from /usr/local/include to the program repo just before pushing the program repo. This looks very unsexy.
No, you cannot push files outside the repository. Git does not push individual files, it pushes commits. The files have to part of a commit.
Once you've committed those files in your repository, the rough solution is to symlink them into /usr/local/include/. The better solution is to used a build tool like autoconf and install them in /usr/local/include.
Git is not a substitute for a build tool, nor dependency manager, nor installer.
I'm collaborating with a few other people on a Drupal website which we are version controlling Git. We setup a local Git repository containing our commits.
After a colleague pushed some updates and I fetched and merged into my local dev branch, I began experiencing the following problems:
user#server:/var/www/Intranet/sites/intranet/modules/custom$ git checkout dev
error: The following untracked working tree files would be overwritten by checkout:
themes/bigcompany/panels/layouts/radix_bryant_flipped/radix-bryant-flipped.png
themes/bigcompany/panels/layouts/radix_bryant_flipped/radix-bryant-flipped.tpl.php
themes/bigcompany/panels/layouts/radix_bryant_flipped/radix_bryant_flipped.inc
Please move or remove them before you can switch branches.
Aborting
The issue above typically shows up when I try to checkout into other branches which fails and I am effectively trapped in my current branch.
Referring to this question, there is a suggestion my issue is related to the gitignore file. However, my .gitignore file has nothing indicating any part of my themes directory should be ignored as the following shows:
# .gitignore for a standard Drupal 7 build based in the sites subdirectory.
# Drupal
files
settings.php
settings.*.php
# Sass.
.sass-cache
# Composer
vendor/
# Migrate sourec files
modules/custom/haringeygovuk_migrate/source_data
As mentioned above, my attempts to execute git checkout into any branch fails with the message above. I decided to force it with the -f switch and successfully switched into my target branch but I lost a couple of hundred lines of code - which I'd love to avoid going forward.
I work on a Linux-Ubuntu VirtualBox which my colleagues prefer working in a WAMP setup and use the Git Bash terminal emulator for executing the Git commands. Could the difference in environments be causing these serious issues?
How can I resolve this issue?
Well, the situation is rather simple. You, in your current branch, don't have certain files under the control of Git, but at the same time, you have those files in your working tree. The branch you're trying to switch to, has those files, so git would need to override files in the working tree to perform checkout.
To prevent possible data loss, Git stops the process of switching the branches and notifies you that you should either add those files under the control of Git in a separate commit in your current branch, and only then perform the switch, or simply remove those files from the git way.
Likely you have chosen the second way. Generally you should "force" any operation only if you really understand what you're doing.
I tried installing git-annex yesterday to backup my files. I ran git annex add . in the root of my repository tree and then a git commit. So far everything is fine.
What I didn't know git-annex was doing was turning my entire file tree into a whole bunch of symlinks. Every single file in my whole tree is now symlinked into .git/annex/objects! This is messing up my application which depends on files not being symlinks.
My question is, how do I get rid of git-annex and restore my file system to its original state? For a normal git repo I could do rm -r .git, but I'm afraid that won't do the job in git-annex. Thanks in advance.
Okay, so I stumbled upon some docs for git-annex, and they give two commands that achieve what I wanted to do:
unannex [path ...]
Use this to undo an accidental git annex add command. You can use git annex unannex to move content out of the annex at any point, even if you've already committed it.
This is not the command you should use if you intentionally annexed a file and don't want its contents any more. In that case you should use git annex drop instead, and you can also git rm the file.
uninit
Use this to stop using git annex. It will unannex every file in the repository, and remove all of git-annex's other data, leaving you with a git repository plus the previously annexed files.
I started running git annex uninit, but my god was it slow. It took about 5 minutes to "unannex" just a single file. My filesystem tree is about 200,000 files, so that was just unacceptable.
What I ended up doing was actually surprisingly simple and worked well. I used the cp -rL flags to automatically duplicate the contents of my file tree and reverse all symlinks in the duplicate copy. And it was blazing fast: around 30 seconds for my entire file tree. Only problem was that the file permissions were not retained from my original state, so I needed to run some chmod and chcon commands to fix up the permissions.
This second method worked for me because there were no other symlinks in my schema. If you do have symlinks in your schema beyond those created by git-annex, then my little shortcut probably isn't the right choice for you, and you should consider sticking with just git annex uninit.
I would like to include my own experience of using git annex uninit, in addition to OP's answer.
I didn't have full repository annexed, but only about 40 bigger files. After deciding that I have no particular benefit of using git-annex, I tried unannexing several files and it was over in several seconds per file. Then, I ran git annex uninit and it took more than a minute only for really huge files (more than few GB). Overall, it was done in about 20 minutes, which was acceptable in my case.
So, it seems that the complexity of unannexing increases with the size of annexed file tree.
If you have a v6 repository, you can do the following:
git unnannex . --fast
which replaces the symlinks w/ hardlinks instead of slowly replacing the symlinks with the original files again.
Only v6 repositories can execute the git-annex unannex command on uncommited changes, so it could be necessary to upgrade the git-annex repo to a v6 repository.
See the Official Upgrade Guide.
In my case I had to upgrade v5 -> v6 and I only had to execute
git annex upgrade
which took a few seconds and I was done.
Have you tried to use git-annex in direct mode?
Just change your repository with
git annex direct
This will not use symlinks any longer, but some git commands do not work with such annex repositories.
Check out the explanations on their website to see if this scheme fits your purposes.
Maybe the conversion process is faster then the previous mentioned tips.
I haven't tried it by myself with big repositories.