Edit multiplayer.txt and secrets.txt

[gitmagic/gitmagic.git] / vi / secrets.txt

== Các Bí Mật ==

We take a peek under the hood and explain how Git performs its miracles. I will skimp over details. For in-depth descriptions refer to http://www.kernel.org/pub/software/scm/git/docs/user-manual.html[the user manual].

=== Invisibility ===

How can Git be so unobtrusive? Aside from occasional commits and merges, you can work as if you were unaware that version control exists. That is, until you need it, and that's when you're glad Git was watching over you the whole time.

Other version control systems force you to constantly struggle with red tape and bureaucracy. Permissions of files may be read-only unless you explicitly tell a central server which files you intend to edit. The most basic commands may slow to a crawl as the number of users increases. Work grinds to a halt when the network or the central server goes down.

In contrast, Git simply keeps the history of your project in the `.git` directory in your working directory. This is your own copy of the history, so you can stay offline until you want to communicate with others. You have total control over the fate of your files because Git can easily recreate a saved state from `.git` bất kỳ lúc nào.

=== Tính Toàn vẹn ===

Phần lớn mọi người sử dụng phương pháp mã hóa để giữ cho thông tin của mình không bị nhòm ngó, nhưng có thứ quan trọng không kém đó là giữ cho thông tin của mình được an toàn. Proper use of cryptographic hash functions có thể ngăn ngừa accidental or malicious data corruption.

A SHA1 hash can be thought of as a là một số định danh 160-bit không trùng lắp cho mỗi chuỗi ký tự you'll encounter in your life. Actually more than that: every string of bytes that any human will ever use over many lifetimes.

As a SHA1 hash is itself a string of bytes, we can hash strings of bytes containing other hashes. This simple observation is surprisingly useful: look up 'hash chains'. We'll later see how Git uses it to efficiently guarantee data integrity.

Briefly, Git keeps your data in the `.git/objects` subdirectory, where instead of normal filenames, you'll find only IDs. By using IDs as filenames, as well as a few lockfiles and timestamping tricks, Git transforms any humble filesystem into an efficient and robust database.

=== Thông Mính===

Làm thể nào mà Git biết bạn đã đổi tên một tệp tin, dù là bạn chẳng bao giờ đề cập đến thực tế này the fact explicitly? Chắc chắn rồi, you may have run *git mv*, but that is exactly the same as a *git rm* followed by a *git add*.

Git heuristically ferrets out renames and copies between successive versions. Trên thực tế, nó có thể tìm ra từng đoạn mã nguồn đã bị di chuyển hay sao chép giữa các tệp tin! Though it cannot cover all cases, it does a decent job, and this feature is always improving. If it fails to work for you, try options enabling more expensive copy detection, and consider upgrading.

=== Indexing ===

For every tracked file, Git ghi lại các thông tin như là kích thước, thời gian tạo và lần cuối sửa đổi trong một tệp tin được biết đến là một mục lục 'index'. To determine whether a file has changed, Git compares its current stats with those cached in the index. Nếu chúng giống nhau, thế thì Git có thể bỏ qua việc đọc tệp tin đó lại lần nữa.

Since stat calls are considerably faster than file reads, if you only edit a
few files, Git can update its state in almost no time.

We stated earlier that the index is a staging area. Why is a bunch of file
stats a staging area? Because the add command puts files into Git's database
and updates these stats, while the commit command, without options, creates a
commit based only on these stats and the files already in the database.

=== Git's Origins ===

http://lkml.org/lkml/2005/4/6/121[Linux Kernel Mailing List post] này describes the chain of events that led to Git. The entire thread is a fascinating archaeological site for Git historians.

=== The Object Database ===

Every version of your data is kept in the 'object database', which lives in the
subdirectory `.git/objects`; the other residents of `.git/` hold lesser data:
the index, branch names, tags, configuration options, logs, the current
location of the head commit, and so on. The object database is elementary yet
elegant, and the source of Git's power.

