I talk about untracked *.so (unzipped by jme when running)
Untracked files:
(use "git add <file>..." to include in what will be committed)
build/
liblwjgl64.so
libopenal64.so
sdk/jme3-project-baselibs/src/com/jme3/gde/project/baselibs/jme3-android.xml
sdk/jme3-project-baselibs/src/com/jme3/gde/project/baselibs/jme3-bullet.xml
sdk/jme3-project-baselibs/src/com/jme3/gde/project/baselibs/jme3-ios.xml
sdk/jme3-project-baselibs/src/com/jme3/gde/project/baselibs/jme3-jogl.xml
sdk/jme3-scenecomposer/nbproject/private/
sdk/nbproject/private/
no changes added to commit (use "git add" and/or "git commit -a")
no changes added to commit (use “git add” and/or “git commit -a”)
[/code]
idk where that build folder is from but it should probably be ignored altogether, yeah. Might be its a leftover from the recent attempts to get the native packaging work without actually building the binaries (what I mentioned above).
Or do you talk about the binary files when running the engine itself, like what the engine unpacks when running the examples? For me, they are called .dylib in that case ^^ Obviously you can ignore them but somebody has to come across this and actually put them on the ignore list, again we just recently moved to git and gradle.
The nbproject/private folder(s) can be ignored as well, but these get created depending on which module you run the SDK from, so not all of these are in the ignore list. The xml files are updated by the build script as I mentioned, this updating was also added recently. Generally the gradle build is a WIP, with native bullet building and other things on the list to be fixed.
I hope this information helps you to cope with whatever problems you have with these circumstances.
I run the SDK for netbeans, then open SceneComposer and run my project from the SDK (I already ignore *.so in my project).
I imagine the *.so at root come from running SceneComposer.
I’m currently out of job, and try to start as indie gamedev. So I’m ok to contribute to jmonkeyengine, (I need to remember java (I did scala since 6 years) and netbeans (I created some game asset viewer in 2008, nothing since).
@david.bernard.31 said:
I imagine the *.so at root come from running SceneComposer.
Nah, it should create these in the build folder of the SDK (or the module you run), in the temporary user folder. Each module and the SDK have their own, thats why I mostly run the main SDK project to keep the user settings until the next clean&build.
I'm currently out of job, and try to start as indie gamedev. So I'm ok to contribute to jmonkeyengine, (I need to remember java (I did scala since 6 years) and netbeans (I created some game asset viewer in 2008, nothing since).
Awesome, the github issues list is imported from google and not fully cleaned up yet but I think it contains most planned improvements. For the SDK theres also this infamous thread that contains most info on what the current development areas for the SDK are: http://hub.jmonkeyengine.org/forum/topic/improving-scene-composer/ Be warned, if you expect a detailed timeline with predefined class names an UML charts you will be disappointed ;)
I can PR on .gitignore to help improve ?
Sure, as you see its relatively obvious which files are just not on the ignore list yet so keep them pulls coming :)
I like to have ‘git status’ empty when there are no pending changes.
“filtering” with eyes on a the list of modification is error prone.
Those changes are noisy (long list where I have to search for my real change).
In the IDE you can just list these files, right-click them and ignore them locally. Generally I do commits manually and never get to see the other changed files, I guess thats why these don’t bother me at all.
In fact it’s a back partice to ignore tracked files,
it’s the cause of this noise, and other issue like ‘it work on my desktop, I don’t know why you have this issue’.
“git update-index --assume-unchanged” is just a less worse workaround than local gitignore (IMHO)
gitignore should be shared by all the team member.
I manage files with IDE, editor, command line (git), gitg, github,… so I like to have the “view” in every tools.
@david.bernard.31 said:
In fact it's a back partice to ignore tracked files,
it's the cause of this noise, and other issue like 'it work on my desktop, I don't know why you have this issue'.
“git update-index --assume-unchanged” is just a less worse workaround than local gitignore (IMHO)
gitignore should be shared by all the team member.
I manage files with IDE, editor, command line (git), gitg, github,… so I like to have the “view” in every tools.
yes lot of branches, my working branch + dedicated branch for PR where I cherry-prick from working branch.
and an other issue : thoses, tracked but un-commited noisy, files prevent branch switching.
isn’t that what stashing is for? I mean theres loads of files that could be changed and still should not be committed just because you do development. E.g. build options etc.
Stashing is to store “unfinished” change in a temporary zone.
Those files have nothing related to “unfinished” change, those files are modified by build and IDE.
About build options :
if it’s dev specific then it should not be track (user’s preferences)
if it’s temporary, eg enable debug options, the modification is reverted before commit.
if it’s common to the team, it should be tracked and committed to keep team members sync it’s part of the source.
Often IDE’s config files are ignored (and not tracked) and they can be generated by build tool or via IDE plugin for the build tool. In our case (IDE’s plugins), it may not be possible. In this case, the files should be committed when there are change (like version modification 3.0.10 or 3.1.x).
we’d have to maintain a third set of user settings on the build server
and yes, most of these files are just “unfinished”, those for the libraries and versions for example.
if I followed 2)
I’d feel stupid to not just not commit these files instead of reverting my local changes each time before committing
and 3)
is mostly done by us, e.g. the version numbers in the config files and probably the library xml files too at some point
I feel most of the issues you have are only issues if you use generic command line commands affecting the whole repo each time instead of just working with the files you change in terms of versioning. That is committing only the package you work on, or even just the one file you work on… Anyway it looks like you’re able to ship around these “issues” just fine.
@normen said:
if we followed 1)
- we'd have to maintain a third set of user settings on the build server
- and yes, most of these files are just "unfinished", those for the libraries and versions for example.
About build server, if it require specific build options, I currently define them via the command line use to invoke the build or via a special build task. And sometime build server has it’s own user settings (eg: login / password)
@normen said:
if I followed 2)
- I'd feel stupid to not just *not* commit these files instead of reverting my local changes each time before committing
let’s go to commit.
My point 2) was about “temporary” change like adding debug trace.
@normen said:
and 3)
- is mostly done by us, e.g. the version numbers in the config files and probably the library xml files too at some point
mostly
@normen said:
I feel most of the issues you have are only issues if you use generic command line commands affecting the whole repo each time instead of just working with the files you change in terms of versioning. That is committing only the package you work on, or even just the one file you work on.. Anyway it looks like you're able to ship around these "issues" just fine.
you’re right I don’t commit/add file by file. After a modification, in the modified/untracked files, I select files to add to the commit (and I review the modifications, to remove some debug). I know lot of people following the same workflow. Mainly because I don’t use IDE’scm plugin and I often work with project without IDE (no language support).
I work on many projects (OSS and non OSS) and it’s the first time, that after a clone + build + open project, I’ve got the scm notify about changes to commit. It’s very uncommon and I image other futures (or wanabe) contributors, like me, will have the same “surprise”. Nobody else talk about this ?
We discuss and we provide our “workarounds”, so now there some trace, and contributor can chose its way.
May be a note in CONTRIBUTION.md is a better place.
No, nobody else talks about this. We either have people trying to contribute that struggle with even getting a checkout to work or people who can ship around such issues easily like you.
