vi/drawbacks.txt

   1 == Phụ lục A: Hạn chế của Git ==
   2
   3 There are some Git issues I've swept under the carpet. Một số có thể xử lý thủ công một cách dễ dàng bằng các script và hook, một số yêu cầu phải tổ chức lại hay xác lập lại dự án, and for the few remaining annoyances, one will just have to wait. Or better yet, bắt tay vào và giúp đỡ!
   4
   5 === Điểm yếu SHA1 ===
   6
   7 Thời gian trôi đi, những nhà mật mã đã phát hiện ra ngày càng nhiều điểm yếu của thuật toán SHA1. Already,
   8 finding hash collisions is feasible for well-funded organizations. Trong khoảng
   9 vài năm, có lẽ những chiếc PC thông thường cũng đủ sức để âm thầm
  10 làm hư hỏng một kho Git.
  11
  12 Hopefully Git will migrate to a better hash function before further research
  13 destroys SHA1.
  14
  15 === Microsoft Windows ===
  16
  17 Sử dụng Git trên hệ điều hành Microsoft Windows có vẻ hơi cồng kềnh một chút:
  18
  19 - http://cygwin.com/[Cygwin], a Linux-like environment for Windows, có chứa  http://cygwin.com/packages/git/[Git đã chuyển đổi để chạy trên Windows].
  20
  21 - http://code.google.com/p/msysgit/[Git chạy trên MSys] là một thay thế với các hỗ trợ tối thiểu nhất, bởi vì chỉ cần một số lệnh để làm một số việc thôi.
  22
  23 === Unrelated Files ===
  24
  25 Nếu dự án của bạn rất lơn và chứa rất nhiều tệp tin không có liên quan mà luôn luôn bị thay đổi, Git có thể chịu thiệt thòi hơn các hệ thống khác bởi vì các tệp tin riêng lẻ không được giữ dấu viết. Git giữ các dấu vết thay đổi cho toàn bộ dự án, điều này thường có lợi.
  26
  27 Giải pháp là chia nhỏ dự án của bạn ra, mỗi một phần bao gồm các tệp tin liên quan. Hãy sử dụng *git submodule* nếu bạn vẫn muốn giữ mọi thứ trong một kho chung.
  28
  29 === Who's Editing What? ===
  30
  31 Một số hệ thống quản lý mã nguồn bắt buộc bạn đánh dấu rõ ràng vào tệp tin theo một cách nào đó trước khi biên soạn. While this is especially annoying when this involves talking to a central server, it does have two benefits:
  32
  33   1. Diffs are quick because only the marked files need be examined.
  34
  35   2. One can discover who else is working on the file by asking the central server who has marked it for editing.
  36
  37 With appropriate scripting, you can achieve the same with Git. Điều này yêu cầu sự hợp tác từ người lập trình, who should execute particular scripts khi biên soạn một tệp tin.
  38
  39 === Lịch sử Tệp tin  ===
  40
  41 Since Git records project-wide changes, việc cấu trúc lại lịch sử của một tệp tin đơn lẻ yêu cầu more work than in version control systems that track individual files.
  42
  43 The penalty is typically slight, and well worth having as other operations are incredibly efficient. Ví dụ, `git checkout` nhanh hơn `cp -a`, and project-wide deltas compress better than collections of file-based deltas.
  44
  45 === Khởi tạo Bản sao ===
  46
  47 Việc tạo một bản sao có vẻ hơi xa xỉ hơn là checking out trong các hệ thống quản lý mã nguồn khác khi nó có lịch sử phát triển lâu dài.
  48
  49 The initial cost is worth paying in the long run, như thế các tác vụ cần làm trong tương lai sẽ nhanh chóng và không cần mạng. Tuy nhiên, trong một số hoàn cảnh, việc làm thích đáng hơn là tạo một bản sao không đầy đủ tất cả với tùy chọn `--depth`. Điều này giúp làm nhanh hơn, but the resulting clone has reduced functionality.
  50
  51 === Volatile Projects ===
  52
  53 Git was written to be fast with respect to the size of the changes. Humans make small edits from version to version. A one-liner bugfix here, a new feature there, emended comments, and so forth. But if your files are radically different in successive revisions, then on each commit, your history necessarily grows by the size of your whole project.
  54
  55 There is nothing any version control system can do about this, but standard Git users will suffer more since normally histories are cloned.
  56
  57 The reasons why the changes are so great should be examined. Perhaps file formats should be changed. Minor edits should only cause minor changes to at most a few files.
  58
  59 Or perhaps a database or backup/archival solution is what is actually being sought, not a version control system. Ví dụ, quản lý mã nguồn không thích hợp cho việc quản lý ảnh được chụp một cách định kỳ từ webcam.
  60
  61 If the files really must be constantly morphing and they really must be versioned, a possibility is to use Git in a centralized fashion. One can create shallow clones, which checks out little or no history of the project. Of course, many Git tools will be unavailable, and fixes must be submitted as patches. This is probably fine as it's unclear why anyone would want the history of wildly unstable files.
  62
  63 Một ví dụ khác là dự án phụ thuộc vào firmware, which takes the form of a huge binary file. Người sử dụng không quan tâm tới lịch sử của firmware, and updates compress poorly, vì vậy quản lý firmware để làm phình to kích thước kho chứa có lẽ là không cần thiết.
  64
  65 Trong trường hợp này, mã nguồn có thể lưu giữ trong kho Git, và tệp tin nhị phân được giữ ở nơi khác. To make life easier, one could distribute a script that uses Git để clone mã nguồn, và dùng lệnh rsync hay Git shallow clone cho firmware.
  66
  67 === Global Counter ===
  68
  69 Một số hệ quản trị mã nguồn tập trung duy trì một số nguyên dương tự động tăng lên khi có lần commit mới được chấp nhận. Git quy các thay đổi này bởi giá trị băm của chúng, điều này là tốt trong phần lớn hoàn cảnh.
  70
  71 Nhưng một số người thích có nó ở dạng số nguyên. May mắn thay, it's easy to write scripts so that with every update, the central Git repository increments an integer, perhaps in a tag, and associates it with the hash of the latest commit.
  72
  73 Every clone could maintain such a counter, but this would probably be useless, since only the central repository and its counter matters to everyone.
  74
  75 === Các thư mục rỗng ===
  76
  77 Các thư mục rỗng không được theo dõi. Create dummy files to work around this problem.
  78
  79 Xét về mặt thi hành của Git, thay vì sự thiết kế của nó, điều hạn chế này này là đáng trách. With luck, once Git gains more traction, more users will clamour for this feature and it will be implemented.
  80
  81 === Initial Commit ===
  82
  83 A stereotypical computer scientist counts từ 0, thay vì 1. Thật không may, with respect to commits, git does not adhere to this convention. Many commands are unfriendly before the initial commit. Thêm nữa, some corner cases must be handled specially, such as rebasing a branch with a different initial commit.
  84
  85 Git would benefit from defining the zero commit: as soon as a repository is constructed, HEAD được đặt cho một chuỗi ký tự bao gồm 20 byte rỗng. Lần commit đặc biệt này tương ứng với một cây (tree) rỗng, không có gốc, at some time predating all Git repositories.
  86
  87 Then running git log, for example, would inform the user that no commits have been made yet, instead of exiting with a fatal error. Similarly for other tools.
  88
  89 Tất cả các bản commit đầu tiên hoàn toàn là con cháu của bản 0 (zero).
  90
  91 Tuy nhiên, ở đây có một số vấn đề there are some problem cases unfortunately. Nếu nhiều nhánh  If several branches with different initial commits are merged together, then rebasing the result requires substantial manual intervention.
  92
  93 === Giao diện Lập lờ ===
  94
  95 Để commit A và B, nghĩa của biểu thức "A..B" và "A...B" tùy thuộc vào
  96 việc lệnh mong đó là hai điểm mút hay một vùng. Xem *git help diff*
  97 và *git help rev-parse*.