Mỗi tệp tin trong `.git/objects` là một 'đối tượng'. Ở đây có 3 loại đối tượng
that concern us: đối tượng 'blob', đối tượng 'tree', và đối tượng 'commit'.

=== Blobs ===

First, a magic trick. Pick a filename, any filename. Trong một thư mục rỗng:

 $ echo sweet > YOUR_FILENAME
 $ git init
 $ git add .
 $ find .git/objects -type f

Bạn sẽ thấy +.git/objects/aa/823728ea7d592acc69b36875a482cdf3fd5c8d+.

How do I know this without knowing the filename? Đó là bởi vì đó là giá trị
băm SHA1 của:

 "blob" SP "6" NUL "sweet" LF

là aa823728ea7d592acc69b36875a482cdf3fd5c8d,
với SP là khoảng trắng, NUL là byte có giá trị bằng 0 và LF ký tự xuống dòng. Bạn có thể xác minh lại
bằng lệnh sau:

  $ printf "blob 6\000sweet\n" | sha1sum

Git is 'content-addressable': tệp tin không được lưu trữ như theo tên của chúng,
but rather by the hash of the data they contain, trong tệp tin chúng ta gọi là một in a file we call a 'blob
object'. We can think of the hash as a unique ID for a file's contents, so
in a sense we are addressing files by their content. Phần khởi đầu `blob 6` đơn thuần
chỉ là phần đầu của một merely a header consisting of the object type and its length in bytes; it
simplifies internal bookkeeping.

Thus I could easily predict what you would see. The file's name is irrelevant:
only the data inside is used to construct the blob object.

You may be wondering what happens to identical files. Try adding copies of
your file, with any filenames whatsoever. The contents of +.git/objects+ stay
the same no matter how many you add. Git only stores the data once.

By the way, the files within +.git/objects+ are compressed with zlib so you
should not stare at them directly. Filter them through
http://www.zlib.net/zpipe.c[zpipe -d], hay gõ:

 $ git cat-file -p aa823728ea7d592acc69b36875a482cdf3fd5c8d

which pretty-prints the given object.

=== Trees ===

Nhưng mà tên tệp tin ở đâu? Chúng phải được lưu giữ ở đâu đó chứ.
Git gets around to the filenames during a commit:

 $ git commit  # Type some message.
 $ find .git/objects -type f

You should now see 3 objects. This time I cannot tell you what the 2 new files are, as it partly depends on the filename you picked. We'll proceed assuming you chose ``rose''. If you didn't, you can rewrite history to make it look like you did:

 $ git filter-branch --tree-filter 'mv YOUR_FILENAME rose'
 $ find .git/objects -type f

Now you should see the file
+.git/objects/05/b217bb859794d08bb9e4f7f04cbda4b207fbe9+, bởi vì đây là giá trị băm
SHA1 của nội dung của nó:

 "tree" SP "32" NUL "100644 rose" NUL 0xaa823728ea7d592acc69b36875a482cdf3fd5c8d

Check this file does indeed contain the above by typing:

 $ echo 05b217bb859794d08bb9e4f7f04cbda4b207fbe9 | git cat-file --batch

Với lệnh zpipe, ta có thể dễ dàng xác thực một giá trị băm:

 $ zpipe -d < .git/objects/05/b217bb859794d08bb9e4f7f04cbda4b207fbe9 | sha1sum

Hash verification is trickier via cat-file because its output contains more
than the raw uncompressed object file.

