Differences between version 19 and predecessor to the previous major change of Git.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 19 | Last edited on Sunday, February 1, 2009 2:34:04 am | by AristotlePagaltzis | Revert |
| Older page: | version 17 | Last edited on Saturday, January 31, 2009 1:03:38 pm | by LawrenceDoliveiro | Revert |
@@ -1,12 +1,14 @@
-[Git] is an OpenSource VersionControlSystem
(although it originally started as just a storage backend). It was initially written by LinusTorvalds for the needs of the LinuxKernel developers, but due to a clever but simple internal design it can be tailored to nearly any development workflot. It is itself kept [in a Git repository | http://master.kernel.org/git/?p=git/git.git;a=summary]. The project was born of necessity when BitKeeper's licence was changed such that it was no longer an acceptable home for the LinuxKernel, but all other VersionControlSystem~s were found inadequate.
+[Git] is an OpenSource [DVCS]
(although it originally started as just a storage backend). It was initially written by LinusTorvalds for the needs of the LinuxKernel developers, but due to a clever but simple internal design it can be tailored to nearly any development workflot. It is itself kept [in a Git repository | http://master.kernel.org/git/?p=git/git.git;a=summary]. The project was born of necessity when BitKeeper's licence was changed such that it was no longer an acceptable home for the LinuxKernel, but all other VersionControlSystem~s were found inadequate.
> Torvalds seemed aware that his decision to drop BitKeeper would also be controversial. When asked why he called the new software, "git," British slang meaning "a rotten person," he said. "I'm an egotistical bastard, so I name all my projects after myself. First Linux, now git."
From [PC World: After controversy, Torvalds begins work on "git" | http://www.pcworld.idg.com.au/index.php/id;1852076002]
!!! Design
[Git]'s primary design objective is to keep the computational effort of committing a patch proportional to the size of the patch, rather than the size of the repository, as would be the case with most VersionControlSystem~s. This is achieved by keeping every version of every object (ie a file in a directory), compressed using ZLib and identified by its [SHA1] sum. Contrary to traditional VersionControlSystem~s, this makes building a history for a single object computationally expensive, while at the same time making getting a view of any particular revision of the repository as a whole very cheap.
+
+The main [Git] ManPage describes it as “the stupid content tracker”. What this means is that the repository format is designed to store only file and directory contents (known as a tree) but not store information about how trees arrived at their state. F.ex. deleting a file and then untracking it in [Git] is identical to using <tt>git rm</tt>, an operation that is special in many other [VCS]s. While this means that algorithms like rename tracking and merge conflict resolution must initially get by with less information, it also means that as that as they become more intelligent, all of the history benefits, not just history recorded recently enough to have the necessary metadata. It also means that all workflows are created equal.
[Git] has two main ways of transferring data. Its native application protocol is implemented by the <tt>git fetch-pack</tt> and <tt>git upload-pack</tt> commands, but [Git] can also crawl the files in the remote repository's object store without reliance on server-side intelligence. There are a number of transport protocols:
* The most efficient transport protocol is called <tt>git://</tt>, which is merely a thin [TCP] wrapper around the application protocol, commonly using [Port] 9418. However it has no built-in access control so usually does not allow pushing, although it can.
@@ -14,10 +16,8 @@
* On servers without [Git] installed, you should probably use rsync(1). Again, pushing is usually possible.
* Lastly, the slowest option is to simply publish the repository via [HTTP]. If the WebServer supports WebDav, it can even accept pushes.
Note that when using a dumb transport, you must ensure that <tt>git update-server-info</tt> is run in the repository any time someone commits to it (eg. by setting up a hook). This maintains a static file with a stored index of the state of the repository which would be dynamically negotiated between <tt>git fetch-pack</tt> and <tt>git upload-pack</tt> in smart transports.
-
-The main git man page describes Git as “the stupid content tracker”. The only thing “stupid” about the design of Git is that it its data structures are independent of any particular algorithm for merging conflicting changes. The early merge algorithms may not have been very elaborate, but it was possible to add better ones without any changes to the repository format—see the “merging strategies” section of the git-merge man page to see what’s currently available.
!!! Notes
You may encounter the following error:
