Using git init in my terminal on mac creates a hidden a folder. I used command + shift + . to show folder, but it appears faded and can't be detected for further functions.
enter image description here
Code:
cd "desired folder"
git init .
when i cd .git, it works; however, i cannot ls into .git. I can also add and remove in code but the changes appear as changes to be committed. When I open the .git folder my files aren't saved there.
Could someone please assist?
Thanks
Git stores its data within the .git directory, and that directory is created by running git init (or as a part of running git clone). On macOS, like other Unix systems, files that start with a dot are hidden, which is normal, and it's intended that this folder should be that way.
Once you've committed data, that data will be stored in the .git directory in an internal format, so it will not be readily visible. If you want to access it, you'll need to do so using the git command or a library, such as one based on libgit2.
You should, unless you know what you are doing, not modify the contents of the .git folder, possibly with the exception of the files in .git/info and .git/hooks (after reading the documentation thoroughly). Also, the history of your project is stored there, so if you delete the directory or its contents and haven't pushed the changes elsewhere, you'll lose data.
So it appears everything is working as expected in this case and you can just ignore the .git directory and its contents, using the git command as normal.
Related
I'm confused. The following commands were executed on a Windows 10 command window:
First I list all the .git files on the entire C drive, then go to a specific directory where none was found and enter "git status". That command returns status, indicating that that directory (or a parent of it) HAS been initialized as a local git repository. For good measure, I list all the files found in that directory as well.
How can that directory return git status if neither it nor its ancestors have ".git" files in them?
A history -- I am fairly sure that I executed "git init" in this directory, but I have now changed my mind and want to get rid of its status as a git repository. I thought that would be done by deleting the ".git" file, hence my search (for the file and for information). Is there some other way to remove the 'git' status of a directory?
On Windows .git folder is hidden by default and dir command doesn't show hidden files by default.
Running dir /A should list missing .git folder.
I'm working on a python project and want to rename a (package) folder to small letters, let's say from Myackage to mypackage. As git is case-sensitive and Windows is not, I followed the solutions taken from here and espacially here.
My procedure was as follows:
git mv Mypackage tmp
git mv tmp mypackage
git commit -m "Change capitalization of package name"
This changes the folder Myackage to mypackage with success (for both, git and Windows). But if I switch to another branch, I expect the folder to change back to Mypackage (with capital letter!), as it was before. Background is, that all the imports of the package are also case-sensitve in python and i need this renamng acompanied with adaptions of the imports.
I've tried both, core.ignorecase set to true and false, but no matter what I try, if I checkout an older branch, the folder remains in form of small letters (mypackage) and I run into issues within python.
UPDATE:
I've set up a small example with only one Folder and one file and could succesfully change the capitalization of the folder. It also shows the desired behaviour, that upon branch switch the capitalization of the folder in Windows changes, yet still this won't work for my python project.
Could it be, that, e.g., submodules, play a role here?
UPDATE 2:
I've checked the case sensitivity attribute for both cases via:
fsutil.exe file queryCaseSensitiveInfo .
Both folders claim, that case-sensitivity is deactivated. Still for one project folder name capitalization changes, but for the other folder not.
The attribute case sensitivity is available on Windows 10 but after April 2018 Update and only affect the specific folder to which you apply it. It isn’t automatically inherited by that folder’s subfolders. However, if you use WSL to create folders it's enabled by default and available in that way to Windows. [1]
Although you can use the Git Unite [2] tool to match the case of the current folders with the git index.
If you use the rename approach, try using it with git commands like in "Rename files and folders with git"[3]
git mv foldername tempname && git mv tempname folderName
I found a way to reproduce your behavior :
if my CaSeD folder contains some extra files (untracked files for example), git will not change the case of my folder name when I jump between commits.
Is this the case in your setup ?
If this is your issue : you could go with a post-checkout hook, which forcibly renames the folders according to what is stored in HEAD after a checkout.
One way to get the full list of paths to directories from commit HEAD is :
git ls-tree --name-only -d -r HEAD
If you match this list with a similar list extracted from your local file system (ls -r ? find . -type d ? some python function from os.* ?), you can spot what folders need to be recapitalized.
We have a git repository for a scientific software where we need to maintain a certain folder structure for our data files.
These folders should remain empty, everything that will be put there should not be tracked by git. However, it is necessary that those folders exist.
The solution to accomplish this was to add a .gitignore file into every directory which looks like this:
*
!.gitignore
which means everything inside this folder is ignored except for the .gitignore file.
This works very well.
We maintain all our data on one particular server.
Our scientists use this server often for their calculations.
It would be very convenient to be able to replace the data folders from the git repository which currently contain only the .gitignore file with a symbolic link to the full data files on this server. The data files on the server also have a .gitignore file which looks exactly the same as in every repository.
I wrote a bash script to do this which looks like this:
rm -r path/to/empty/data/in/repository/name
ln -sfn /absolute/path/to/data/on/server/ path/to/empty/data/in/repository
Now the software runs perfectly and you have access to all the data without copying it into your git repository.
However, git now gets confused.
If I run git status only my changes are listed as expected. It does not complain about the new symbolic links which replaced the existing directories.
As soon as I run git add . to stage my changes the symbolic links appear as new file: and the .gitignore files in the replaced folder are listed as deleted:.
This seems like a problem to me because as soon as somebody pushes his code changes that he made on the server the symbolic links would get uploaded (I guess) and the .gitignore files would get removed and thus the folder structure would not remain.
Is it possible to tell git that it should compare the content of the symbolic linked folders rather than the symbolic link itself?
PS: I know this seems like a software design issue with the static folder structure which is inside git but I do not want to discuss this here. We are all scientists and no programmers and the software is now developed for over 10 years by many different people. It is not possible to change the code to make it more flexible.
EDIT: This bash code reproduces the problem:
cd ~ #setup
mkdir tmp
cd tmp
mkdir server #server data folder (this one is full of data)
mkdir server/data
printf '*\n!.gitignore' > server/data/.gitignore
printf 'data file 1' > server/data/data1.txt
printf 'data file 2' > server/data/data2.txt
mkdir repo #repo data folder (this one only contains .gitignore file)
mkdir repo/data
printf '*\n!.gitignore' > repo/data/.gitignore
cd repo # create a dummy repo
git init
git add .
git commit -am"commit 1"
git status
cd .. # replace data folder with server/data folder which hase exactly the same content
rm -r repo/data/
ln -sfn ~/tmp/server/data/ ./repo/
cd repo
git status
At the end git status should ideally not list any changes in the repository.
EDIT:
I found a workaround: instead of linking the whole directory I'm now linking the content of the directory:
ln -sfn /absolute/path/to/data/on/server/* path/to/empty/data/in/repository/
this works because the symbolic links are irgnored due to the .gitignore file.
Drawback is that it only works with existing data. As soon as there is a new file in the server directory I have to run the bash script again.
Git tracks symbolic links. What you're trying to achieve can be done with bind mounts.
Replace the final ln -sfn ~/tmp/server/data/ ./repo/ with sudo mount --bind $PWD/repo
$HOME/tmp/server/data/
We are forced to work on Windows at work, and I have lets say problem, strange situation. We have github repository, inside which we have one directory with name Something (with capitalized first letter 'S'), but in my local I see this directory with name something (note lower case 's'), git status shows that working directory is clean, even if I change this directory locally to, for example SoMeThInG git says that nothing changed. I suspect that Windows is here a problem, as it is case insensitive. Is there possibility to change this directory name from Windows level? Or maybe how to force git bash to be case sensitive?
Update
I've changed that files from mine virtual fedora, but this is just a workaround, the question remains unanswered, how to do it properly on Windows?
On case-insensitive file systems, Git will not detect changes just in casing. However, when committing files, the actual casing is still being reflected in the way it was added to the index.
So a git add file and git add FILE will both work for a file that is named file in any kind of casing (e.g. FiLe or fIlE), but each command will actually stage that exact name into the repository. So git add file will make the name be case-sensitive file and git add FILE will make the name case-sensitive FILE.
That’s why you should try to always use your command line auto completion for file names, so you don’t accidentally add files with a different casing than they actually are. Or use commands that stage the files automatically, e.g. git add ., since that will also use the actual casing.
However, since Git will not detect casing changes, once a file has been added with a particular casing, that casing will be used until you explicitly change it. That’s why it’s possible to have files in a folder src/readme.md and SRC/license.txt that are both physically in the same location on your file system, but are represented using incompatible paths inside of Git. So you should be careful here.
That all being said, you can fix the casing later. But to do that, you need to make the change using Git instead of the file system, as Git is case sensitive while the file system isn’t. So commands like git mv will work. Same as a combination of git rm --cached and git add.
For example, to fix the above situation of the src/SRC directory, one could do (assuming the correct name of the folder should be Src):
git mv src/readme.md Src/readme.md
# or
git rm --cached SRC/license.txt
git add Src/license.txt
You can also fix the casing for every file by removing everything from the index, and then adding it back:
git rm --cached -r .
git add .
That should stage all renames to the correct file casing.
I am having issues with the command-line client of svn - svn-win32.
Current situation:
We have a directory with multiple subfolders, like so
file1
folder/archives/file2
folder/archives/file3
Situation1:
A new file is added via checkout.
Everything behaves as it should.
Situation2:
An existing file is modified via checkout.
Result: Existing file remains, and is marked as "modified".
Desired result: Existing file fully overwritten, local changes lost.
How do i achieve the desired result?
svn revert -r pathname
svn up
did not help.
svn revert requires a path be passed in; use svn revert -r . to discard all changes in the current directory and everything below, or specify a directory or file if you want to revert that path and everything below it. Then you can run svn update.