🔧 fix repository on Linux or MacOS dev machines

[wiztigers]

On my linux, a fresh clone of the repository gives me this error:

warning: CRLF will be replaced by LF in <path to expertnation .PNG>.
The file will have its original line endings in your working directory

Files concerned by this are all in hclient/widgets/expertnation/assets/:

• beyond1914/documents/beyond1914_help_search.PNG
• beyond1914/documents/beyond1914_help_search_dropdown.PNG
• beyond1914/documents/beyond1914_help_search_facets.PNG
• beyond1914/documents/beyond1914_help_search_simple_plus_facet.PNG
• uadelaide/documents/nov1918_help_person.PNG
• uadelaide/documents/nov1918_help_search.PNG
• uadelaide/documents/nov1918_help_search_dropdown.PNG
• uadelaide/documents/nov1918_help_search_facets.PNG

Problem was due to the fact that those are .PNG files, and not .png.
As it turns out, filters in .gitattributes are case-sensitive.

I modified the .gitattributes to make these files explicitely binary.
Another solutions would have been to rename these 8 files, but I don't know if this would have had unintended behaviour in these apps.

Any of these solutions is NOT sustainable however anyway ; if you don't wanna be bothered by case (which is debatable), what should be done is to update the whole .gitattribute file as I did.

You don't have this problem on Windows because this OS is case insensitive, but in other situations, it can bite you in the nose.

 

As a side question, shouldn't ExpertNation specific assets be in their own project, and not in Heurist core repository ?

[wiztigers]

As a side note, this pull request allows to use tools like git flow on a Linux dev machine.
You can't do git flow init in the repo as it is in the current state, because the stack of errors I talk about in this PR description counts as "unstaged changes". And if you git move the guilty files, first in would create an additional commit, and second this can have unintended consequences on ExpertNation.

[michaelgfalk]

Hey @wiztigers, does the git flow tool implement the Git Flow development strategy? If you look at previous commits to the repo, you'll see that we don't use Git Flow currently. Instead we do continual minor changes to the main branch, which is currently h6dev. I agree, moving to something like Git Flow would be a great idea if we do engage more developers to work on the project – it will make tracking what's going on much easier. But I think that is a discussion for another issue.

[michaelgfalk]

Thanks for the bugfix too!

[wiztigers]

Hi @michaelgfalk , thanks for the merge

Hey @wiztigers, does the git flow tool implement the Git Flow development strategy? If you look at previous commits to the repo, you'll see that we don't use Git Flow currently. Instead we do continual minor changes to the main branch, which is currently h6dev. I agree, moving to something like Git Flow would be a great idea if we do engage more developers to work on the project – it will make tracking what's going on much easier. But I think that is a discussion for another issue.

First, I'd want to reiterate that allowing Gitflow wasn't my main purpose in this PR, it's just that IMO the repo wasn't in a clear state for Linux devs. I did't like that git status didn't show me a blank state although I just cloned your repo. Didn't send a good message, y'know?

To answer you now, there isn't only one development strategy allowed by Gitflow, there are many. Gitflow is only a tool that standardizes the way you branch in the usual cases (new feature, hot fix, release). So deciding to use Gitflow is, in my opinion, not enough to be "good to go". What constitutes a feature ? What constitutes a hotfix ? How should branches be merged (rebasing or not? squasing or not?)
I mean, as you seem to be missing a guide explaining your dev practices, I didn't even know how you work, so I couldn't adapt to your workflow. That's where using Gitflow could be kind of "a dev guide in itself", but it's not enough. No tools can replace good communication between team members.

I agree with you that Gitflow makes development easier in many cases ; personally, I'll use it in my fork of Heurist on Huma-Num Gitlab, because it allows me to be more understandable from the outside (eg. by you guys).
Ian suggested than one day I'd give him a crash course on git (and I could, it's just ... more efficient to be face-to-face for this kind of thing), but there really is a bit more than that. For me, Gitflow is just one of the components that will allow me to deliver quality features in the future, the others being unit testing, refactor, documentation, "historization" (eg. linking commits to issues, this issue being the main source of discussion, debates, context in which the defect occured (how to reproduce, ...), ...), and so on.

What I could do before that however, is to document how I do things regarding to git, and why it's good for me. This could maybe lay the first stones of a future "developer guide".
Thus, you could test if this method works for you. If so, that's one step for me to one day join you guys on the core repo. If not, that's exactly why I chose to work on a fork, so that everyone of us can work their own way/pace.
Do you think such a document would be useful ?