Hi Giovanni,

I have two comments;

1.
For submitting changes, please make a patch. Using git you can create patches easily. Under linux you would do

git diff src/oofemlib/fileA.C src/sm/someotherfile.h src/sm/CMakelists.txt    >  my_changes.patch

Under windows, I'm not sure. You can probably find how to make a diff through whatever graphical GIT tools you might be using.

A diff lets us see what specific changes has been done.

2.
Please fix the indent and coding style on the changes.
This might seem picky, but with several authors, different indenting and coding styles, even though it's mostly just whitespace characters, can cause a lot of headaches when there are merge conflicts.

You managed to include a few lines in the beginning that is not part of the patch. You also included some changes from an unrelated files.
Always make patches as small as possible, single out features (rarely will it be all your changes)

I just mention this for future reference. You don't need to include a new file, because it's simple enough for me to delete these other changes myself.

It's not that strict that all code checked in has to go through uncrustify, though we do it occasionally to the whole code base.
The problem was the tabs used for indenting, which would all be modified if any other developer touched the code later.

If you can set up your IDE to be as close as possible to the uncrustified code (tabs, where to add newlines, etc.) then I wouldn't have bothered to ask you to uncrustify anything.

Hi Giovanni,

I was planning on merging in these changes now, but the patch is no good.
It has a bad path;
diff --git "a/C:\\Users\\Giovanni\\AppData\\Local\\Temp\\TortoiseGit\\bea541A.tmp\\beam3d-c4e7651-left.C" "b/C:\\oofem\\src\\sm\\beam3d.C"
Your other patch did it correctly, so please remake this one. Patches should be self-contained, so please don't make patches for individual files.

Even better, if you plan on making contributions in the future, I recommend that you learn git and send me a pull-request on github (though sending patches is also OK if it's just going to be a few changes).

Actually, you would be sending me a pull request (which i could choose to accept, reject, or request changes to be made).

This last patch doesn't contain all the changes, it just fixes the indentation so the critical changes are actually missing.

Since it was a patch to an old version, I'm not sure if everything went in correctly. It seems to work, so you will have to try it out to be sure.

In the future, if someone wants me to include changes it should either be
1. New files (if someone has written a new element/material)
or
2. A pull request on github

Anything else always tends to turn into to much of a hazzle if the patch isn't perfect (and relative to the latest version), like in this case.

I understand that when you first wrote this patch it was relatice to the latest version, but before anyone had time to look at it, it was to late. But, unfortunately, I will still have to require the submitter to do the extra work in the future.

Yes, my github repo should work with windows (we fixed a few minor things recently), but I'm not personally testing VS that often (or ever).
The plan would be to have nightly builds on all supported platforms.

Do not send any more patches for this, since I have already applied this one (with a bit of manual changes) (unless you have to make corrections).
We should have done it via pull-requests to start with, where I allow you to make additional commits until the the changes are ready to be merged.
So, the price to pay for this, is that now both repos (yours and mine) now has different changes, is that a merge is *not* advised (there would have duplicated changes, and probably a lot of ugly merge conflicts).

Side note: sending patches (which is still a good way if you only plan on making a single change) stems more from the old SVN days, where you couldn't make any commits if you weren't granted access. Now, with distributed version control, everyone can work on their own copy, and then the maintainer merges changes regurlarly.

The best thing you could do now, is to do a fresh clone of my github repo (any repo would have worked, but I have only merged your patches into my github repo yet), and if you have other changes, copy over those files and make a new commits for those changes again. From here on out, we'll stick to pull requests.
The main problem is that of CMakeLists.txt changes you had to do for PETSc. I could selectively avoid pulling in those changes, but a better solution would be to solve this in a satisfactory way once and for all.

The easiest way is to fork from my github account (so that you can send pull requests). You can on your local machine add however many repositories you want. I have my github repo, and the oofem.org repo added to my local repos, so that I can pull in changes from either easily.

I hadn't pushed the changes from my local machine yet. They are there now.