Version control using git with Dymola/Modelica
Asked Answered
F

1

6

At work I use git as a version control system and Dymola for modeling and simulation.

One major Issue I have is that once I touch or by mistake move a connection (more exactly the position of a part of the connecting wire) in a diagram without changing any parameters -which usually happens when discussing or explaining by showing the diagram to colleagues- git consider this as a version change or change in the file. At least the real change is in some auto-generated Modelica annotations, for example:

connect(TT_1.T, Controller.y[1]) annotation (Line(
  points={{48,-20},{48,40},{-22.5,40},{-22.5,29.25}},
  color={0,0,127},
  smooth=Smooth.None));

changed to (compare the 2nd lines)

 connect(TT_1.T, Controller.y[1]) annotation (Line(
  points={{48,-20},{48,38},{-22.5,38},{-22.5,29.25}},
  color={0,0,127},
  smooth=Smooth.None));

My Question therefore is: How can I prevent such an unnecessary "change" in the code on either side: git or Dymola?

Fluorite answered 22/4, 2016 at 6:22 Comment(12)
well, it is a version change, since the .mo text file changes, so I don't think you can do anything about this on the git side (except undo the changes with git, if they are the only ones).Chatterer
@Chatterer I was expecting this, I was also wondering if there's a possibility to "ignore" such changes somehow. But how to undo changes with git? I mean is it possible before committing? Maybe that could be an answer or at least a part of it!Fluorite
I'd say connections, layouts, and the graphics of your model should also be a part of your model design, and they are as important as your physics. They might not affect your physics, but it helps tremendously in understanding the model, it's just like comments or naming conventions in your code, I would never ignore this in git. Also, if you do encounter quite a lot of issues like this, I think you're probably not using the inheritance feature of Modelica a lot, because once a partial model is designed you won't be able to change their graphics in its children.Whitecap
From some discussions with long time users, this very issue was brought up. Dymola has issues with "whitespace" modifications.Dandle
I think you are confusion a "version" with a "release". In the course of developing any code, you will make countless changes. Those changes should be committed to your version control system. But you should not make this mistake of thinking about this as a release (i.e., a change that should trigger users to upgrade). It isn't clear to me what you think the "problem" here is. Perhaps you could elaborate on that if these comments aren't addressing your concern.Await
@MichaelTiller I don't think so, as the change is more in the graphics (more precisely in the annotations of the position of a virtual wire) then in the code.Fluorite
the graphics is the code, though. Regarding your git question, read up on git reset, e.g. here.Chatterer
@Chatterer thanks for the helpful link. I knew the command, but to some extent failed to use it the right way. I hoped that somehow one could ignore minor changes in the Dymola annotations or freeze them somehow.Fluorite
you can use git stash to temporarily move changes away.Chatterer
@Chatterer that seems to be an other nice git solution. I want to wait a while before accepting the given answer even if I feel that you have given me more options. As said if there's a possibility via Dymola, that would be preferable, as even if I'm familiar with git, I'm used to some kind of commands and command sequences in a way I would really need to pay much attention to remember using stash and reset ;)Fluorite
But isn't git stash meant for temporarily storing changes that you want to keep working on later? If you accidentialy introduce changes while showing something to a colleague, the easiest solution would be to just not save these changes!? Or if it is already too late for that, revert/reset them.Denotation
@Denotation well of course i don't need to store save it, but git already consider it as a change.Fluorite
D
3

The graphical part of your model also has to be stored somewhere, and the place Modelica uses are so called annotations. Every model, instance of a model and also every connection has such annotations. The graphics do not influence the "pyhsical" behavior, but they are still important for end user convenience.
Now, if you edit some icon or connection (or, anything else) from the GUI, this change will be reflected in the code. And once you click the save button, the file will be written to disk and git will notice that the code has changed. Some of these changes might be on purpose (some people invest a lot of time in nice looking connections), while other changes might not be important. There is absolutely no way how a version control system can decide what you consider relevant, that decision is up to you. You can always decide NOT to save your changes (in Dymola, choose the Save None button).

In addition to the changes that you are responsible for, your tool (e.g. Dymola) might try to be smart and do some auto-formatting. There are users that consider Dymolas behavior too intrusive (e.g. breaking lines, inserting whitespace, adding irrelevant annotations, moving comments around). Sadly, there is not much you can do here, except of course stopping to use Dymola as an editor (and instead only use it as a simulation tool), or you can use cleanup tool like ttws (trim-trailing-white-space). As far as I know, Dymola does not move around your icons, so the example you showed was not introdced by Dymola.

Now, second part of your question. If for some reason you have clicked the save button, git (and any other good version control system) allows you to revert your changes, or part of your changes, before commiting (or after commiting, but then things get more complicated). Also, you do not have to push all your commits to the central repository. The exact workflow will depend on which git client you use and whether you use a graphical user interface or the command line. Which one do you use?
Below is a screenshot of the GitExtensions commit dialog (this image is the main reason for writing an answer instead of a comment):

GitExtensions Commit Stage Revert dialog

  • On the left top, you see all files where git has noticed a change, here you can revert whole files.
  • On the left bottom, you see the staging area. Only the files in the staging area will be part your commit.
  • On the right top, you see the diff and the context menu that allows to reset single lines of code.
  • On the right bottom, you would type your commit message.

There are many tutorials and books available on how to use git, you probably want to read these, as well as the manual for the git client of your choice. Or, you simply do not click the save button when there is nothing you want to save.

Denotation answered 25/4, 2016 at 9:5 Comment(2)
I knew about git reset, but beside your answer the comment of Carsten was very helpful. I was hoping that there's a chance that one could make graphics and annotation untraceable for git.Fluorite
My example of course was not made by Dymola only, but it certainly happen that I just want or by mistake change the layout/coordinates of some components. Of course for Dymola this is significant change, but for me especially in the case it was created by mistake it is not!Fluorite

© 2022 - 2024 — McMap. All rights reserved.