Skip to content
This repository was archived by the owner on Jan 26, 2023. It is now read-only.

Remove repeat instances of .classpath from .gitignore and remove and ignore sysProps.xml - #4

Open
LoadingPleaseWait wants to merge 1 commit into
discobots2587:masterfrom
LoadingPleaseWait:master
Open

Remove repeat instances of .classpath from .gitignore and remove and ignore sysProps.xml#4
LoadingPleaseWait wants to merge 1 commit into
discobots2587:masterfrom
LoadingPleaseWait:master

Conversation

@LoadingPleaseWait

Copy link
Copy Markdown

So, I know what you're thinking but this pull request is legit. 😄 I found that were three lines in your .gitignore file that do the exact same thing: ignore .classpath. I removed two of those lines to remove clutter in .gitignore. Now, about sysProps.xml. sysProps.xml is created when you build the project. It is seen by git as a binary file so git isn't very good at tracking changes in the file. The file doesn't need to be in the repository because you can still open the project in Eclipse, compile the source code and deploy the program to the robot without that file. In other words, the file serves no purpose in the repository. You can find examples of other teams that have ignored sysProps.xml here, here and here.
As for .classpath, it would be a valid decision to take it out of the repository because users who clone the repository can just create the Eclipse project themselves but it's also valid to keep the file in the repository because it may help users open the project in Eclipse with less hassle. Right now though, the file is in the GitHub repository and being tracked by git. The .gitignore file prevents files from accidentally being added to the repository but the .classpath file has already been added into the repository. It looks like you guys want to prevent changes in .classpath from getting uploaded to the GitHub repository so you have a few options. An easy option would be to just remove .classpath from the repository. The .gitignore file will prevent it from being tracked by git when Eclipse creates the .classpath file again although this may mean you'll have to set up the Eclipse project again. You can also just keep the .classpath file in the repository and just prevent it from changing in future commits. After a quick glance at the git history of the file, it looks like the file has been changing due to people using different versions of JDK 1.8. This could be solved easily by getting everyone to update Java. If everyone has the most recent release of Java then the .classpath will be the same for everyone. A third option would be to get people to run the command git update-index --assume-unchanged .classpath.
I would also recommend looking at OpenRIO's .gitignore template as there are other files ignored in the template that you guys might want to include in your .gitignore.

@mason2smart

Copy link
Copy Markdown
Contributor

Please let the code be. We know what we are doing. My version of eclipse
and github are mapped to my flashdrive and are this portable w/ plugins and
Java on USB as well but does not like the gitignore.

On Friday, February 19, 2016, Michael Murphey <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

So, I know what you're thinking but this pull request is legit. [image:
😄] I found that were three lines in your .gitignore file that do
the exact same thing: ignore .classpath. I removed two of those lines to
remove clutter in .gitignore. Now, about sysProps.xml. sysProps.xml is
created when you build the project. It is seen by git as a binary file so
git isn't very good at tracking changes in the file. The file doesn't
need to be in the repository
because you can still open the project in
Eclipse, compile the source code and deploy the program to the robot
without that file. In other words, the file serves no purpose in the
repository. You can find examples of other teams that have ignored
sysProps.xml here
https://github.com/Open-%20RIO/.gitignore/blob/master/.gitignore, here
https://github.com/frc2879/2015-eva/blob/master/.gitignore and here
https://github.com/FRC5333/2015-Edu/blob/master/.gitignore.
As for .classpath, it would be a valid decision to take it out of the
repository because users who clone the repository can just create the
Eclipse project themselves but it's also valid to keep the file in the
repository because it may help users open the project in Eclipse with less
hassle. Right now though, the file is in the GitHub repository and being
tracked by git. The .gitignore file prevents files from accidentally
being added to the repository but the .classpath file has already been
added into the repository. It looks like you guys want to prevent changes
in .classpath from getting uploaded to the GitHub repository so you have
a few options. An easy option would be to just remove .classpath from the
repository. The .gitignore file will prevent it from being tracked by git
when Eclipse creates the .classpath file again although this may mean
you'll have to set up the Eclipse project a gain. You can also just keep
the .classpath file in the repository and just prevent it from changing
in future commits. After a quick glance at the git history of the file, it
looks like the file has been changing due to people using different
versions of JDK 1.8. This could be solved easily by getting everyone to
update Java. If everyone has the most recent release of Java then the
.classpath will be the same for everyone. A third option would be to get
people to run the command git update-index --assume-unchanged .classpath.
I would also recommend looking at OpenRIO's .gitignore template
https://github.com/Open-RIO/.gitignore as there are other files ignored

in the template that you guys might want to include in your .gitignore.

You can view, comment on, or merge this pull request online at:

#4
Commit Summary

  • Remove repeat instances of .classpath from .gitignore and remove and
    ignore sysProps.xml

File Changes

Patch Links:


Reply to this email directly or view it on GitHub
#4.

Mason

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants