I am using git for the first time and I am trying to make a commit. I want to ignore all .project and .settings files so I went to my .gitignore file and added .project, .settings and saved. When I did that the .settings file doesn't appear anymore, however, I still see my .project file when I do git -status. Also, why is the .xml and java file in a different section that the .jar files:
Your git status output is showing you two types of files:
Changes not staged for commit
These are files which Git is tracking, and these files have been modified since the previous commit. But, the changes have not yet been staged. Unless you stage the changes using git add, they will not be committed. Here is how you would stage the change to the web.xml file:
git add path/to/web.xml
Assuming you really just started working, then the most likely explanation for why the .project is showing up as being tracked by Git is that you somehow added it. To fix this, you can try using:
git rm --cached .project
This removes the .project file from being tracked by Git. It would also remove it from the remote repository, but since you just started working and haven't pushed yet, this is a moot point.
Untracked files
These are files which Git is completely ignoring. From Git's point of view, these files are not there. I can see that you have a number of JAR files listed as untracked, which is probably a good thing, since in general it is a bad idea to add binary files, especially dependencies, to your Git repository. Should you see a source file listed as untracked, you could also run git add to add that file to Git.
The reason it is generally considered bad practice to add binaries to a Git repository is that Git doesn't handle diffs of binaries very well. Suppose you add a 1MB JAR file. Each time it changes, which could be fairly often if you are doing some open source stuff, a diff has to be stored for that binary. But, Git often will interpret the diff as being deleting the old file and replacing it with the entire contents of the new file. In other words, Git basically versions the entire binary for each change. Over time, this can cause your repository to become large and bloated, and it can be difficult to get rid of those binaries from your history. So, unless absolutely necessary, avoid storing binaries in your Git repository.
Related
We are five students in a team and we must work in the same project using git.
What i did is:
create an empty project
add gitignore file
The gitignore file
contains:
*.class
nbproject/private/
build/
nbbuild/
dist/
nbdist/
nbactions.xml
nb-configuration.xml
git init
git add .
git commit -m "Initial commit"
set up the remote and push
But we have a conflict in nbproject/private/private.properties file.
This file contains:
user.properties.file=C:\\Users\\Houssem\\AppData\\Roaming\\NetBeans\\8.2\\build.properties
user.properties.file=C:\\Users\\ASUS\\AppData\\Roaming\\NetBeans\\8.2\\build.properties
One of us he had cloned the repository and he can't add any java class in his local project.
You have confirmed in a comment that the output of git ls-files | grep nbproject/private/ contains line.nbproject/private/private.properties.
That means the file line.nbproject/private/private.properties is part of the repository.
You need to remove the file with git rm line.nbproject/private/private.properties,
and then commit the changes.
After that none of your collaborators should get any conflicts on this file.
Having nbproject/private/ in the .gitignore file should normally prevent line.nbproject/private/private.properties from getting added to the repository.
But it's possible that the file was added to the repository before .gitignore was created,
or that one of the collaborators force-added it (git add -f ...).
If possible, you might want to set up NetBeans to keep the project workspace (I believe this is called "Project" in NetBeans) outside of the actual repository and code, since this contains absolute references and (I'm assuming here) personal preferences.
I have no experience with NetBeans, but in Eclipse this works just fine.
Keeping the workspace files separate should also allow each developer to use an editor of his or her choice instead of being locked to one.
I'm working on a group project for my software engineering course, and my professor has indicated that I set up the directory structure incorrectly on Github. I'd like to correct the issue now to avoid a grade penalty, but I'm very new to using Git. Basically we have a structure that is as follows on Github.
src
--main
----java
------Source Files
--test
-----java
------Test Files
Various Ivy/Ant build files
.classpath
.gitignore
.git
.project
README.md
I need to create a new directory called CodeComp that will contain the directory structure above except for the README.md, which should be on the same level as the CodeComp directory.
Since our grade is dependent on the commit history, this would need to be preserved. Is there an easy way to do this or are we better off just taking the small deduction on the final project grade?
UPDATE:
In case anyone else has to do this in the future:
Go to the folder holding the project and create the new directory.
Move all files needed into the new directory except .* files. Refresh Eclipse.
Commit and Push the directory changes to the repo regardless of Eclipse errors.
Manually delete the .classpath, .gitignore, and .project files from the repository.
Back-up your .classpath and .gitignore files. Delete your local copy of the repo and re-clone it.
Import the Git project and choose to put the project files in your newly created directory.
Copy the .classpath and .gitignore you backed up into the new project directory. Push the changes.
In theory you should be able to use a standard file browser to move everything but your .git and Readme file into your new sub-folder and then commit that.
The git history will still there but it may see it as two separate files, one that has been deleted and one that is just created. In my experience Git doesn't really like moving files.
In any case, you commit history will still be in the repository, it will just be 2 separate sections from when you moved the files.
But, hey... It may pay to show that move anyway. I know for sure that I was moving files all around when I first learnt about version control. It's all learning.
EDIT: You can test this by committing the change locally and checking the history before you push it upstream to Github.
I changed some settings in my config file which I don't want to push to the remote repository.
I want it to effect only one project locally.
I saw there are few ways to do so:
http://365git.tumblr.com/post/519016351/three-ways-of-excluding-files (1)
Per Computer: through settings in ~/.gitconfig
git update-index --assume-unchanged (2)
I'm using SourceTree and only when I use option (2) I see the files are vanished from the UI.
What is the difference between (1) and (2) ?
Does it really means that the files are not ignored when I see them in the SourceTree after using option (1) ?
The .gitignore file prevents files from showing up as files to be added to the repository. If the file is already in the repo when it is added to the .gitignore file, any changes to the file will be shown by git and can be committed. The .gitignore settings only affect new files that are in the repos path. You would use this for keeping temp files created by you IDE or compile files from showing up and cluttering your list of files that you modified when you do git status.
git update-index --assume-unchanged doesn't show that a file was changed at all. If you make any modifications to the file, git won't show that it has been modified in git status. You would use this with config files for users. When the repository gets cloned they need to have the file but there may be some changes that they need so that they can use the code (i.e. change a file path for their local machine). But you don't want them to accidentally commit the file and mess up things for others when they pull in the changes.
For changes to a config file, you want to use the git update-index option. You want the config file in the repo but you don't want to commit the changes to it.
I'm collaborating on an android app development using GitHub and I'm using eclipse adt bundle for the development. The problem is, git does not detect any new files which I add to the repo in the res or drawable folder although it is detecting any changes I make to the existing Java or xml code. It detects any new Java files I create but it does not detect any new xml file or any new png files which I put in the layout or drawable folder.
I've shown my gitignore file to my project manager and other colleagues and they said it has no error, the problem is local.
Use
git check-ignore -n -v <file>
To see if the file has been explicitly configured to be ignored by Git.
If that prints out something .gitignore:XX, then you know the line number of the Rule in the .gitignore file that is causing the problem.
Typically, .gitignore is used to exclude build output like *.o, but it may also be excluding binary objects, or anything else.
How to 'fix' the problem depends on your particular situation. You can have a .gitignore file in each directory of your project. In some cases you might want to remove a rule from the root .gitignore file, but in others you might want to create a lower level .gitignore and undo an earlier rule for just one particular directory.
The Git Docs have a pretty good description of it along with examples
There's another option beside gitignore to check files which is at .git/info/exclude .Check it please.
I have a local SVN folder which has many files/directories/sub-directories
One of them is Project-Ear, which contains generated folders/files that I do not wish to check-in at all..
I have marked this Project-Ear folder as "unversion and add to ignore list"
Now every time, I do SVN Commit, this folder Project-Ear and it's files show in the Commit dialog.
How do I fix this? I do not want this Project-Ear to be shown at all.
If the files were initially committed into the repo, you will need to commit the "un-version" part, at that point they will be removed from the repo, and ignored from then on local file systems.