Hi I have just started my git repo and this is my first time using git in windows
anyway I have added my project and commited it, however, whenever I mod a file it thinks that I need to re-add even though I have already done that.
$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: bonfire/content.php
# modified: bonfire/style_1.css
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# .htaccess
# .htaccess_del
# .smileys/
# 1.htaccess
# docs/
# nbproject/
no changes added to commit (use "git add" and/or "git commit -a")
$ git add bonfire/content.php
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: bonfire/content.php
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: bonfire/style_1.css
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# .htaccess
# .htaccess_del
# .smileys/
# 1.htaccess
# docs/
# nbproject/
I really don't want to have keep doing this. I believe I added the project properly. Not sure what to do at all
Thanks
This is just how git works, your repository is set up correctly. You commit the contents of the staging area, not your working tree, so you have to add the changes to the staging area first. This is quite handy if you only want to commit some of your changes, or split your changes into several commits, because you can even add partial file changes to the staging area (using git add -p).
However, in case you just want to commit all the modified files, there is a shortcut: Just use git commit -a. This will directly commit all modified and deleted files in working tree. You will still have to add newly created files manually, but it sounds like that's what you expect anyway.
Related
Changes mysteriously appeared in a file (lib/spo_api.rb) when I switched to master, and I could not get rid of the changes with git restore to switch back. The shell history says it all more explicitly, but skip down to the bottom if you already understood.
💻 git status
On branch master
Your branch is up to date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: lib/spo_api.rb
no changes added to commit (use "git add" and/or "git commit -a")
💻 git diff
diff --git a/lib/spo_api.rb b/lib/spo_api.rb
index 4af1ffb..54628c4 100644
--- a/lib/spo_api.rb
+++ b/lib/spo_api.rb
## -22,4 +22,4 ## class SpoApi
{ success: res.success?, data: data }
end
-end
\ No newline at end of file
+end
💻 git restore lib/spo_api.rb
💻 git status
On branch master
Your branch is up to date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: lib/spo_api.rb
no changes added to commit (use "git add" and/or "git commit -a")
You can see that the first and last git status invocations are the same, and that git restore lib/spo_api.rb does nothing. 😱
I tracked it down to something in my .gitconfig:
[filter "bindingpry"]
clean = sed '/^\\s*-?binding.pry$/'d
smudge = cat
This is here to prevent accidentally leaving binding.pry (for debugging in Ruby) in a codebase, and it works perfectly as long as all files have a final newline, as they should. Of course I can't control the behavior of every developer who goes before me, or who works in the same repo concurrently with me, and while of course I have plans to clean up such files in repos I work in, it would also be nice if I didn't get shot in the foot by my own safety measures.
What would make the above filter work as I want it to? (I'm using zsh but I imagine 98% of what works in Bash will work for me too.)
I'm on Windows and I have core.autocrlf disabled:
$ git config core.autocrlf; git config --global core.autocrlf
false
false
Now, I would assume, that git does not mess with any line endings, but some files in my repo keep causing issues.
I just cloned a fresh copy of the repo, and git is already telling me that there are unstaged changes. When I git diff -R, I can see that CRLF line endings have been added to a file:
diff --git b/nginx-1.11.1/contrib/geo2nginx.pl a/nginx-1.11.1/contrib/geo2nginx.pl
index bc8af46..29243ec 100644
--- b/nginx-1.11.1/contrib/geo2nginx.pl
+++ a/nginx-1.11.1/contrib/geo2nginx.pl
## -1,58 +1,58 ##
-#!/usr/bin/perl -w
-
-# (c) Andrei Nigmatulin, 2005
+#!/usr/bin/perl -w^M
+^M
+# (c) Andrei Nigmatulin, 2005^M
I don't understand where these line endings come from, but I'm also unable to "revert" this change. When I checkout the file again, it will still be modified afterwards:
$ git checkout -f nginx-1.11.1/contrib/geo2nginx.pl
$ git status
On branch dev
Your branch is up-to-date with 'origin/dev'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: nginx-1.11.1/contrib/geo2nginx.pl
no changes added to commit (use "git add" and/or "git commit -a")
This makes no sense to me, so I just run dos2unix on the file:
$ dos2unix nginx-1.11.1/contrib/geo2nginx.pl
dos2unix: converting file nginx-1.11.1/contrib/geo2nginx.pl to Unix format...
Now there surely shouldn't be any changes, right? But the file is still being shown as modified in git status and git diff will still report CRLF line endings in the working copy.
When I now stage and commit the file, the resulting file will have LF line endings, even though the diff showed CRLF line endings.
I don't have a global .gitattributes (git config --global core.attributesfile does not output anything). And the .gitattributes in the project has * text eol=lf set (full .gitattributes).
What is going on here and how can I resolve this?
Reproduce the issue
I can repro this issue with an open source project I'm maintaining:
$ git clone git#github.com:fairmanager/fm-log.git
Cloning into 'fm-log'...
remote: Counting objects: 790, done.
remote: Total 790 (delta 0), reused 0 (delta 0), pack-reused 790
Receiving objects: 100% (790/790), 201.71 KiB | 138.00 KiB/s, done.
Resolving deltas: 100% (418/418), done.
Checking connectivity... done.
$ cd fm-log/
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: .idea/dictionaries/OliverSalzburg.xml
modified: .idea/inspectionProfiles/Project_Default.xml
modified: .idea/inspectionProfiles/profiles_settings.xml
no changes added to commit (use "git add" and/or "git commit -a")
Interesting: with the newly added-to-question repo I tried cloning it and, on BSD, see the same thing:
$ git clone git#github.com:fairmanager/fm-log.git
Cloning into 'fm-log'...
remote: Counting objects: 790, done.
remote: Total 790 (delta 0), reused 0 (delta 0), pack-reused 790
Receiving objects: 100% (790/790), 201.71 KiB | 0 bytes/s, done.
Resolving deltas: 100% (418/418), done.
Checking connectivity... done.
$ cd fm-log/
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: .idea/dictionaries/OliverSalzburg.xml
modified: .idea/inspectionProfiles/Project_Default.xml
modified: .idea/inspectionProfiles/profiles_settings.xml
no changes added to commit (use "git add" and/or "git commit -a")
Trying to see what's going on:
$ git diff
warning: CRLF will be replaced by LF in .idea/dictionaries/OliverSalzburg.xml.
[snip]
It seems that HEAD:.idea/ files actually have carriage-returns in them (and the last line has no newline, hence the prompt right after the close angle bracket):
$ git show HEAD:.idea/dictionaries/OliverSalzburg.xml | vis
<component name="ProjectDictionaryState">\^M
<dictionary name="OliverSalzburg">\^M
<words>\^M
<w>colorizer</w>\^M
<w>multiline</w>\^M
</words>\^M
</dictionary>\^M
</component>$
The work-tree version likewise has carriage returns (no cut and paste but vis shows the same \^M line endings).
So what has happened in this case, at least, is that due to the .gitattributes setting of:
$ head -2 .gitattributes
# In general, use LF for text
* text eol=lf
Git will convert these files to LF-only during commit, vs the HEAD version that contains CR-LF endings. This is what git status is saying here.
Commenting out the * text eol=lf in .gitattributes makes the status go away (since the files won't be converted), though of course .gitattributes is now marked as modified. Interestingly, putting the attribute line back again, the status goes completely silent: it's necessary to force git checkout to replace the work-tree version to get the status back (e.g., manually rm -rf .idea and check out again, or git reset --hard).
(Presumably—I'm guessing a bit here—the index entry gets marked specially during git checkout when Git notices that the work-tree and HEAD version differ. This makes Git inspect the file closely. Modifying .gitattributes and running an internal diff via git status probably un-marks the index entries. This part is pure speculation meant to explain the weird behavior of git status...)
If the local setting git config core.autocrlf is indeed to false, then those eol changes must come from a .gitattributes file (see man page).
Look for one in your local repo, which would include eol rules (like * text=auto eol=crlf I mentioned here).
Or check if you have a global gitattributes file.
git config --global core.attributesfile
Regarding fairmanager/fm-log, you can see one of the "modified" files .idea/dictionaries/OliverSalzburg.xml added in commit e6f823b with crlf at the end.
Since the .gitattributes has * text eol=lf rule, the working directory checkout blobs with lf eol, hence the git diff.
my .gitignore file
ext/templates_c
my git status call
D:\Development\online\site\newsite>git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: ext/pages/config.php
# modified: ext/templates_c/60a4cccd667e8b1e3a702b2a2c9108f056837adc.file.pages.html.php
# modified: ext/templates_c/fd38ffaa13c6f4c29772bec22cad5aebb1d4d7f6.file.form.html.php
#
no changes added to commit (use "git add" and/or "git commit -a")
Have I done something really stupid?
Why isnt git ignoring the files in ext/templates_c
The fact that git status shows files in your "ignored" subdirectory as "modified" means that those files are already being tracked by git. Because of this, simply adding the directory to .gitignore is not sufficient to get those files ignored (although new files in that directory will properly be ignored). You need to do a git rm --cached <file> for each of the files in that directory that are currently tracked.
As I was writing this I discovered that
ext/templates_c
does not work but
ext\templates_c
does.
So you need to use windows slashes.
I have follwoing dir structure
and here is content of .gitignore
conf.php
The problem is, when I change contents conf.php and try to commit something, GIT detects conf.php as changed file again. In fact it must be ignored.
I have commited it once. I want to ignore it from now. What am I missing?
Update
I tried following:
Added conf.php to gitignore
removed it from cache git rm --cached conf.php.
But now, when I rescan project, it wants to stage conf.php as removed.
Its not what I want.
I want to keep it on remote repo and ignore future (from now) changes in local repo.
Git will not ignore tracked files
Git will not ignore changes to already-committed files.
What Git ignore is for
Git ignore, ignores noise that's in your repo, for example:
$ git init
$ mkdir tmp
$ touch tmp/file1
$ touch tmp/file2
$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# tmp/
nothing added to commit but untracked files present (use "git add" to track)
If the .gitignore file is modified to ignore the tmp directory:
$ echo "tmp" > .gitignore
$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# .gitignore
nothing added to commit but untracked files present (use "git add" to track)
the tmp dir contents are nolonger listed - but the .gitignore file IS listed (because I just created it and the file itself is not ignored).
Committing that, there are no changes listed:
$ git add .gitignore
$ git commit -v -m "addding git ignore file"
[master (root-commit) d7af571] addding git ignore file
1 file changed, 1 insertion(+)
create mode 100644 .gitignore
$ git status
# On branch master
nothing to commit (working directory clean)
Now any changes to the .gitignore file will show up as pending changes, any new files outside the tmp dir will show up as untracked files and any changes inside the tmp dir will be ignored.
Don't commit files that you don't want to track
If you've already added conf.php to your git repo, git is tracking the file. When it changes git will say that it has pending changes.
the solution to such things is to NOT commit files you don't want to track. Instead what you can do though, is to commit a default file, e.g.:
$ mv conf.php conf.php.default
$ # Edit conf.php.default to be in an appropriate state if necessary
$ git commit -v -m "moving conf.php file"
$ cp conf.php.default conf.php
Now any changes you make to conf.php - will not show up as unstaged changes.
if you want to add a empty config file to your project and then not track any additonal changes then you can do this:
edit conf.php to be in the state you want it to stay
add and commit the config.php
run the following git command:
git update-index --assume-unchanged conf.php
You will no longer see conf.php as having pending changes
To start tracking changes again, run this command:
git update-index --no-assume-unchanged conf.php
Just run git rm --cached conf.php
If you have more commited files to ignore:
git rm -r --cached .
git add .
Then commit and push your changes.
I have created a project called zz and it has a single file called ruby.rb in it. I am using git. I have already added ruby.rb to the staging area. Now I have modified the ruby.rb file and using git status below is the output.
nikhil#pc:/home/rapps/zz$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: ruby.rb
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# ruby.rb~
no changes added to commit (use "git add" and/or "git commit -a")
Now I see another file ruby.rb~ even though, I did not created it. Is git creating this file. I have seen tutorials on Internet and I think I have found this on my system only.
I'm on Ubuntu 10.10 using gedit with gmate plug-gins.
That's a temporary file created by some text editors. You may wish to create a .gitignore file to automatically ignore such files to prevent them from accidentally being added to your repository. You would put
*~
in your .gitignore file to exclude all files ending with a tilde.
Git does not create these files on my system, but I know gedit has a back-up system. If you disable the backup in gedit's preferences, the files should not be created again.
You can put this into the .gitignore file so git won't commit them:
*~
No, Git does not create files like ruby.rb~ This is a common method text editor applications do to save backups of the currently edited file.
No, git is not adding this file. It is likely being used as a file buffer or backup by your text editor. If you close your text editor, does the file disappear?
Git won't ever add a file or change the file system of your repository except in the .git directory, which Git knows to treat different.