I'm playing with pronto since done the line I wish to integrate it to my process.
I have followed the instruction on the Github page (at least I think so) but when I run pronto (with pronto-rubocop and pronto-spell) no messages are posted to Github even if I have several issues in the code.
You may check this test repo.
In the repo I have
a variable not in english
a couple of not camel cased classes
a misspelled commit message
Shouldn't pronto find this issues and post on Github?
After pushing my commit I execute pronto by running
GITHUB_ACCESS_TOKEN=xxx482cb9b577de5a216xxxxxxxxxxxxxxxxxxxx pronto
run -f github -c origin/master
The same happens when I run pronto locally pronto run: nothing is printed out.
Thanks
-c/--commit flag determines against which commit your current HEAD will be compared to. In your case, I don't see another branch besides master. You're probably running Pronto and comparing master against origin/master. That's very likely the same commit. You can observe it by:
git show HEAD
git show master
git show origin/master
To see some result in that repo, you can run Pronto like this (replaced origin/master with HEAD~5):
GITHUB_ACCESS_TOKEN=xxx482cb9b577de5a216xxxxxxxxxxxxxxxxxxxx pronto run -f github -c HEAD~5
Or alternatively, create another branch, make some bad commits, git push and run Pronto while being on that branch.
Related
I am not very familiar with git as I just use it in the most basic manner. Lately I've been running into this strange behavior which makes no sense to me and causes a huge disturbance in my productivity. For certain branches when I run git pull instead of just getting the latest commits from the remote repository like I expect, I get an ENORMOUS list of modified/deleted/added files as well as an enormous list of untracked files. The branch I am pulling from is our team's master branch. I am just trying to keep my local copy of master in sync. What are these other untracked files showing up as well as these modified files? I didn't touch any of these other files.
What makes the problem worse is that I can't delete these untracked files or anything. I've tried `git clean -fx' and it only removes 3-4 files but still leaves hundreds. At this point I just want to get rid of all of these files, delete the branch, and pull the branch from remote again.
I tried doing the following:
git fetch --all
git reset --hard origin/<remote_branch_name>
but I received an error because Git couldn't create a symbolic link. I am using Git on Windows.
Why is git pull doing this, and what should I do?
EDIT: I was finally able to run the git reset command when I ran my prompt as an admin, but it still doesn't explain this weird git pull behavior.
It seems to me that the 'git pull' action did not complete successfully.
It is possible that you modified some of the files as an admin, and when pulling as non-admin user git tries to modify or delete a file and has no permissions to it.
Therefore you stay in some half baked state.
What do you see when you run git status?
Is there any error in the git pull?
This question already has answers here:
How do I reset or revert a file to a specific revision?
(35 answers)
Closed 3 years ago.
Just a dumb question from just a newb in git, Messed up alot with git, but now I was wondering if how can I restore to a previous version in the application, since my .env environment configuration file is now gone in my current master branch, I did merge my other branch with this one. I knew I made my latest work on my chat-feature branch, pretty much the 100% of the application was there, since the chat part and the payment feature of the application was there but when I checkout there, its not even working, I was wondering how can I go back to that previous commit that I made. When I git log I want to be back to this specific version.
Restore + push --force
I don't like to recommend anything that requires --force but in your case it may be the cleanest solution. If you shared your code with others, don't follow this - you're changing history.
Let's make master be like chat-feature.
Make a copy of the repo (on your drive), just in case.
git checkout master
git checkout -b master_copy (optional, but let's store what we currently have in master as a new branch; this will make it easy to use it if rewind too much)
git checkout chat-feature
Check that this is what you want master to look like.
git log -n 1
Copy the commit id
git checkout master
git reset --hard <commit-id>
Double check that things work and that's what you want.
git push --force
I started using godep a while ago but I think I'm failing to understand the principal, and I may be using it incorrectly entirely.
I thought godep maintains _workspace in order to have a local copy of the packages in case some revisions/projects are removed or become unavailable. But godep restore doesn't seem to use _workspace at all.
Also, calling godep save for the second time didn't update _workspace, only Godeps.json.
What am I missing?
UPDATE:
To explain my question I changed one of the revisions in my Godeps.json to an invalid revision "1" and ran godep restore. Here's the error I got:
$GOPATH/bin/godep restore
# cd /home/iliga/gopath/src/github.com/jinzhu/gorm; git pull --ff-only
From https://github.com/jinzhu/gorm
a97a508..087b708 master -> origin/master
You are not currently on a branch. Please specify which
branch you want to merge with. See git-pull(1) for details.
git pull <remote> <branch>
# cd /home/iliga/gopath/src/github.com/jinzhu/gorm; git checkout 1
error: pathspec '1' did not match any file(s) known to git.
godep: restore: exit status 1
As explained above, I would expect there to be no error and for godep to simply copy the code from _workspace.
"godep restore" does not use _workspace. It reads Godeps.json and check out your dependencies to GOPATH.
To use _workspace, you run go command prefixed with godep, like "godep go build", "godep go test".
I installed Octopress in GitHub Pages.
And I clone the repository.
$ git clone git#github.com:my-name/my-name.github.io.git
$ git checkout source
And
$ rake setup_github_pages
I input my repository name.
And
$ rake gen_deploy
I got error
! [rejected] master -> master (non-fast-forward)
my solution
I resolve this problem, in GitHub delete my-name.github.io.git, and make same name repository and
$ rake gen_deploy
But I don't want to delete repository
What is the best solution?
Without deleting the repository
Please keep in mind this is not considered best practice, but it may work for you.
The solution is to force a push on the master branch.
Edit the Rakefile and look for this line:
system "git push origin #{deploy_branch}"
Alter the line by adding a plus (+) before the #{deploy_branch} tag:
system "git push origin +#{deploy_branch}"
Run the command
rake deploy
It should succeed.
Undo the edit you made to the Rakefile!
Idea for this solution came from reading this: https://stackoverflow.com/a/9629458/1369730
I have the same problem when hosting my Octopress blog on github pages. I Googled a lot and finally solved this problem.
Just change the directory.
cd octopress/_deploy
git pull origin master
cd ..
rake deploy
Then it's fixed.
Sometimes a git checkout command gives progress feedback:
$ git checkout develop
Checking out files: 100% (10779/10779), done.
Switched to branch 'develop'
Sometimes it doesn't, (very next command line, same repo context):
$ git checkout master
Switched to branch 'master'
It's not because the branches are equal, because switching back on the very next command shows this feedback:
$ git checkout develop
Checking out files: 47% (5067/10779), done.
Switched to branch 'develop'
This happens for small repos also. I have a repo with just 13 files in it and when I add a file in a branch and use checkout to switch back and forth, I get no feedback either way. Is it some kind of "this is taking a long time, start showing feedback" timer?
I searched (Google, Stackoverflow) but didn't find anything specific. I did find some patch documentation that shows the addition of a --verbose flag to checkout that forces feedback to always happen, but I couldn't find an explanation for why feedback only happens sometimes without that patch. The same notes pointed out that feedback only happens if isatty() returns true, but that's not relevant here, since all of the commands above were typed into the same bash window, which presumably isatty.
I'm using git version 1.8.1.msysgit.1 (downloaded from git-scm.com as 1.8.1.3), which does not have the --verbose patch as far as I can tell.
This checkout output should now be more consistent with Git 2.7 (Nov./Dec. 2015)
See commit 870ebdb (01 Nov 2015) by Edmundo Carmona Antoranz (eantoranz).
(Merged by Junio C Hamano -- gitster -- in commit 6a38bd6, 05 Nov 2015)
"git checkout" did not follow the usual "--[no-]progress" convention and implemented only "--quiet" that is essentially a superset of "--no-progress".
Extend the command to support the usual "--[no-]progress".
The git checkout doc now shows:
--[no-]progress::
Progress status is reported on the standard error stream by default when it is attached to a terminal, unless --quiet is specified.
This flag enables progress reporting even if not attached to a terminal, regardless of --quiet.
checkout: add --progress option
Under normal circumstances, and like other git commands, git checkout will write progress info to stderr if attached to a terminal.
This option allows progress to be forced even if not using a terminal.
Also, progress can be skipped if using option --no-progress.
Under normal conditions, you will see output when checking out if the operation's been running for more than one second.