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.
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
My git was init in folder ~/ryan/pythonproject/ and then later on I started using PyCharm and it created a venv for the project after importing. So now I have:
~/ryan/pythonproject/venv/
The first directory has my original work on the project, and then it appears I have a duplicate of my work under the venv folder.
Whenever I commit/add/push it does the original folder as well as the venv folder.
What I would like to do is have Git stop monitoring the original folder and only have git under the venv folder only. What's the best way to do that?
If you want to stop monitoring a folder you can put it to the .gitignore file. So i.e. you have:
YourProject/venv/FolderA
YourProject/venv/FolderB
YourProject/FolderA
YourProject/FolderB
Then just add the lower two to the .gitignore .
But please think about it whether this is really what you want. Usually it is the other way around. Keep your files and ignore the build folder.
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
I reinstalled my OS (KDE neon) and I thought why not backup my project git folder, before I reinstalled I made sure I commited any code and everything in my git project folder was up-to-date.
So after reinstalling, I moved my project back onto my PC from my backup drive and ran git-status and it wants to stage nearly all of my project?
What do I do? I don't want to commit all these files again when I have not editing any of them? Its nearly 800 files it wants to stage?
You could reset your project using:
git reset --hard branch_name
This would lose any unstaged files.
Or you could stash the changes:
git stash save 'msg'
This works like the previous one, but instead it saves the unstaged files in a separate "memory" (in case you need them later on).
Now, I may assume that the reason you got that situation in the first place is maybe when you restored your data back from the drive, the OS changed some properties on those files, stuff like creation/modification dates, permissions...etc. While the content of the files has not changed but the properties are. Still, git sees them as modified files.
is it possible to set a 'rule' that tells TortoiseSVN to automatically resolve conflicts on a specific folder?
ie. we have a shared resources folder - "/shared" that we use to store our latest bin files in. when we do a local build, the local bin files in that folder gets overwritten.
next time we do an svn update on that folder the update should pull the latest bin files from SVN and overwrite the previously locally-built bin files but this will throw a conflict because the files are binary and cannot be merged (and, should not be merged anyway)
we would like to setup a rule that tells tortoise to always "resolve using theirs" on that /shared folder ("svn update -R --accept theirs-full")
There's a SVN misuse here. If the files should not be merged as you said, the directory should be set to ignore all .bin files (svn:ignore). It doesn't make sense keep in version control binary files that are changed frequently causing so much collisions.
In your place, I would delete all .bin files from this folder. If it's really necessary to keep the files versioned, I would create a directory and place these .bin files in there, avoiding frequent changing.
But if you really want to keep the files as they are, I recommend you to write client-side hooks for post-update events. See TortoiseSVN Docs for more information.