de/pot/drawbacks.po

   1 # Git Magic - A guide to using Git
   2 # This file is distributed under the GNU GENERAL PUBLIC LICENSE Version 3.
   3 # Benn Lynn <benlynn@gmail.com>, 2007.
   4 # Armin Stebich <armin@lordofbikes.de>, 2010.
   5 msgid ""
   6 msgstr ""
   7 "Project-Id-Version: Git Magic deutsch\n"
   8 "Report-Msgid-Bugs-To: bennlynn@gmail.com\n"
   9 "POT-Creation-Date: 2010-10-30 08:21+0300\n"
  10 "PO-Revision-Date: 2010-10-26 18:38+0300\n"
  11 "Last-Translator: Armin Stebich <armin@lordofbikes.de>\n"
  12 "Language-Team: de <git-magic@lordofbikes.de>\n"
  13 "Language: de\n"
  14 "MIME-Version: 1.0\n"
  15 "Content-Type: text/plain; charset=UTF-8\n"
  16 "Content-Transfer-Encoding: 8bit\n"
  17
  18 #. type: Plain text
  19 #: ../en/drawbacks.txt:2
  20 msgid "== Appendix A: Git Shortcomings =="
  21 msgstr ""
  22
  23 #. type: Plain text
  24 #: ../en/drawbacks.txt:4
  25 msgid ""
  26 "There are some Git issues I've swept under the carpet. Some can be handled "
  27 "easily with scripts and hooks, some require reorganizing or redefining the "
  28 "project, and for the few remaining annoyances, one will just have to wait. "
  29 "Or better yet, pitch in and help!"
  30 msgstr ""
  31
  32 #. type: Plain text
  33 #: ../en/drawbacks.txt:6
  34 msgid "=== SHA1 Weaknesses ==="
  35 msgstr ""
  36
  37 #. type: Plain text
  38 #: ../en/drawbacks.txt:11
  39 msgid ""
  40 "As time passes, cryptographers discover more and more SHA1 weaknesses. "
  41 "Already, finding hash collisions is feasible for well-funded organizations. "
  42 "Within years, perhaps even a typical PC will have enough computing power to "
  43 "silently corrupt a Git repository."
  44 msgstr ""
  45
  46 #. type: Plain text
  47 #: ../en/drawbacks.txt:14
  48 msgid ""
  49 "Hopefully Git will migrate to a better hash function before further research "
  50 "destroys SHA1."
  51 msgstr ""
  52
  53 #. type: Plain text
  54 #: ../en/drawbacks.txt:16
  55 msgid "=== Microsoft Windows ==="
  56 msgstr ""
  57
  58 #. type: Plain text
  59 #: ../en/drawbacks.txt:18
  60 msgid "Git on Microsoft Windows can be cumbersome:"
  61 msgstr ""
  62
  63 #. type: Plain text
  64 #: ../en/drawbacks.txt:20
  65 msgid ""
  66 "- http://cygwin.com/[Cygwin], a Linux-like environment for Windows, contains "
  67 "http://cygwin.com/packages/git/[a Windows port of Git]."
  68 msgstr ""
  69
  70 #. type: Plain text
  71 #: ../en/drawbacks.txt:22
  72 msgid ""
  73 "- http://code.google.com/p/msysgit/[Git on MSys] is an alternative requiring "
  74 "minimal runtime support, though a few of the commands need some work."
  75 msgstr ""
  76
  77 #. type: Plain text
  78 #: ../en/drawbacks.txt:24
  79 msgid "=== Unrelated Files ==="
  80 msgstr ""
  81
  82 #. type: Plain text
  83 #: ../en/drawbacks.txt:26
  84 msgid ""
  85 "If your project is very large and contains many unrelated files that are "
  86 "constantly being changed, Git may be disadvantaged more than other systems "
  87 "because single files are not tracked. Git tracks changes to the whole "
  88 "project, which is usually beneficial."
  89 msgstr ""
  90
  91 #. type: Plain text
  92 #: ../en/drawbacks.txt:28
  93 msgid ""
  94 "A solution is to break up your project into pieces, each consisting of "
  95 "related files. Use *git submodule* if you still want to keep everything in a "
  96 "single repository."
  97 msgstr ""
  98
  99 #. type: Plain text
 100 #: ../en/drawbacks.txt:30
 101 msgid "=== Who's Editing What? ==="
 102 msgstr ""
 103
 104 #. type: Plain text
 105 #: ../en/drawbacks.txt:32
 106 msgid ""
 107 "Some version control systems force you to explicitly mark a file in some way "
 108 "before editing. While this is especially annoying when this involves talking "
 109 "to a central server, it does have two benefits:"
 110 msgstr ""
 111
 112 #. type: Bullet: '  1. '
 113 #: ../en/drawbacks.txt:34
 114 msgid "Diffs are quick because only the marked files need be examined."
 115 msgstr ""
 116
 117 #. type: Bullet: '  2. '
 118 #: ../en/drawbacks.txt:36
 119 msgid ""
 120 "One can discover who else is working on the file by asking the central "
 121 "server who has marked it for editing."
 122 msgstr ""
 123
 124 #. type: Plain text
 125 #: ../en/drawbacks.txt:38
 126 msgid ""
 127 "With appropriate scripting, you can achieve the same with Git. This requires "
 128 "cooperation from the programmer, who should execute particular scripts when "
 129 "editing a file."
 130 msgstr ""
 131
 132 #. type: Plain text
 133 #: ../en/drawbacks.txt:40
 134 msgid "=== File History ==="
 135 msgstr ""
 136
 137 #. type: Plain text
 138 #: ../en/drawbacks.txt:42
 139 msgid ""
 140 "Since Git records project-wide changes, reconstructing the history of a "
 141 "single file requires more work than in version control systems that track "
 142 "individual files."
 143 msgstr ""
 144
 145 #. type: Plain text
 146 #: ../en/drawbacks.txt:44
 147 msgid ""
 148 "The penalty is typically slight, and well worth having as other operations "
 149 "are incredibly efficient. For example, `git checkout` is faster than `cp -"
 150 "a`, and project-wide deltas compress better than collections of file-based "
 151 "deltas."
 152 msgstr ""
 153
 154 #. type: Plain text
 155 #: ../en/drawbacks.txt:46
 156 msgid "=== Initial Clone ==="
 157 msgstr ""
 158
 159 #. type: Plain text
 160 #: ../en/drawbacks.txt:48
 161 msgid ""
 162 "Creating a clone is more expensive than checking out code in other version "
 163 "control systems when there is a lengthy history."
 164 msgstr ""
 165
 166 #. type: Plain text
 167 #: ../en/drawbacks.txt:50
 168 msgid ""
 169 "The initial cost is worth paying in the long run, as most future operations "
 170 "will then be fast and offline. However, in some situations, it may be "
 171 "preferable to create a shallow clone with the `--depth` option. This is much "
 172 "faster, but the resulting clone has reduced functionality."
 173 msgstr ""
 174
 175 #. type: Plain text
 176 #: ../en/drawbacks.txt:52
 177 msgid "=== Volatile Projects ==="
 178 msgstr ""
 179
 180 #. type: Plain text
 181 #: ../en/drawbacks.txt:54
 182 msgid ""
 183 "Git was written to be fast with respect to the size of the changes. Humans "
 184 "make small edits from version to version. A one-liner bugfix here, a new "
 185 "feature there, emended comments, and so forth. But if your files are "
 186 "radically different in successive revisions, then on each commit, your "
 187 "history necessarily grows by the size of your whole project."
 188 msgstr ""
 189
 190 #. type: Plain text
 191 #: ../en/drawbacks.txt:56
 192 msgid ""
 193 "There is nothing any version control system can do about this, but standard "
 194 "Git users will suffer more since normally histories are cloned."
 195 msgstr ""
 196
 197 #. type: Plain text
 198 #: ../en/drawbacks.txt:58
 199 msgid ""
 200 "The reasons why the changes are so great should be examined. Perhaps file "
 201 "formats should be changed. Minor edits should only cause minor changes to at "
 202 "most a few files."
 203 msgstr ""
 204
 205 #. type: Plain text
 206 #: ../en/drawbacks.txt:60
 207 msgid ""
 208 "Or perhaps a database or backup/archival solution is what is actually being "
 209 "sought, not a version control system. For example, version control may be "
 210 "ill-suited for managing photos periodically taken from a webcam."
 211 msgstr ""
 212
 213 #. type: Plain text
 214 #: ../en/drawbacks.txt:62
 215 msgid ""
 216 "If the files really must be constantly morphing and they really must be "
 217 "versioned, a possibility is to use Git in a centralized fashion. One can "
 218 "create shallow clones, which checks out little or no history of the project. "
 219 "Of course, many Git tools will be unavailable, and fixes must be submitted "
 220 "as patches. This is probably fine as it's unclear why anyone would want the "
 221 "history of wildly unstable files."
 222 msgstr ""
 223
 224 #. type: Plain text
 225 #: ../en/drawbacks.txt:64
 226 msgid ""
 227 "Another example is a project depending on firmware, which takes the form of "
 228 "a huge binary file. The history of the firmware is uninteresting to users, "
 229 "and updates compress poorly, so firmware revisions would unnecessarily blow "
 230 "up the size of the repository."
 231 msgstr ""
 232
 233 #. type: Plain text
 234 #: ../en/drawbacks.txt:66
 235 msgid ""
 236 "In this case, the source code should be stored in a Git repository, and the "
 237 "binary file should be kept separately. To make life easier, one could "
 238 "distribute a script that uses Git to clone the code, and rsync or a Git "
 239 "shallow clone for the firmware."
 240 msgstr ""
 241
 242 #. type: Plain text
 243 #: ../en/drawbacks.txt:68
 244 msgid "=== Global Counter ==="
 245 msgstr ""
 246
 247 #. type: Plain text
 248 #: ../en/drawbacks.txt:70
 249 msgid ""
 250 "Some centralized version control systems maintain a positive integer that "
 251 "increases when a new commit is accepted. Git refers to changes by their "
 252 "hash, which is better in many circumstances."
 253 msgstr ""
 254
 255 #. type: Plain text
 256 #: ../en/drawbacks.txt:72
 257 msgid ""
 258 "But some people like having this integer around. Luckily, it's easy to write "
 259 "scripts so that with every update, the central Git repository increments an "
 260 "integer, perhaps in a tag, and associates it with the hash of the latest "
 261 "commit."
 262 msgstr ""
 263
 264 #. type: Plain text
 265 #: ../en/drawbacks.txt:74
 266 msgid ""
 267 "Every clone could maintain such a counter, but this would probably be "
 268 "useless, since only the central repository and its counter matters to "
 269 "everyone."
 270 msgstr ""
 271
 272 #. type: Plain text
 273 #: ../en/drawbacks.txt:76
 274 msgid "=== Empty Subdirectories ==="
 275 msgstr ""
 276
 277 #. type: Plain text
 278 #: ../en/drawbacks.txt:78
 279 msgid ""
 280 "Empty subdirectories cannot be tracked. Create dummy files to work around "
 281 "this problem."
 282 msgstr ""
 283
 284 #. type: Plain text
 285 #: ../en/drawbacks.txt:80
 286 msgid ""
 287 "The current implementation of Git, rather than its design, is to blame for "
 288 "this drawback. With luck, once Git gains more traction, more users will "
 289 "clamour for this feature and it will be implemented."
 290 msgstr ""
 291
 292 #. type: Plain text
 293 #: ../en/drawbacks.txt:82
 294 msgid "=== Initial Commit ==="
 295 msgstr ""
 296
 297 #. type: Plain text
 298 #: ../en/drawbacks.txt:84
 299 msgid ""
 300 "A stereotypical computer scientist counts from 0, rather than 1. "
 301 "Unfortunately, with respect to commits, git does not adhere to this "
 302 "convention. Many commands are unfriendly before the initial commit. "
 303 "Additionally, some corner cases must be handled specially, such as rebasing "
 304 "a branch with a different initial commit."
 305 msgstr ""
 306
 307 #. type: Plain text
 308 #: ../en/drawbacks.txt:86
 309 msgid ""
 310 "Git would benefit from defining the zero commit: as soon as a repository is "
 311 "constructed, HEAD would be set to the string consisting of 20 zero bytes. "
 312 "This special commit represents an empty tree, with no parent, at some time "
 313 "predating all Git repositories."
 314 msgstr ""
 315
 316 #. type: Plain text
 317 #: ../en/drawbacks.txt:88
 318 msgid ""
 319 "Then running git log, for example, would inform the user that no commits "
 320 "have been made yet, instead of exiting with a fatal error. Similarly for "
 321 "other tools."
 322 msgstr ""
 323
 324 #. type: Plain text
 325 #: ../en/drawbacks.txt:90
 326 msgid "Every initial commit is implicitly a descendant of this zero commit."
 327 msgstr ""
 328
 329 #. type: Plain text
 330 #: ../en/drawbacks.txt:92
 331 msgid ""
 332 "However there are some problem cases unfortunately. If several branches with "
 333 "different initial commits are merged together, then rebasing the result "
 334 "requires substantial manual intervention."
 335 msgstr ""
 336
 337 #. type: Plain text
 338 #: ../en/drawbacks.txt:94
 339 msgid "=== Interface Quirks ==="
 340 msgstr ""
 341
 342 #. type: Plain text
 343 #: ../en/drawbacks.txt:97
 344 msgid ""
 345 "For commits A and B, the meaning of the expressions \"A..B\" and \"A...B\" "
 346 "depends on whether the command expects two endpoints or a range. See *git "
 347 "help diff* and *git help rev-parse*."
 348 msgstr ""