0

I have this structure:

thumb/.gitignore

Inside that .gitignore I have:

#ignore everything
*
#except gitignore
!.gitignore

I've added a file inside /thumb folder. And it appears on as untracked!

I have:

git rm -r --cached .
git add .
git commit -a -m "gitignore SHOULD work"

Repeat the process, and git stills consider the file!

What am I not getting? Could it be related to other "upper" gitignore instruction, I mean, I use this a LOT because git doesn't understand folders... (so I've been told).

Please advice.

Update:

Here are the detailed commands requested:

1 - git ls-files

git ls (git ls was a command not found. I did "git ls-files" I hope it's the same. I didn't know any of them.)

$ git ls-files 
.DS_Store 
.gitignore 
test 
test2 
thumb_5363d384b0cff.gif

2- git status .

$ git status . 
# On branch dev 
# Your branch is ahead of 'hub/dev' by 1 commit. 
# (use "git push" to publish your local commits) 
# 
nothing to commit, working directory clean

3- git rm -r --cached .

$ git rm -r --cached . 
rm 'public_html/assets/images/cropkimages/thumb/.DS_Store' 
rm 'public_html/assets/images/cropkimages/thumb/.gitignore' 
rm 'public_html/assets/images/cropkimages/thumb/test' 
rm 'public_html/assets/images/cropkimages/thumb/test2' 
rm 'public_html/assets/images/cropkimages/thumb/thumb_5363d384b0cff.gif'

4- git status .

$ git status . 
# On branch dev 
# Your branch is ahead of 'hub/dev' by 1 commit. 
# (use "git push" to publish your local commits) 
# 
# Changes to be committed: 
# (use "git reset HEAD <file>..." to unstage) 
# 
# deleted: .DS_Store 
# deleted: .gitignore 
# deleted: test 
# deleted: test2 
# deleted: thumb_5363d384b0cff.gif 
#
# 
# Untracked files: 
# (use "git add <file>..." to include in what will be committed) 
# 
# .DS_Store 
# .gitignore 
# test 
# test2 
# thumb_5363d384b0cff.gif
MEM
  • 30,529
  • 42
  • 121
  • 191
  • 1
    And what do you mean by "git doesn't understand folders"? Ofc you can ignore folders with a `.gitignore` file. – Sascha Wolf May 05 '14 at 10:17
  • @LeGEC: Why is it useless? Without it `.gitignore` would be ignored as well. – sleske May 05 '14 at 10:34
  • @sleske: You are right, you would have to `git add -f .gitignore` the file the first time. However, once it is tracked, it won't be ignored. – LeGEC May 05 '14 at 10:37
  • With the `.gitignore` you posted, all files in `thumb/` should be ignored (unless they are already tracked). So there's something missing from your question. Could you post a [SSCCE](http://www.sscce.org/)? – sleske May 05 '14 at 10:40
  • @Zeeker: By git doesn't understand folders... :p I mean: in order to allow some folder to exist, I have to place a file in it. That's stupid. I end up adding some useless files, so that git can know they exist. I'm sure that there's a very clever reason for that, but I believe, there's a equal clever reason to consider that dummy. :) It's not my fault. – MEM May 05 '14 at 12:01
  • @skeske - They were tracked. That's why I did git rm -r --cached . (but even doing so, when I do git add . (they came again). – MEM May 05 '14 at 12:02
  • @sleske if there's something missing, I don't know what. I have described the steps I did. Precisely. The problem may rely on something else, but I'm clueless about what that something else is. – MEM May 05 '14 at 12:08
  • 1
    @MEM: No, you have not. If I create an emtpy git repo, add folder `thumb` with your `.gitignore`, and then add a file to `thumb`, it does *not* appear as untracked. So you did more than you wrote. Please read the link to SSCCE I posted, and then post a complete list of every single command you ran to create the problem, so anyone can reproduce it. Then we'll see... – sleske May 05 '14 at 13:38
  • In which directory were you when you performed the commands. In the `thumb` directory? – Sascha Wolf May 05 '14 at 14:55
  • @Zeeker - the first commands, the ones I did before the update, were executed on the project home directory. Not thumbs. The commands I describe on this question update, were done inside thumbs directory. – MEM May 05 '14 at 14:59
  • @MEM When I follow your instructions in a new repository with a prepared `thumbs` directory I can't seem to reproduce the issue. Could you try reproduce it using a freshly prepared git repository? And if you manage to reproduce can you provide us with further information on how you did it? – Sascha Wolf May 05 '14 at 15:30

3 Answers3

2

.gitignore rules will not apply to files that are already tracked.

If you have files inside thumb/ which are already versioned in git, and you want to get rid of them, you should :

# assuming you are inside thumb/ :
git rm -r --cached .
# check if gitignore is still tracked, maybe you will have to run :
git add .gitignore
# do not try to add the other files, just commit the new result :
git commit -m 'Removed wrongly tracked files'

