i have a container generated from an image, and that image was generated by another container
The container that the image was based there two directories, one of these directories i created with mkdir, the other directory was created through the git clone.
But when I generate a new container from that image, I can not delete the directory that was generated by git, I can erase that exists within that folder, but not the root folder.
I can delete the folder created by the mkdir.
I do not know if there is a special feature of git to control files.
ever was something like the docker, but the issue was closed https://github.com/docker/docker/issues/1672
Sorry for my bad english
Related
I am new to Yocto, I have created a read-write folder on a readonly filesystem using volatile-binds package of yocto. I have pushed some test files into that folder for testing.
After loading the image, I was able to see the folders getting created. I am trying to delete the contents int this created writeable folder over a factory reset using 'rm' using v_secure_system() call. But the files don't get removed. I was able to verify that rm works perfectly by manually trying it in serial console after loading the image.
What i find it weird was i am able to list the files (ls) and move the files (mv over the folder), but not remove it with rm.
Is there anything that could cause this behavior.
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 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
Container 1 : I have a docker container which is spawned by a Dockerfile image that i built serving Python dependencies to a specific use-case. This container is mount to my file system project directory to /source directory in the Docker container.
Container 2 : Another container contains Jupyter notebook and it is only configured to use Jupyter notebook.
I don't use Jupyter notebook all the time for Python developement, i use my code editor instead. I just want an easier way to mount Jupyter notebook when i want to and edit my project files.
Now, can i mount Container-2 to Container-1 such that contents in the /source directory in Container-1 is persisted to my project directory while enabling Container-1 and Conatiner-2 to take up a shared space? In my case i want Container-1 to be mount to my file system to /source and I want the Jupyter Notebook, running in Container-2 to be able to edit files inside the /source directory in Container-1.
if I'm understanding correctly, what you are trying to do is using one container installed libs in another container
I think that this approach is bad, since there might be some problems with OS level dependencies that are missing. The first possible solution is installing the dependencies in both containers, or at least using the 1st docker image as base to the 2nd
If you yet rather doing it your way, you can try mounting volume between the 1st container virtual env / site-packages with the 2nd
Currently, I am using GitKraken to upload my files to Gitlab. However, there was a submodule that contained all my files for the project - in an attempt to combine the submodule into the main respiratory, I tried deleting it; however, my entire submodule is gone now. When I go into the trash folder of my Mac, I can see the folder except it is named with extra letters and contains files such as Build and Test Index. Is there anyway to get this submodule back?
UPDATE: I tried reverting the files from the trash folder, but it only put the files back into the derived data folder. Not sure how to get the submodule back, it is asking to initialize it by specifying a URL.