For my project I'm using by .gitignore as a 'don't ignore' file by telling it to ignore everything in the first few lines then giving it a list of file to include with the ! character. I added a file to my list and copied the file to my working directory and did a "git status" but it's not showing my new file as something to be added. Even "git status -u" doesn't show anything but says my working directory is clean.
This is on a Raspberry Pi with Debian Wheezy and git version 1.7.10.4, which should be the latest version for Wheezy. I can do a build of git from the source if that is the fix.
Just remove it from .gitignore and you will see it, there is no point of putting it there if you want it to be committed.
Related
On a quite fresh setup I ran
bin/build-storefront.sh
Now var/plugins.json is on the list of changed files in git. Now I am wondering if I should commit this file, because it contains local absolute paths - which might be different on other systems:
EDIT: The file seems to be recreated during build, when I deleted it. However it's in the production-template git repository which is strange.
var/plugins.json is auto generated by build-administration.sh and build-storefront.sh to set entry points and output files for Webpack for the installed plugins.
This file should not be commited. If you commit, it will be replaced anyway. It will be ignored by git in the upcoming version of Shopware 6.4 (see the commit).
I'm going to answer my question with the fix what solved my problem.
Note for downvoters: I understand that the root cause is discussed in various other threads (that is how I solved my problem). This post is more about how having a dual boot system can lead you to this issue. So no, this question/answer is not a duplicate, but a particular instance of a general class of problems, adding more cases to SO's repository on this issue.
At home: I code in Linux. LF used as line ending
At the office: I code in windows. CRLF used as line endings.
By default, git's autocrlf feature (https://stackoverflow.com/a/20653073/2715083) keeps things happy.
However, if you run a dual boot system with Linux and Windows, you can mess yourself up in the following way:
git pull some files you worked on in a linux environment in a windows environment, in a location that can be accessed from the dual-booted linux environment. This modifies the files to contain CRLF endings.
Then when you open up the file in linux, where the default is only LF, git diff will say entire file is modified, because each LF got changed to CRLF at every single line. (I was warned by Atom, which has this diff count inbuilt)
you are talking about text=auto part? I wasn't sure If I need to include that in a new .gitattributes file or not, because when I did, ATOM still showed the files as modified.
Yes, it does.
To force Git to apply .gitattributes directives, see "Dealing with line endings".
I would first make sure core.autocrlf is set to false.
git config --global core.autocrlf false
Then:
git add . -u
git commit -m "Saving files before refreshing line endings"
rm .git/index
git reset
git status
git add -u
git add .gitattributes
git commit -m "Normalize all the line endings"
You can also use, to force the index re-normalization:
git rm --cached -r .
git reset --hard
See "Force LF eol in git repo and working copy"
* text=auto eol=lf
The FIX
Delete/move to another location the problem files/folders
do git checkout <hash> <your/files/location>
where <hash> is for the last good commit, and your/files/location being the location of the files you want to cure from the CRLF problem. This will basically restore the older versions from your local .git repository.
Worked for me.
If you know something i missed, or explained incorrectly, do let me know
I have tried to search for a way to resolve this and have come up with nothing so far.
I made changes to certain files in a directory. I then performed an svn add and svn commit for those files I changed. Then (by accident) I deleted the directory in svn containing the files I just modified. (the directory names were different which is what caused the mix up).
My goal is to get back the directory I deleted with my modified files or get back just the modified files. I have tried using svn merge -c REV and recommitting. it first told me there was a tree conflict with the directory i deleted so i did an svn resolve --accept working PATH. I have also tried an svn merge -r (current):(previous) to no avail.
Please help. I am using Linux (centOS)
I'm just entering into the wonderful world of git.
I have to submit a bunch of changes that I've made on my program, located in a directory called /var/www/myapp.
I created a new directory /home/mylogin/gitclone. From this directory, I did a git clone against the public repo and I was able to get the latest copy created.
I'm now trying to figure out how to take all the files in my working folder (/var/www/myapp) and "check them in" to the master repository.
From /home/mylogin/gitclone, I tried git add /var/www/myapp but I'm getting an error that the folder I tried to add is outside the repository.
Can you give me a few pointers on what I'm doing wrong? Also, I'd like to add everything, whether it's different from the master or not.
Thanks.
First in the clone folder you can create a Branch (so the master stay untouched)
git branch [branch_name]
After, just copy the files you want from your old folder to the clone folder.
When you are done, just add / commit your change and Merge your branch into the "master" branch. It will look like to something like this:
git add .
git commit -m "Comments"
git checkout master
git merge [new_branch]
Try this tutorial from GitHub.
You'll have to move all the files from /var/www/myapp to /home/mylogin/gitclone and then do a git add . and then git commit -m "Your message".
When upgraded to git version 2.12.2 that error appeared, I nooted the i add the file with a full path like:
git add c:\develop\project\file.text
when removed the full path it start working, like:
git add file.text
To add some files or folder to your repository, they have to be in the folder you created with git clone. So copy/paste your application in your local git folder and then go in it and do git add * and then you'll be able to commit to the server with git commit -m 'message' and finally push the changes to the server with git push
Okay, this error came up for me because I moved the project from one computer to another.
So the git was not able to figure my global git user.name and user.email
I opened the command prompt and specified my old git user.name and user.email from previous computer. Kindly run the following commands and it should be fixed.
cd pathToMyProjectDirectory
git config user.name "myName"
git config user.email "myEmail"
That's because you are versioning stuff inside /home/mylogin/gitclone and git tracks everything inside that folder. You cannot track other folders outside of this repository.
A solution might be create a submodule, or using a symbolic link using ln -s
Git only tracks files and folders within the root folder which includes the .git directory and the subfolders inside root folder. The folder you are trying to add is outside the scope of git.
What would you actually like to do is first git checkout -b myapp which will create and checkout a new branch based on the master branch of the repository you cloned. Then you would actually copy all your files over and commit them with git commit -a -m "Short descriptive name about what you did". The parameter -a you passed to git commit is for including all the changes done to the repository and -m is to include the commit message in the actual command. After that you can either push back to the main repository if you have write access to it or push it to your own public repo or don't push it at all.
What I've described above is pretty much the basics of git. Try reading this book which is pretty descriptive.
Maybe someone comes along having the same trouble like I had:
In my case this error was thrown while using husky (commit hooks) https://github.com/typicode/husky
It was just an error because of encodings. My source was located in a directory that contains a special character ("รถ")
Seems like husky uses "git add" with the absolute path of the source which fails somehow at this point
I renamed the path and it worked fine.
This message can also appear when the file name is listed in the .gitignore file.
My scenario is that the git repository's path has symbolic link and git throw out this error when add file say to "/home/abc/GIT_REPO/my_dir/my_file".
and "/home" is actually a softlink to "/devhome".
code ninja gave me some light when I tried to debug this case.
So I tried get the target directory by using the command readlink -f /home/abc/GIT_REPO before run add command.
And then everything works like a charm !
I encountered the issue at Windows box with maven-release-plugin.
The plugin tries to add files using absolute path and I have noticed that the path in the Git add command starts with uppercase D: while the path in Working directory: log line started with lowercase d:
I have added core.ignorecase = true to the Git settings and the issue was gone.
I am new to use svn and the company in which I work uses three levels (I don't know whether this is a correct word to use here) of svn. I mean the developers are provided a working directory on a testing server. When we commit, it goes to the dev server. When a manager commits it from there it goes to production server. I am a developer here and one of my files is giving error (conflict) when I commit from directory. Not only, but also it gives conflict when manager tries to commit. I am now given access as manager too but I am still unable to resolve it.
What I've tried till now:
svn update
svn delete
svn commit
It gives conflict on all of these operations.
Earlier on a simple error happened and the manager preferred to just delete file on dev, copy it manually and then commit from there. I don't know this may be a reason of this problem or not.
Please help me resolve this issue. I've read some things in read-bean book too but to no avail yet.
Thanks
Ok, here's the update. The actual problem is that a file (ex lib/a.php) used to be in my working directory as well as in dev and production servers. Now it was deleted by someone (using del command, not svn delete) from dev server. Now question here is how I add it again so that it becomes part of svn again. The simple svn add doesn't work.
Update 2
From one of the answers below I understood that its a tree conflict. Some searching brought me to http://svnbook.red-bean.com/nightly/en/svn.tour.treeconflicts.html . Following the instructions, I took the backup of the file and then svn delete it from everywhere. Then I svn add it to my directory, commit it and tried to update dev and production. End result is that it doesn't go there. No error is shown either.
svn info in my directory shows complete info of the file but on dev and production it shows
file_name: (Not a versioned resource)
:S
Any more ideas please?
Alternatively you can take backup of the file ,then say svn revert filename insert you new code.Do a svn up just to make sure you do not have any conflicts,and then commit
Or
fix the conflicts in the file and then you can say svn resolved filename and then you can continue operations on the file
Update:If your file is deleted using rm or del command use svn revert filename to get it back and you do not have to add it again.Just put in your new changes and say svn ci -m"your comments" filename
svn revert will fetch back the last checked in copy into SVN and it wouldnt have your any changes made before the user had used del command
Update 2:After u say svn delete ,u need to commit it until u get the message Deleting filename with a new revision number.Then add the file using svn add command,then commit again.Once this is done you can check the svn info, let me know..
Use svn status command to know the status of the file
The only problem apart from this i can think of is this the directory may not have been added.Is this a new directory?
ah, the old tree conflict problem.
The issue is that SVN is letting you know that you're adding a file that used to be there but it cannot tell whether you're trying to delete it, add it or just update it! So it does the only thing it can - flags a conflict so you can sort it out and fix it. Its basically a conflict on the directory level (rather than a conflict of a file's contents).
What you do is resolve the error (as others have pointed out), then update the directory to get the original file back, then commit your changes. Note that the file was never deleted from SVN - its still in the repo, and if you checkout out a new WC, you'd get the file.
Try to resolve the conflicts then commit again:
svn resolve --accept working