Git-2.46.1

Using Git

This Git installation doesn't have the full power Git can provide, such as scheduling and the like. If you want even more features, check https://linuxfromscratch.org/blfs/view/svn/general/git.html. However, this installation if you installed cURL-8.9.1 can provide enough features to be of good use for you, such as the ability to clone repos. This is sometimes a necessity when developers don't publish releases or haven't in a long time, so the repo is the only way to obtain the (hopefully) up to date package. In order to clone a repo, simply invoke:

git clone https://path/to/repo.git

The above command will then clone the entire repository besides subprojects, something that some projects do and require special instructions. A directory will be created, called repo, in the current working directory, with all the repo's files being in that just created directory. If you want to for some reason change the directory name, you can do it when you clone the repo, like so:

git clone https://path/to/repo.git newname

The above command will create the directory called newname and put all the repo's files in that directory. Eventually you'll come across a repository that has some subprojects, for instance an emulator that depends on graphic libraries and intends to compile a static version of it. In order to pull in those subprojects, you must also invoke the --recurse-submodules option. This will clone all the subprojects and check them out.

Git Repo vs Release Archives

All of the packages in GLFS, except for when obtaing firmware, have you download tarballs or zipfiles. These tarballs and zipfiles were created as part of a release, and often include files not found in the repo equivalent where the package development happens. Usually the extra included files are the configure scripts you should now be used to using. They are generated manually using aclocal, autoconf , and automake. The configure scripts are often not in the repos, so if the git repo gets cloned, you will have to generate the configure script yourself if you find configure.ac, Makefile.am, and possibly autogen.sh . You won't need to do this if you find the repo has a Makefile or has meson_options.txt or CMakeLists.txt.

Another big difference between the repo and the release package is that the repo probably has had commits after the last release if it had any, and new commits can introduce bugs or prevent compilation. When developers prepare a new release, often they search for issues, bugs, and compilation errors, making it stable before they publish the release and its related package files. Release packages aren't entirely safe from issues and can help with causing issues as files can be added. Sometimes you can tell if something is wrong, sometimes you can't. It's always important to be up to date with security news to prevent damage.