Part of my .gitignore looks like below:
## Ignore logs
/log/
/log/development.log
Yet development.log is always in modified files when commiting.
I tried to remove --cached and remove file altogether. No luck.
Also I have recently pushed it to remote (by mistake).
Any idea how to solve that bugger once and for all?
Try
log/*
(without leading slash)
And probably
git rm --cached log/development.log
to remove the file from index.
You may also check this question How to make Git "forget" about a file that was tracked but is now in .gitignore? to remove accidentally commited log file.
Related
I messed up so I downloaded an old commit and tried to build from some old code that functioned as intended. I see the files (Podfile, License Gemfile etc) now have a .exec extension and when I push to bitBucket they have a "+x" annotation. When you hover over it says this file is now executable.
Everything still happens to build and run successfully but why does git add this extension to my files without my say so? This issue is causing some concern on my pull request. How do I return my files to being just plainText or whatever they were originally?
I've tried to run chmod -x $(find . -type exec) in the offending directory but this doesn't seem to work.
Anyone know how restore my file to their former purity???
You could:
rename your files
add them again, explicitely removing the 'x' executable bit with git add --chmod=-x aFile
Then you can commit and push again.
But make sure to use Git 2.31 (Q1 2021), because of various fixes on "git add --chmod"(man)".
See commit 9ebd7fe, commit 4896089, commit c937d70 (22 Feb 2021) by Matheus Tavares (matheustavares).
(Merged by Junio C Hamano -- gitster -- in commit f277234, 25 Feb 2021)
add: propagate --chmod errors to exit status
Signed-off-by: Matheus Tavares
Reviewed-by: Taylor Blau
If add encounters an error while applying the --chmod changes, it prints a message to stderr, but exits with a success code.
This might have been an oversight, as the command does exit with a non-zero code in other situations where it cannot (or refuses to) update all of the requested paths (e.g. when some of the given paths are ignored).
So make the exit behavior more consistent by also propagating --chmod errors to the exit status.
And:
add --chmod: don't update index when --dry-run is used
Helped-by: Junio C Hamano
Signed-off-by: Matheus Tavares
Reviewed-by: Taylor Blau
git add --chmod(man) applies the mode changes even when --dry-run is used.
Fix that and add some tests for this option combination.
I am a new solo developer working on my first iOS app. I'm using Git for Mac to backup my progress and it's my first time using Git.
I'm developing the app across 2 laptops.
I also saved my Xcode project in my iCloud folder so that they would be synchronized across both macs.
Everything was working fine for the first 2 months, but I've come across this error on Git for Mac and I can no longer sync to Git nor revert to an older commit.
This is the error:
fatal: Reference has invalid format: 'refs/stash 2' (128)
My guess is that an iCloud synchronization error happened between my macs and that messed up Git.
All I would like to do is be able to fix git so that I can recover my last working commit and then I will remove my project from iCloud to prevent this error from happening again.
Any help you can provide would be greatly appreciated!
View the tree which is under your .git folder:
tree .git and check to see if you actually have this ref in your git filesystem.
If you want to reset your data (if you can) do git reset HEAD --hard it will reset your current branch to the latest commit.
Some other solutions you can try as well
Make a backup of your repository since the following commands are irreversible.
Search for the conflicted files and delete them
find . -type f -name "* conflicted copy*" -exec rm -f {} \;
lastly, remove any "conflicted" references from git's packed-refs file
awk '!/conflicted/' .git/packed-refs > temp && mv temp .git/packed-refs
Also take a look here (where the conflicts file may be in):
.git/logs/refs/remotes/origin/
.git/logs/refs/heads/
.git/refs/remotes/origin/
.git/refs/heads/
Hope it will help you fix the problem.
I was trying to solve an issue with some gem conflicts, and I added all of my gems to vendor/cache, I have since removed them, but now I have a 40M pack file where it used to be less than 1M.
I have tried to filter the branch
git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch vendor/cache' --prune-empty -- --all
This goes through a list of rm commands, for example:
rm 'vendor/cache/sass-3.2.8.gem'
and then at the end
Rewrite 9c90286ba515f46919e82e73e2c01a5db1762668 (202/202)
Ref 'refs/heads/master' was rewritten
Ref 'refs/remotes/origin/master' was rewritten
WARNING: Ref 'refs/remotes/origin/master' is unchanged
Finally I run
git gc --aggressive --expire=now
But I still have the same huge number of objects, and the pack file is still 40M. I even try forcing a push when this was complete with no change. Any idea how I can clean up my repository following this mistake?
I think you'll find the answer at the bottom of the question or in the accepted answer here:
Remove file from git repository (history)
The key is in that warning line you have:
WARNING: Ref 'refs/remotes/origin/master' is unchanged
The solution discusses how to get rid of that so that the other steps accomplish what you want and reduce the size back down.
I am using Ruby on Rails, the Capistrano gem and git. I would like to do not put anymore under version control some directories that until now I was tracking.
For my application I have a file system structure like the following:
...
.gitignore
/public/aaa/000/001
/public/aaa/000/002
/public/aaa/000/003
/public/aaa/000/...
To accomplish that I aim, I changed the .gitignore file and added to it the following lines:
# Ignoring "/public/aaa/*" directories
public/aaa/
However, if I check what directories are under version control, I see that those I would like to ignore are still tracked. So, when I deploy with Capistrano to the remote server the content of those directories is still changing.
How can I definitely ignore those directories?
In few words, what I would like to do is to do not change public/aaa directories and files on the remote machine (and, thus, to do not track those with git on my local machine) so that when I deploy with Capistrano those folders (on the remote machine) are untouched.
You'll need to remove them before they'll disappear from source control. They're still part of your git repo, so git is going to continue paying attention to them.
git rm -r --cached public/aaa
The -r tells git to remove the directory (just like rm -r in the console) and --cached tells git to leave the file(s), just remove it from the repo.
You could use git update-index --assume-unchanged <filename>. This will keep the files around, but will no longer track their changes.
You can do this recursively with
find ./folder/ -type f | xargs git update-index --assume-unchanged
I accidentally unpacked a gem (paperclip) in my root folder. Now I can't get rid of it to save my life. I add it, remove, add it, stash it, try to check it out...nothing works. I know I'm not providing much detail, but has anyone run into this issue before? Rails env is 2.3.11.
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# paperclip-2.3.16/
nothing added to commit but untracked files present (use "git add" to track)
Try to do:
git rm -r --cached paperclip-2.3.16/*
You could also throw a -f on there before the --cached if you want, to try to force it.
I'm referring to this source:
http://www.kernel.org/pub/software/scm/git/docs/git-rm.html
Since is not tracked yet, you can just do a rm -rf paperclip-2.3.16 and it should remove it with no problems.