Update git_update.sh

[jcalve]

Exits if it's not a clone of the master repository, also checks if the data path exists and clones the repository it if it doesn't.

[andy5995]

Hi @jcalve

I tried it but didn't work as intended. The URL i have configured is git@github.com:ZetaGlest/zetaglest-source.git

I'm sure it would be simple to add some extra conditions, however...

Thank you for this, but I was planning on doing away with this script. There's no real reason to keep a script in our repo that does such a simple task. If anyone wants to create a script for their own use, they have that choice.

If you'd like to help with another PR, You could remove this script and and the reference to it on https://github.com/ZetaGlest/zetaglest-source/blob/develop/BUILD.md. Also there is one hanging out in the root dir of https://github.com/ZetaGlest/zetaglest-data

If not, I'll do it myself or open a ticket. Thanks again for your effort! Sorry we couldn't use your suggestions this time.

[linux-player9]

I prefer you keep the script, not every Linux users know how to create a script that does the same. And this script is the simple way to update the source and the data

[andy5995]

@linux-player9 , @mathusummut will have the final decision about it, but my opinion is that from a maintainer's point of view, scripts like this clutter up the repo. They tend to work fine at first, but over time as things change, they need updating and no one bothers to update them.

For example, the setupBuildDeps script is far behind on maintenance. It's designed to detect the user's specific Linux OS, then run the appropriate package manger to install the dependencies. Which means every time a Linux distro increases a version, the script must be updated. Old versions of the distro should be removed. The questions comes up, "How long do we support that particular distro and version?" Also the script installs dependencies that are no longer used.

However, the script's purpose is to do only does one thing that can be done with one command line. Run the package manger, followed by a list of dependencies.

From a user's perspective, yes it's very simple and convenient. For maintainers it's not so easy. If we had a team of 20 or 30 people working on things, that would be a different story. In the meantime, we have to make due with what we have.

The git_update script essentially does one thing: git pull. In the data and source repo...so 2 things ;)

not every Linux users know how to create a script that does the same

Not every Linux user has to know how to create a script to do it. If a user is at the point they have a git repo, they have at least some basic knowledge of git, and should know how to use "git pull" without the use of a script. After a release, even fewer people will have to worry about pulling source and data.

Do you know how to make a script? If not, I can teach you.

[andy5995]

Windows version is not relevant to the script, not entirely sure why Linux version is relevant, but that’s just because I don’t know the build process on Linux.

There are sometimes subtle differences in library names or what's included between Linux distribution version.

For example, Debian 7 might come pre-installed with some required development libraries, while Debian 9 does not.

In reality, the Linux versions aren't relevant. The script makes them relevant. The setupBuildDeps script figures out which version of Linux the person is using and then downloads the packages known to be needed. The script maintainer has to add the package names in manually as things change.

Of the hundreds of programs I've tried, there are no scripts that automatically try to do that. The dependencies are listed in the documentation. If any dependencies are already installed on the user's system, his package manager simply skips over them.

On our Build page, under the `dependencies' section, you can see there are subtle variations between the filenames of development libraries between distributions (not Linux distro versions).

Nothing beats a single-command solution, which is why I took the time to write setup.bat, which automagically calls the approprite scripts for build to take effect.

I would disagree with that, and say sometimes it's better to automate things, and sometimes not. To prepare ZG for Linux packaging, I set things up in a way that I felt would work best for me and other contributors in the future. I'm more for making sure the end-user has an easy-to-use automated experience. I feel that development however, should be broken down into each step, and well-documented to make changes easier, and so developers understand how everything works.