After the old project introduced eslint husky lint-staged, executing git commit will scan the whole, one is too slow, and the other old code does not dare to change easily, thinking about only detecting the files changed by commit this time , how to configure
configure eslint --cache --fix
Related
I am getting this instruction on the terminal "npm notice created a lockfile as package-lock.json. You should commit this file." after I tried solving the EAUDITNOLOCK error.
Please help me with an step by step resolution.
Thanks!
To tell git to track the file you would use git add package-lock.json
To then commit it to git commit -m "Adding package lock"
As with any npm based project in git you will want to make sure your .gitingore file contains at the very minimum the following
# Don't commit npm node_module directory
node_modules
If you don't have a .gitignore file, then you will want to create one. For more information on gitignore please see the docs
The pacakge-lock.json itself has benefit described in the npm documentation while boils down to specifically locking your dependencies to exact versions given that your pacakge.json can define version ranges. This helps with debugging and keeping things stable overtime. Committing this file mean that you can always go to previous commit and have your environment setup exactly as it was and others can have your identical environment when they checkout your git repo.
Hi, I'm making a Spring project now with STS and Git.
However, whenever I try to do Git Push,
I discover that pom.properties file that I've never worked on is always automatically modified.
1.
So I always ignore it by Git Stash clear or Git Reset.
Is it a smart action?
2.
By the way, what is the purpose of pom.properties file?
I've tried to find the answer on the net, but I couldn't.
Spring help guide also doesn't give me the answer.
I'd be happy if I can get your answer.
As seen in "Version Informations Into Your Apps With Maven", this file would be used to show a version information in a kind of About Dialog or may be on command line as well.
That file is created by an archive step.
If you wanted to ignore it, you could do:
git rm --cached pom.properties
echo pom.properties>>.gitignore
git add .gitignore
git commit -m "Ignore pom.properties"
git push
That way, the file would still be generated/modified, but would no longer be tracked by your Git repository.
As commented by Ralph, the all target folder should not be in Git (since it can be rebuilt every time)
git rm -r --cached target
echo target/>>.gitginore
git add .gitignore
git commit -m "Ignore target folder"
git push
I have a few Cocoapods installed for my project. For one particular pod, KVNProgress, Xcode doesn't commit it to GitHub. Each time I check my project out I get 'can't find KVNProgress.h' blah blah...
So I run 'pod update' from terminal and immediately all is fixed.
After running 'pod update', I check my project navigator and there are no 'A' or 'M' or anything else for that matter indicated a new or modified file. Therefor nothing to commit.
Any ideas how to fix this so I don't have to update the pods each time I check out the project?
You should use the Terminal to figure out if it's an Xcode problem or a git problem.
Run git status --ignored in the project directory. If the Pods directory is shown in the Ignored files section you have to remove Pods from your .gitignore file.
If the files appear in the untracked files section Xcode messed up the git status.
You can use git add . to add all untracked files.
As a side note, I would recommend to use a dedicated git client like SourceTree, GitHub Mac, or Tower instead of Xcode. Xcodes git implementation is not the best (feature wise) and it's a bit buggy.
I have an Xcode project that uses git for version control. I have a .gitignore file to ignore the build subdirectory:
build/*
I recently added a subdirectory that contains an Xcode project and forgot to update the .gitignore file before checking it in.
Is there any way to make git ignore the build subdirctory now, after the fact?
Thanks,
Doug
git rm --cached dirToignore
echo dirToignore >>.gitignore
From there, a new commit will record that:
dirToignore is no longer par of versioned data
dirToIgnore won't show up anymore in git status
See this SO question for similar advices.
If you want to amend previous commit in order to remove said subdirectory from an old commit, see this SO question:
git commit --amend
can help you remove it from at least the last commit.
I have recently decided to take the git plunge, and am really enjoying using git, even on Windows.
My current open source project lives on subversion, all devs are familiar with subversion so I would like to keep subversion as the "source of truth" for now.
Nonetheless, I want to use git, so I went ahead and created a copy of the source on github using git svn. All my work is done against the source in github and I push my changes to github. Once every few days I also push my changes to svn and rebase.
The initial import seemed to go ok, but now every time I do a "git svn rebase" I keep on getting conflicts, even on files I have not changed in my get repository. This is causing me much pain.
Eg.
$ git svn rebase
First, rewinding head to replay your work on top of it...
Applying: Added git ignore file
c:/Users/sam/Desktop/MediaBrowserGit/trunk/.git/rebase-apply/patch:12: trailing
whitespace.
*/obj/*
error: .gitignore: already exists in index
Using index info to reconstruct a base tree...
:12: trailing whitespace.
*/obj/*
warning: 1 line adds whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging .gitignore
CONFLICT (add/add): Merge conflict in .gitignore
Failed to merge in the changes.
Patch failed at 0001 Added git ignore file
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
rebase refs/remotes/git-svn: command returned error: 1
My questions:
Is there any way I can tell git to sync itself up with svn using svn as the source, so I can start with a clean slate. (export latest, check in changes and reset the svn refs somewhere)
Are there any tips and tricks to getting this scenario to work consistently?
Should I have the core.safecrlf and core.autocrlf options set to true? It seems I will need a bit of hoop jumping.
Related:
http://kerneltrap.org/index.php?q=mailarchive/git/2008/4/16/1450834/thread
http://markmail.org/message/vaois4kkr5ggugqs#query:git%20crlf+page:1+mid:i4flex6vmt5tdala+state:results
http://code.google.com/p/msysgit/issues/detail?id=271
It seems getting line endings right is a bit of a black art.
(I realize that this question probably needs to be expanded, please comment on the places that need expanding)
Are you getting line-ending conflicts? Git has a few configuration properties you can set that change how it handles the end of line characters. I have the following set:
# this makes git NOT attempt to convert line endings on commit and checkout
core.autocrlf=false
# this makes git check if the conversion done by autocrlf would be reversible
# this is probably not required because I do not have autocrlf turned on
core.safecrlf=true
Note that I am on windows, all my coworkers are on windows and I am interfacing with SVN through git-svn. These settings seem to do the trick for me.
(source: codinghorror.com)