I have project in eclipse. I was developing it. Everything was fine. I use git to commit changes.
But starting from some point I noticed that not all files in git repository are committed.
When I do commit, git just do not show it under list of available files. I have tried to commit each file - no result, tried "add to index" - no result.
Does somebody know what can be the reason? I have such problem first time.
And no tracking symbol ">" appears.
In order to see if there is an issue with a .gitignore, switch back to the command line, and type:
git check-ignore -v -- yourFile
You will immediately see if one of the .gitignore rules applies to it or not.
Related
I have a requirement to have a property configuration for different environment like dev, uat and production. For example a config.properties having and entry like environment=dev, this I need to change for staging branch as environment=uat and for master branch as environment=prd .
I tried to commit these files in each branch respectively and tried adding config.properties in gitignore so that it will not consider in next commits.
But git ignore not getting updated so I ran command
git rm -rf --cached src/config.properties
git add src/config.properties
git commit -m ".gitignore fix"
But this command is deleting the file from local repository itself and the proceeding commits also deleting from branches. I want to handle the branch as such so as Jenkins will do the deployment without editing config file manually. I am using fork for git UI. Is there any way to handle this kind of situation?
You should not version a config.properties (git rm is right), and ignore it indeed.
That way, it won't pose any issue during merge.
It is easier to have three separate files, one per environment:
config.properties.dev
config.properties.uat
config.properties.prd
In each branch, you would then generate config.properties, with the right value in it, from one of those files, depending on the current execution environment.
Since you have separate branches per environment, with the right file in it, you can have a generation script which will determine the name of the checked out branch with:
branch=$(git rev-parse --symbolic --abbrev-ref HEAD)
That means you could:
version only a template file config.properties.<env>
version value files named after the branches: config.properties.dev, config.properties.uat...: since they are different, there is no merge issue when merging or switching branches.
Finally, you would register (in a .gitattributes declaration) a content filter driver.
(image from "Customizing Git - Git Attributes", from "Pro Git book")
The smudge script, associated to the template file (package.json.tpl), would generate (automatically, on git checkout) the actual config.properties file by looking values in the right config.properties.<env> value file.
The generated actual config.properties file remains ignored (by the .gitignore).
See a complete example at "git smudge/clean filter between branches".
When i change something in my repository.I see some "Unstaged Changes" in Eclipse, but when i use git at the same time, it tells me that there is no any updates in my repository.
Why is that?
Should i change or configure something to see changes at the same time?
Or it's something normal?
It happens to me many times,
apparently there is a bug on git client in Eclipse
What do i do, and helped me:
Try to stage the files and then unstage them via Eclipse
after that those files disappear form the unstaged area in Eclipse.
This can happen if any of the files are inadvertently checked in with a character case inconsistencies in the path.
You might need to do something like:
git mv Path/file.c path/file.c
I've just installed IntelliJ IDEA with git and pulled down code from the framework. Immediately after doing this, I get hundreds (out of thousands) of files saying that 'contents have differences only in line separators'. If I change these from CRLF to LF it makes no difference. Any idea how to fix this?
One possible reason may be change of line separator style after your checkout, and a missed git reset after that. For example, if you change global config "core.autocrlf" or ".gitattributes" file, you may need to reset git index.
Backup your changes and execute those commands at the root of git repository to reset git index:
rm .git/index
git reset
I am working on a Java project in Intellij that uses git. Quite a few files are blue (to show that changes have been made), however when I right click them and click on "Git -> Compare with Latest Repository Version" it says that the contents are identical. Anyone know why this happens? It only seems to happen to files that I've opened to look at but haven't changed. Could it happen if I accidentally added extra white space and then deleted it or something? Or just extra whitespace in general?
This is how GIT is different from SVN. GIT's change detection algorithm does not depend only on the content of the file but the meta data (timestamp last modified, etc) of the file as well. So even if you are adding just one space and removing it later on; if you save it, it modifies the metadata of the file.
For more details, you can have a look at: What algorithm does git use to detect changes on your working tree?
One of the great things about using an IDE for Java is the automated refactorings you get. The problem I'm having is that after using Refactor > Move to move a class into a different package (which moves the file itself in the filesystem), git status shows that the file in the old location has been deleted, and the one in the new location has been added.
The workaround I've found is clunky:
mv src/com/example/newpackage/Foo.java src/com/example/oldpackage/Foo.java
git mv src/com/example/oldpackage/Foo.java src/com/example/newpackage/Foo.java
Is there any way (when using the Git plugin for Eclipse) to have the refactoring do a git mv instead of a naive filesystem move?
That's the way how Git works with renames/moves (delete old file and add new file). It then detects the contents of the file, and recognizes a rename based on an algorithm. So even it shows you delete and add, if you commit and then do a "git log --follow movedfilename", it should show you the whole history, even the history before the rename.