-
Notifications
You must be signed in to change notification settings - Fork 194
I haven't found any Modelica template for .gitignore on https://github.com/github/gitignore.
Shall we prepare one? Maybe with a general part and vendor parts?
All reactions
Replies: 5 comments 1 reply
Good idea.
All reactions
I've prepared the first draft of gitignore for Modelica, looking several Modelica repos over and reducing (to my knowledge) to the most common setting.
https://github.com/tobolar/gitignore/tree/addModelica, or directly the file Modelica.gitignore
Please feel free to add, delete, modify and whatever to improve this gitignore file. Once finalized, I would trigger the PR.
All reactions
I think it looks quite good!
I also ignore .moe and .mol files.
Dymola and maybe other tools can generate modelDescritpion.xml file along with build artefacts, do you want to ignore that?
Another build artefact to ignore: *.log files
I have these lines also in my gitignore:
# Ignore merge conflict leftovers
*.mo.BASE
*.mo.LOCAL
*.mo.orig
*.mo.REMOTE
You have listed .pyc, but that is from python. If you want to ignore it, you might want to use .py[cod] instead.
All reactions
I was thinking about tool-specific patterns for System Modeler, but couldn't think of a single pattern which would be specific to our tool.
All reactions
I'd be curious to hear your thoughts regarding the role of a template like this. Should it aim to cater for every possible tool and habit used to work with Modelica repositories, or should it rather aim to be an example of a more minimalistic setup which we believe is relevant for modern work on a Modelica repository?
It's probably worth making a comparison with https://github.com/modelica/ModelicaStandardLibrary/blob/master/.gitignore in the MSL. This file with all its global patterns defined at the top level looks like chaos to me, and I hope we will find objectives that will result in something more tidy that we can recommend as a template for others to copy.
For example, I am thinking about how to manage the large and ever changing collection of tools used to edit project content. Is is really reasonable that it is the responsibility of this file to know how Emacs names its backup files, or is it a more modern and relevant approach to assume that users of Emacs will take care of this in their ~/.config/git/ignore? Similarly, do we really imagine that the various tools used today for building external code really should be supported with global ignore patterns defined at the project root?
All reactions
First it is not clear that all of them should specifically be in gitignore; https://git-scm.com/docs/gitignore indicate that left-over from editing (and possibly build-artifacts) may go in the users gitconfig instead.
But ignoring that, for tool use there are several parts:
- Temporary build-artifacts (log files, modelDescription.xml etc)
- Left-over from editing (.bak-mo etc for Dymola)
- Generated contents (FMUs, plots, moe and mol-files).
Let's consider each of them:
-
Build-artifacts:
I can understand the need here, but the simplest solution is to not have build-artifacts inside your library, by not simulating inside the library. That's why Dymola added File>Open>Load some decades ago. -
Left-over from editing.
Since you are using Git for version control you should configure the tool to refrain from generating them (and/or push tool-developers to add such possibilities). Obviously things may break, but then it's similar to a merge-conflict, i.e., something that needs to be resolved - not ignored. -
Generated contents:
This is complicated. If you are encrypting the library (generating moe and mol-files) it can make sense to version control them - but usually separately. Similarly for plots and FMUs; where you also want some form of scripting for automatically generating them.