cubemx re-generating

[Maciej Drozd]

Posted on December 26, 2016 at 23:31

Few weeks ago I have started my first CubeMX generated project. Like always, my project is stored in git repository (locally).

Recently, I wanted to extend projects functionality using re-generating option of CubeMX. Before this operation I have carefully commited my work.

After CubeMX regeneration, with options like: 'backup previously generated...' and 'keep user code...' checked in, I got surprise! All my work is overwritten by CubeMX. Whole git repository is without any question deleted! There is no single byte of my work in project.

I'm really disgusted, what a kind of toy with CubeMX.

File rescue tools haven't helped

:(

What have I done wrong?

[danielbuga9]

Posted on August 21, 2017 at 20:10

Well, creating a new .ioc and migrating to it manually gives this behaviour... CubeMX thinks it can clean the directory and you won't care about it's contents, because you deliberately placed a new project in it. Well, I just did this, time for Undelete to do its magic.

Guys, deleting the .git directory is not cool even if you want to clean the project dir. Please fix this.

[danielbuga9]

Posted on August 21, 2017 at 20:12

I know this thread is old, but as I stated in my reply to Clive One, CubeMX deletes the .git directory for a new project even if all I want is the generated code to be replaced with code for an other microcontroller. So instead of deleting everyting blindly, at least keep the .git (or any other hidden, or 'supposed-to-be-hidden' files). Thank you.

[David Littell]

Posted on August 21, 2017 at 20:45

For some reason I'm not seeing your reply to Clive.  In any case, though, where is your .git directory located relative to the Src (or Inc) directory?

[danielbuga9]

Posted on August 21, 2017 at 20:49

That comment is still under moderation, I wonder why this one wasn't.

Anyhow, the .git directory was at the same level as the Src, Inc, so in the project root. Now I know why Eclipse does not recommend it.

[Tesla DeLorean]

Posted on August 21, 2017 at 21:34

My personal view of source control is that you should be doing your own work in a sandbox, into which do your pulls and commits, the CubeMX tool should be building into it's own workspace, that it can trash and soil has much as it wants, and you merge/diff the content created from your incremental fiddling with CubeMX and .IOC files into your sandbox.

There is too much possibility for the automated tools to nuke the project in undesirable ways either due to user fiddling or tool version updates. There's years of documented destruction, why even let failures in other peoples tools cause this much grief. I think CubeMX should 'do no harm', but I'm not going to wait for that to happen or risk my livelihood on it. CubeMX (Micro Xplorer) was initially a once-and-done tool, this whole rinse-and-repeat model it a lot harder to pull off.

Not sure the Atollic/Eclipse 'workspace' functionality does things the way I like, with Keil/IAR I can just clone directories at the same level without the project falling apart.

[danielbuga9]

Posted on August 21, 2017 at 21:47

Usually my stuff are backed up well enough, my professional work is, at least. This is a hobby project of mine, I did not care as much about it - there's a single driver I lost that hurts somewhat, but that's only a few hours of work and it wasn't even my most beautiful code.

Yes, backing up is important. But this is a thread to report bugs and I just described (I admit, in a poor state of mind) a way that I managed to 'recreate' the losing of the .git directory. I know that Eclipse is not a professional tool at all, and I know how I shouldn't trust automated tools. And that is fine.

But this is a behaviour that is downright dangerous and it has to be changed to prevent more harm being done. Yes, people should protect their work but the tool makers should also make sure, and I mean _sure_ that they don't destroy stuff. If they delete a file, they should move it to the recycle bin, not delete it permanently. Better yet, don't change unknown files. I don't care about source, but the .git directory should be sacred as it's 'hidden' by unix convention.

In short, I agree, but the tools also need to be less destructive and in this case it can be achieved.