then .gitignore rules should apply.

Please, go in your thumb/ directory, and paste the output of the following set of commands :

git ls
git status .
git rm -r --cached .
git status .
MEM
  • 30,529
  • 42
  • 121
  • 191
LeGEC
  • 46,477
  • 5
  • 57
  • 104
  • I don't understand. You are doing the same command that I did already endless times, but, it's more specific. I did it from the project root. You are telling me to do it on thumb directory specifically. What would one work, and the other wouldn't? – MEM May 05 '14 at 11:58
  • You have NOT placed -a on your command. :) Perhaps that's the difference? – MEM May 05 '14 at 12:11
  • I did -m without the -a. The files is still listed as untracked. :( No dice. – MEM May 05 '14 at 12:14
  • @MEM : no `git add .` before commit either – LeGEC May 05 '14 at 13:31
  • @MEM : I saw your update, it is what I was looking for. The behaviour of your git does not match my local behaviour : in the last step, the ignored files are indeed not listed under "untracked" on my machine. What git version do you use ? – LeGEC May 06 '14 at 07:36
  • git version 1.8.5.2 (Apple Git-48) – MEM May 06 '14 at 10:47
  • I edit your post with an update, with the right answer, and accepted it. Hope you don't mind. :p – MEM May 07 '14 at 12:18
  • @MEM : post your solution as an answer and accept that one ... Didn't know extra spaces could blow things up. – LeGEC May 07 '14 at 12:19
  • Neither did I, but this post make me wonder: `http://stackoverflow.com/a/9115498/378170` and the issue has gone. :) – MEM May 07 '14 at 14:38
1

After LeGEC answer, I've typed the commands and I've noticed that the files listed SHOULD NOT be marked as untracked.

By chance, I found this post: https://stackoverflow.com/a/9115498/378170

I have done like this:

1) removed all extra spaces from all .gitignore files contents;

2) re-do the proper commands again.

All working. So it was related with extra spaces.

Community
  • 1
  • 1
MEM
  • 30,529
  • 42
  • 121
  • 191
0

You probably commited the .gitignore file before you tried to remove the other files. So when you do git rm -r --cached you also remove the .gitignore file.

What you have to do to preserve the .gitignore file but delete the other ones is the following:

# Assuming you are in thumb/
git rm -r --cached .
git reset .gitignore
git add .
git commit -m "Remove wrongly tracked files"

And now it should work imo.

Sascha Wolf
  • 18,810
  • 4
  • 51
  • 73
  • I tried your commands. Didn't work. I still see the files. When I do `git status` after `git reset .gitignore` I don't see the .gitignore file listed. But, at that time, I have two lists provided by `git status` one list with status deleted, and another list with untracked status. After the `git reset .gitignore`, if I do: `git ls-files` I see the `.gitgnore` file and only that, listed. – MEM May 05 '14 at 16:04
  • @MEM You have to commit the changes. With `git rm -r --cached` you will remove the files but you have to commit the removal to make it permanent. – Sascha Wolf May 05 '14 at 17:56
  • @MEM after the commit the files won't be tracked anymore in your repository and .gitignore will work as expected. – Sascha Wolf May 05 '14 at 17:57
  • When I state that it didn't work, I tried all the commands. Included the git commit with the exactly same message and all. :) (I'm crazy). No dice. The comment verbose was only to tell you what happened in between. I will try again tomorrow. But absolutely no dice so far. – MEM May 05 '14 at 19:42
  • @MEM I can't actually imagine that it didn't work for you. If so and you still want us to help you, you will have to provide a [SSCCE](http://www.sscce.org/) like sleske already requested since nobody here seems to be able to reproduce. – Sascha Wolf May 06 '14 at 06:26
  • A SSCCE is useless. I have provide all the steps I've done and the behaviour. That should suffice, for someone who has, perhaps, stumble on the issue, or understands why this chain of commands results on such behavior. If, obviously, I recreate a new environment, the result will be different. While SSCCE is a nice thing, in this case, that's not useful. By other words, I don't understand why re-creating the environment (again, **on this specific case**) would help. – MEM May 06 '14 at 10:47
  • Because since now nobody was able to reproduce your result. The chain of commands you used aren't particular uncommon and result in the expected outcome in a fresh repository. So either you are doing something different than us or there are other influences we couldn't possibly know about which only you can analyse. – Sascha Wolf May 06 '14 at 11:13
  • @MEM if you prive us with a SSCCE it would be possible for us to analyse ourself where the problem lies. A fresh repository with your given chain of commands results, like I already said, in the expected outcome. – Sascha Wolf May 06 '14 at 11:14
  • 1
    Found the issue. It was related with an extra space on .gitignore file contents. I've removed all the spaces, and did the stuff again. It worked. :) Yupi. :) – MEM May 07 '14 at 12:14