Questions & Answers

How to work with Git submodules?

Git submodules allow you to keep a Git repository as a subdirectory of another Git repository. This lets you clone another repository into your project while keeping your commits separate.

 

The presence of Git submodules in a repository will not prevent you from using Hackolade Studio. But there is no handling of Git submodules currently in Hackolade Studio.  Even the GitHub Desktop application does not have any special support for submodules...

 

This article even suggests that a better alternative to Git submodules is to use Git subtrees.

 

How to deal with non-ASCII symbols in file names?

By default, Git replaces non-ASCII symbols in file names with octal notation. For example, a file named "TrainScheduleф.json" will be treated by Git as "TrainSchedule\321\204.json".

 

If you need to deal with non-ASCII symbols in file names, then open a terminal and run the command below in order to modify the default behavior of your local Git client (omit the $ sign in Windows).

 

$ git config core.quotepath off

 

See the official documentation about the Git configuration parameter core.quotepath for more details.

 

Where is my .gitconfig file?

From time to time, you may have to adjust Git configuration parameters.  The problem might be to find the location of the .config file first... You can view all of your settings and where they are coming from using to following command (omit the $ sign in Windows):

$ git config --list --show-origin

 

In Task Manager, I see many orphan background processes for Git for Windows

The issue is not specific to Hackolade and is linked to an experimental feature introduced in Git version 2.31.0.  If selected, Git will use a built-in file-system monitor, without the need to install Watchman.  However, this feature is not yet stable so it is strongly advised to run the following command:

 

For Git versions up to 2.35.x:

$ git config --global core.useBuiltinFSMonitor false

 

 

For Git version 2.36.0 and above:

$ git config --global core.fsmonitor false

 

I'm getting an error core.useBuiltinFSMonitor=true is deprecated

Starting with version 2.36.0, the config keyword useBuiltinFSMonitor has been deprecated, and replaced by fsmonitor. When opening a repository, if you get the error:

 

The hint is accurate.  You should run the following command at a command prompt (omit the $ sign in Windows):

$ git config --global core.fsmonitor false

 

 

I have GitHub Desktop installed on my machine.  Is it not a Git client?

Be careful that GitHub Desktop, SourceTree and other visual applications are NOT the Git client the we're looking for here.  They are GUI applications also leveraging the system Git executable.  If you specify a custom path, it must be to the Git executable.

 

 

With GitHub Desktop, it is possible that the installation did not declare the location of the Git executable in the system PATH.  This is a well documented situation...  Hackolade Studio has been enhanced to auto-detect the Git executable installed by GitHub Desktop, if in one of its standard locations:  

C:\Program Files\Git\bin\git.exe

C:\Users\%username%\AppData\Local\GitHubDesktop\app-3.0.0\resources\app\git\cmd\git.exe (GitHub Desktop version 1.1 and above)

 

If installed elsewhere, like 

C:\Users\%username%\AppData\Local\GitHub\PortableGit_<guid>\cmd\git.exe (GitHub for Windows prior to version 1.1)

you may have to declare the custom path manually.

 

See more info in the pre-requisites page.

 

How should I organize our models in the repository?

Should we co-locate models in the application code repo?  Or should we have a separate repo?  Should we have one or more repos?

 

These are excellent questions.  But there is no black-and-white answer, except "it depends"...  You should experiment, and discuss with multiple stakeholders, to find the best setup for your organization.

 

You may already have reviewed our resources specific to the Git integration:

- online documentation and pages below

- eLearning platform videos

 

On the specific question of the repo organization:

- you may co-locate models with application code

- advantages: 

    - model changes follow the same lifecycle as the application code

- model changes provide additional context for the application code

- disadvantages

    - it is harder to decouple models from application code if, for example the target is shared across different applications

- rights management whereby maybe you don't want modelers to have access to the application code

 

- you may want to have a separate repo for models

    - pros and cons are the mirror of the above

 

Some customers choose the former, others the latter.  There is no rule.

 

Also, when choosing a dedicated repo for models, the folder structure differs widely between customers.  Some are domain-oriented, some are application-oriented, some are access rights-oriented, etc.

 

And when using a dedicated repo, some wonder about whether there should be one repo per domain, or multiple repos.  We generally advise to have a single repository.  If you're worried about the protection of your models, so their changes follow a process, you have 2 options:

- you can force in your repo that changes be made through change (pull) requests

- better yet, you may want to force adopt a fork & pull strategy, also known as innersourcing.

 

Our application can accommodate any and all of those repo organizations, but each customer has its own perspective, and we don't know enough to judge.

 

Why is there no auto-commit capability?

Git itself does not provide this feature.  And the reason is that there are too many risks:

- Risk of unintentional commits: auto-committing can cause unintended commits that might include unnecessary or incomplete changes.

- Loss of control: it might push changes that you're not ready to share, or break models

- Inconsistent history: it can create a mess in your commit history, making it harder to understand the changes over time.

 

How are permissions managed?

1. Even for the viewer edition, anyone who needs to have access to a file somewhere must be given proper access.  Same as in anywhere in the digital or physical world.  If a model is stored on a shared drive or in a Git repository, the user must be granted access for that location in order for the user to be able to open the model.  
2.  
3. Just like with any client application, like Microsoft Excel for example, the access control is delegated to the storage layer: the local file system, a shared drive, or the Git repository.  If someone has access to a file, then the application can open it.  The right to edit a modelis shared between the license key (author or viewer -- if you only have viewer rights, you cannot edit a model, even if you have write rights) and the repository -- even if you have the workgroup edition, you cannot save the model in a place where you have no rights to do so.