git 2.27.0 πŸ’Ύ

Git is a distributed version control system, originally designed for Linux kernel development and large projects with non-linear workflows. It's comprised of individual tools, reuses ssh and rsync protocols, emphasises speed and data integrity, and keeps every checkout as full-fledged repository, and cryptographically authenticates source history. Various graphical frontends, IDE integrations and web services (GitHub) exist; with its git-fast-export format meanwhile serves interoperability with

minor feature: When "git describe C" finds that commit C is pointed by a signed or, annotated tag, which records T as its tagname in the object, the, command gives T as its answer. Even if the user renames or moves, such a tag from its natural location in the "refs/tags/" hierarchy, "git describe C" would still give T as the answer, but in such a, case "git show T 0" would no longer work as expected. There may be, nothing at "refs/tags/T" or even worse there may be a different tag, instead. Starting from this version, "git describe" will always use the, "long" version, as if the "--long" option were given, when giving, its output based on such a misplaced tag to work around the problem. "git pull" a warning message until the pull.rebase, configuration variable is explicitly given, which some existing, users may find annoying---those who prefer not to rebase need to, set the variable to false to squelch the warning. The transport protocol version 2, which was promoted to the default, in Git 2.26 release, turned out to have some remaining rough edges, so it has been demoted from the default. A handful of options to configure SSL when talking to proxies have, been added. Smudge/clean conversion filters are now given more information, (e.g. the object of the tree-ish in which the blob being converted, appears, in addition to its path, which has already been given). When "git describe C" finds an annotated tag with tagname A to be, the best name to explain commit C, and the tag is stored in a, "wrong" place in the refs/tags hierarchy, e.g. refs/tags/B, the, command gave a warning message but used A (not B) to describe C. If C is exactly at the tag, the describe output would be "A", but, "git rev-parse A 0" would not be equal as "git rev-parse C 0". The, behavior of the command has been changed to use the "long" form, i.e. A-0-gOBJECTNAME, which is correctly interpreted by rev-parse. "git pull" learned to warn when no pull.rebase configuration, exists, and neither -- no- rebase no

GNU LGPL c git scm vcs dvcs