This file is a 'tree' object: a list of tuples consisting of a file
type, a filename, and a hash. In our example, the file type is 100644, which
means `rose` is a normal file, and the hash is the blob object that contains
the contents of `rose'. Other possible file types are executables, symlinks or
directories. In the last case, the hash points to a tree object.

If you ran filter-branch, you'll have old objects you no longer need. Although
they will be jettisoned automatically once the grace period expires, we'll
delete them now to make our toy example easier to follow:

 $ rm -r .git/refs/original
 $ git reflog expire --expire=now --all
 $ git prune

For real projects you should typically avoid commands like this, as you are
destroying backups. If you want a clean repository, it is usually best to make
a fresh clone. Also, take care when directly manipulating +.git+: what if a Git
command is running at the same time, or a sudden power outage occurs?
In general, refs should be deleted with *git update-ref -d*,
though usually it's safe to remove +refs/original+ by hand.

=== Commits ===

Chúng tôi đã giảng giải cho bạn 2 trong số 3 đối tượng (object). Cái thứ 3 chính là 'commit'. Its
contents depend on the commit message as well as the date and time it was
created. To match what we have here, we'll have to tweak it a little:

 $ git commit --amend -m Shakespeare  # Change the commit message.
 $ git filter-branch --env-filter 'export
     GIT_AUTHOR_DATE="Fri 13 Feb 2009 15:31:30 -0800"
     GIT_AUTHOR_NAME="Alice"
     GIT_AUTHOR_EMAIL="alice@example.com"
     GIT_COMMITTER_DATE="Fri, 13 Feb 2009 15:31:30 -0800"
     GIT_COMMITTER_NAME="Bob"
     GIT_COMMITTER_EMAIL="bob@example.com"'  # Rig timestamps and authors.
 $ find .git/objects -type f

You should now see
+.git/objects/49/993fe130c4b3bf24857a15d7969c396b7bc187+
which is the SHA1 hash of its contents:

 "commit 158" NUL
 "tree 05b217bb859794d08bb9e4f7f04cbda4b207fbe9" LF
 "author Alice <alice@example.com> 1234567890 -0800" LF
 "committer Bob <bob@example.com> 1234567890 -0800" LF
 LF
 "Shakespeare" LF

Như ở phần trước, bạn có thể chạy lệnh zpipe hay cat-file để tự mình trông thấy.

Đây là lần commit đầu tiên, do vậy lần commit này không có cha, nhưng những lần commit sau
sẽ luôn luôn chứa it nhất là một dòng chỉ định commit cha.

=== Indistinguishable From Magic ===

Git's secrets seem too simple. It looks like you could mix together a few shell scripts and add a dash of C code to cook it up in a matter of hours: a melange of basic filesystem operations and SHA1 hashing, garnished with lock files and fsyncs for robustness. In fact, this accurately describes the earliest versions of Git. Nonetheless, apart from ingenious packing tricks to save space, and ingenious indexing tricks to save time, we now know how Git deftly changes a filesystem into a database perfect for version control.

Ví dụ, nếu một tệp tin bất kỳ nào đó trong if any file within the object database is corrupted by a disk
error, then its hash will no longer match, điều này sẽ mang lại rắc rối cho chúng ta. By
hashing hashes of other objects, chúng ta có thể duy trì tính liêm chính ở tất cả các mức. Commits
are atomic, that is, a commit can never only partially record changes: we can
only compute the hash of a commit and store it in the database after we already
have stored all relevant trees, blobs and parent commits. The object
database is immune to unexpected interruptions such as power outages.

We defeat even the most devious adversaries. Suppose somebody attempts to
stealthily modify the contents of a file in an ancient version of a project. To
keep the object database looking healthy, they must also change the hash of the
corresponding blob object since it's now a different string of bytes. This
means they'll have to change the hash of any tree object referencing the file,
and in turn change the hash of all commit objects involving such a tree, in
addition to the hashes of all the descendants of these commits. This implies the
hash of the official head differs to that of the bad repository. By
following the trail of mismatching hashes we can pinpoint the mutilated file,
as well as the commit where it was first corrupted.

In short, so long as the 20 bytes representing the last commit are safe,
it's impossible to tamper with a Git repository.

Đặc tính nào của Git là trứ danh nhất? Nhánh? Trộn? Hay Tags?
Mere details. The current head được giữ trong tệp tin +.git/HEAD+,
which contains a hash of a commit object. The hash gets updated during a commit
as well as many other commands. Branches are almost the same: chúng là các tệp tin trong thư mục
+.git/refs/heads+. Tags cũng thế: chúng ở tại +.git/refs/tags+ nhưng chúng
được cập nhật bởi các lệnh khác nhau.