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.
Related
When working with Gerrit (Code Review), I often need to get a copy of a given patch set for testing or validation purpose. The obvious and easiest way is to download the archive or the patch file through the Gerrit Web interface and manually apply it to my local source.
While the above steps are pretty straightforward and fulfill my needs, in the best world I would like to have the patch set appearing as a commit in my local Git.
I was looking around and didn't find the solution. I found some sparse info that once compiled together gives the following solution.
Say that you want to pull the patch set 2 of the Gerrit change 1222:
Find the remote refs we are interested in:
$ git ls-remote | grep 1220
From http://something.com:8081/MyProject
e2e0212a59240ac5cd7c11220c35542523f44b59 refs/changes/13/713/1
b8c4dceea5eaf1bad711b0ea6938c80ec932726a refs/changes/20/1220/1
6f20c182ec7f54a2aa9e8f6188a0eef1b0790df4 refs/changes/20/1220/2
ed94a98386d224ce3d86004ce99f61220905a077 refs/changes/22/1222/1
Pull the refs:
git pull origin refs/changes/20/1220/2
This will create a Git commit point that you could eventually rebase:
git rebase
This feature is standard in the Gerrit UI.
On the top right of the UI for a patch, click Download, and you will see something like:
When you are navigating the patches you go to the download section and copy the command line command for checking out the patch set, for example like this:
git fetch https://gerrit.googlesource.com/gerrit refs/changes/03/64403/2 && git checkout FETCH_HEAD
Then I normally create a branch with the review number and patchset as name
git checkout -b b64403-2
For here you can work normally and commit your changes or cherry-pick/rebase your changes on this change.
Once the review of r64403 is done your code can be merged or when there is another patchset submitted you will need to do the same thing again.
If you do not see the options to download the option to Checkout or Cherry Pick you need to edit the gerrit.config, something like this:
[download]
scheme = ssh
command = checkout
command = cherry_pick
More details can be found in the Gerrit Documentation
Update:
As barryku correctly points out, in the later version you need to download the downloads-commands plugin. This can be done during the initial setup or by using the following command:
java -jar gerrit-2.11.4.war init -d review_site --batch --install-plugin download-commands
Or you can use the -d option to git-review. For example, assuming you were working the with nova-docker repository and were interested in this change in gerrit:
https://review.openstack.org/#/c/148486/
You could download the latest patchset like this:
git review -d 148486
Or you can use the change id:
git review -d I35729a86e211391f67cc959d19416c9125c6f9eb
You can also request a specific revision of the patch by appending a comma and the patch number. E.g, to get the second revision of that patch:
git review -d 148486,2
I am not 100% sure what your question is. Sounds like you want to easy the workflow or typing. larsks mentioned already git review which is mostly used.
For your case, maybe it helps to download all ref's automatically so you can reference them directly. You can always all specified ref's like with
git fetch origin "+refs/changes/*:refs/remotes/origin/changes/*"
Then you can work locally with the commit id.
A simple git alias or scripting it for all refs can be easily done. An example of such a while loop can be found in the script on https://github.com/saper/gerrit-fetch-all With such a small shell snippet you can easily accomplish to skip one part of the ref id to easier reference them:
Server side: Client side:
refs/changes/13/713/1 refs/head/713/1
refs/changes/20/1220/1 refs/head/1220/1
refs/changes/20/1220/2 refs/head/1220/2
refs/changes/22/1222/1 refs/head/1222/1
As mentioned in the comments, you can just get the right git command from the gerrit GUI. If you really dislike GUIs, or you want to automate it (and for some reason can't use git-review), you can use the gerrit API:
curl -s 'https://<your gerrit server>/r/changes/<change id>?o=CURRENT_REVISION&o=DOWNLOAD_COMMANDS' | tail -n+2 | jq -r '.revisions[.current_revision].fetch["anonymous http"].commands.Pull' | bash -
or
git pull origin `curl -s 'https://<your gerrit server>/r/changes/<change id>?o=CURRENT_REVISION' | tail -n+2 | jq -r '.revisions[.current_revision].ref'`
I am experiencing an issue with pre-commit hooks in overcommit, which is configured to run rubocop and rails_best_practices.
In short, all three commands listed below passed but overcommit wouldn't let me commit to git. Any advice on why/how to circumvent this issue would be appreciated.
# These passed
rubocop -a
rails_best_practices .
overcommit --run
# Git commit failed
$ overcommit --run
Running pre-commit hooks
Analyze with RailsBestPractices..................[RailsBestPractices] OK
Analyze with RuboCop........................................[RuboCop] OK
✓ All pre-commit hooks passed
$ git commit -m 'Ensure lower case with Attr API'
Running pre-commit hooks
Analyze with RailsBestPractices..................[RailsBestPractices] FAILED
Errors on modified lines:
/Users/USER_NAME/projects/APP_NAME/app/models/lower_case_string.rb:2 - remove unused methods (LowerCaseString#cast)
Analyze with RuboCop........................................[RuboCop] FAILED
Errors on modified lines:
/Users/USER_NAME/projects/APP_NAME/app/models/lower_case_string.rb:3:3: C: Layout/IndentationWidth: Use 2 (not 0) spaces for indentation.
✗ One or more pre-commit hooks failed
Now, I read here that overcommit --run doesn't trigger the hooks in the same ways that it does when you actually try to commit (whole project vs only changes to be committed). However, I'm not sure how this would affect my case, especially since rubocop and rails_best_practices both passed individually as well. By the way, the errors raised here are both false alarms. rails_best_practices shouldn't be checking for unused methods in the first place, since that check has been turned off in config/rails_best_practices.yml.
After a few weeks of working with these gems, I think I've figured it out. I'll leave some pointers here for anyone who encounters similar issues.
1. Stage your changes before doing overcommit --run with git add
<file>
As this comment and docs say, the --run command does not check untracked files.
2. Add gemfile option to .overcommit.yml
One issue I had was that overcommit was failing to read my config/rails_best_practices.yml (it wasn't supposed to be checking for unused methods in the first place, since that check was turned off in the config file).
It seems that when I was trying to git commit, overcommit was using gems installed in my system (not in the Gemfile), and as a result somehow failing to read my config file. So I added the gemfile option as recommended in the docs, and made sure overcommit uses the Gemfile/bundler version. I haven't gotten the subject error ever since. As the docs say:
If you are using Bundler to manage your Ruby gem dependencies, you'll likely want to use the gemfile option to control which gem versions are available during your hook runs.
My .overcommit.yml file for reference:
gemfile: Gemfile
PreCommit:
RuboCop:
enabled: true
on_warn: fail
RailsBestPractices:
enabled: true
on_warn: fail
command: ['bundle', 'exec', 'rails_best_practices', '-c', 'config/rails_best_practices.yml']
As a side note - I haven't tried this, but apparently you can also create a separate Gemfile just for overcommit purposes, if you feel that loading your original Gemfile slows down the hook execution (docs).
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