Translation #6 - 1211 Words

book/08-customizing-git/sections/attributes.asc

@@ -64,31 +64,32 @@ Ano ang ``word'' na pagsasala?
 Kailangan mong itakda ito.
 Dito mo i-configure ang Git upang gamitin ang `docx2txt` na programa para palitan ang mga dokumentong Word upang gawing nababasang mga file na teksto, na kung saan ito ay i-diff ng maayos.
 
-First, you'll need to install `docx2txt`; you can download it from http://docx2txt.sourceforge.net[].
-Follow the instructions in the `INSTALL` file to put it somewhere your shell can find it.
-Next, you'll write a wrapper script to convert output to the format Git expects.
-Create a file that's somewhere in your path called `docx2txt`, and add these contents:
+Una, kailangan mong i-install ang `docx2txt`; maari mo itong i-download sa http://docx2txt.sourceforge.net[].
+Sundin ang mga tagubilin sa `INSTALL` na file upang ilagay ito sa isang lugar na kung saan maaring mahanap ng iyong shell.
+Susunod, magsusulat ka ng script na pambalot upang i-convert ang output sa format na inaasahan ng Git.
+
+Lumikha ng isang file na sa isang lugar sa iyong landas na tinatawag na `docx2txt`, at idagdag ang mga nilalaman na ito:
 
 [source,console]
 ----
 #!/bin/bash
 docx2txt.pl "$1" -
 ----
 
-Don't forget to `chmod a+x` that file.
-Finally, you can configure Git to use this script:
+Huwag kalimutan na i-`chmod a+x` ang file na iyon.
+Sa katapusan, maaari mong i-kompigura ang Git upang magamit ang script na ito:
 
 [source,console]
 ----
 $ git config diff.word.textconv docx2txt
 ----
 
-Now Git knows that if it tries to do a diff between two snapshots, and any of the files end in `.docx`, it should run those files through the ``word'' filter, which is defined as the `docx2txt` program.
-This effectively makes nice text-based versions of your Word files before attempting to diff them.
+Alam na ngayon ng Git kung susubukang gumawa ng diff sa pagitan ng dalawang snapshot, at alinman sa mga file na nagtatapos sa `.docx`, dapat itong patakbuhin ang mga file sa pamamagitan ng ``word'' na salaan, na tinukoy bilang programa ng `docx2txt`.
+Ito ay epektibong gumagawa ng magandang bersyon ng tekstong nakabatay sa iyong Word na mga file bago sinusubukang i-diff sila. 
 
-Here's an example: Chapter 1 of this book was converted to Word format and committed in a Git repository.
-Then a new paragraph was added.
-Here's what `git diff` shows:
+Narito ang isang halimbawa: Kabanata 1 ng aklat na ito ay napalitan sa format ng Word at nakatuon sa isang repositoryong Git.
+Pagkatapos ay idinagdag ang isang bagong talata.
+Narito kung ano ang ipinapakita ng `git diff`:
 
 [source,console]
 ----
@@ -98,36 +99,38 @@ index 0b013ca..ba25db5 100644
 --- a/chapter1.docx
 +++ b/chapter1.docx
 @@ -2,6 +2,7 @@
- This chapter will be about getting started with Git. We will begin at the beginning by explaining some background on version control tools, then move on to how to get Git running on your system and finally how to get it setup to start working with. At the end of this chapter you should understand why Git is around, why you should use it and you should be all setup to do so.
- 1.1. About Version Control
- What is "version control", and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. For the examples in this book you will use software source code as the files being version controlled, though in reality you can do this with nearly any type of file on a computer.
+ Ang kabanatang ito ay tungkol sa pagsisimula sa Git. Magsisimula tayo sa simula sa pamamagitan ng pagpapaliwanag ng ilang mga background sa mga kasangkapan ng pagkontrol sa bersyon, pagkatapos ay lilipat sa kung paano makakuha ng Git na tumatakbo sa iyong sistema at sa panghuli kung paano makakuha ng setup na ito upang simulan ang pakikipagtulungan. Sa dulo ng kabanatang ito
+dapat mong maintindihan kung bakit ang Git ay nandito, bakit dapat mong gamitin ito at dapat mong i-setup ang lahat upang magawa ito.
+1.1. Tungkol sa Pagkontrol ng Bersyon
+Ano ang "pagkontrol sa bersyon", at bakit dapat kang makialam? Ang pagkontrol sa bersyon ay isang sistema na nagtatala sa mga pagbabago sa isang file o hanay ng mga file sa paglipas ng panahon upang maaari mong iurong ang mga tiyak na mga bersyon pagkalipas.   
 +Testing: 1, 2, 3.
- If you are a graphic or web designer and want to keep every version of an image or layout (which you would most certainly want to), a Version Control System (VCS) is a very wise thing to use. It allows you to revert files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also generally means that if you screw things up or lose files, you can easily recover. In addition, you get all this for very little overhead.
- 1.1.1. Local Version Control Systems
- Many people's version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they're clever). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you're in and accidentally write to the wrong file or copy over files you don't mean to.
-----
-
-Git successfully and succinctly tells us that we added the string ``Testing: 1, 2, 3.'', which is correct.
-It's not perfect – formatting changes wouldn't show up here – but it certainly works.
-
-Another interesting problem you can solve this way involves diffing image files.
-One way to do this is to run image files through a filter that extracts their EXIF information – metadata that is recorded with most image formats.
-If you download and install the `exiftool` program, you can use it to convert your images into text about the metadata, so at least the diff will show you a textual representation of any changes that happened.
-Put the following line in your `.gitattributes` file:
-
+ Kung ikaw ay taga-desinyo ng graphic o ng web at gusto mong itago ang bawat bersyon ng isang imahe o ang pagkakaayos (kung saan ay tiyak na ninanais mo ito), ang Version Control System (VCS) ay isang matalinong bagay na magagamit. Pinapayagan ka nitong ibalik ang mga file pabalik sa nakaraang estado, ibalik ang buong proyekto pabalik sa nakaraan estado, ihambing ang mga pagbabago sa paglipas ng panahon, tingnan kung sino ang huling nagbago sa isang bagay na maaaring magdulot ng problema, sino ang nagpakilala ng isang isyu at kung kailan, at marami pang iba.
+ Ang paggamit ng isang VCS sa pangkalahatan ay nangangahulugan na kung sira mo ang mga bagay o mawawala ang mga file, madali mo itong mabawi. Sa karagdagan, makukuha mo ang lahat ng ito para sa napakaliit na overhead.
+ 1.1.1. Lokal na Version Control Systems
+ Karamihan ng mga tao ay pinipili ang pagkontrol ng bersyon sa pamamagitan ng pagkopya sa mga file patungo sa ibang direktoryo (marahil isang direktoryo na may nakatala na oras, kung sila ay matalino).
+
+ Ang pamaraan na ito ay karaniwan dahil ito ay sobrang simple, ngunit ito rin ay hindi kapani-paniwalang madaling magkamali. Madaling kalimutan kung aling direktoryo ka at aksidenteng masulatan ang maling file o kopyahin ang maling mga file na hindi mo nais.
+----
+Matagumpay at maliwanag ang pagsasabi ng Git sa atin na idinagdag natin ang string na ``Testing: 1, 2, 3.'', kung saan ay tama.
+Ito ay hindi perpekto - ang mga pagbabago sa pagformat ay hindi lumantad dito - ngunit ito ay tiyak na gumagana.
+
+Isa pang kawili-wiling problema na maaari mong malutas sa paraan na ito ay nagsasangkot sa pag-diff ng mga file na imahe.
+Isang paraan sa paggamit nito ay ang pagpatakbo sa mga file na imahe sa pamamagitan ng pagsasala na nagpapalabas sa kanilang EXIF na impormasyong metadata kung saan ay nakarekord sa mga nakakaraming format ng imahe.
+Kung iyong i-download at i-install ang `exiftool` na programa, maaari mo itong gamitin upang palitan ang iyong mga imahe ng teksto tungkol sa metadata, kaya hindi bababa sa diff ang pagpapakita sa iyo ng isang tekstuwal na representasyon ng anumang mga pagbabago na nangyari.
+Ilagay ang sumusunod na linya sa iyong `.gitattributes` na file:
 [source,ini]
 ----
 *.png diff=exif
 ----
 
-Configure Git to use this tool:
+I-kompigura ang Git upang magamit ang kasangkapang ito:
 
 [source,console]
 ----
 $ git config diff.exif.textconv exiftool
 ----
 
-If you replace an image in your project and run `git diff`, you see something like this:
+Kung iyong papalitan ang isang imahe ng iyong proyekto at patakbuhin ang `git diff`, makikita mo ang isang bagay na ganito:
 
 [source,diff]
 ----
@@ -150,36 +153,37 @@ index 88839c4..4afcb7c 100644
  Bit Depth                       : 8
  Color Type                      : RGB with Alpha
 ----
-
-You can easily see that the file size and image dimensions have both changed.
+Madali mong makikita na ang laki ng file at ang sukat ng imahe ay kapwa nagbago.
 
 [[_keyword_expansion]]
-==== Keyword Expansion
+==== Pagpapalawak ng Keyword
 
 (((keyword expansion)))
-SVN- or CVS-style keyword expansion is often requested by developers used to those systems.
-The main problem with this in Git is that you can't modify a file with information about the commit after you've committed, because Git checksums the file first.
-However, you can inject text into a file when it's checked out and remove it again before it's added to a commit.
-Git attributes offers you two ways to do this.
+SVN- or CVS- na estilo sa pagpapalawak ng keyword ay madalas na hinihiling ng mga nag-develop na ginagamit sa mga sistema na iyon.
+Ang pangunahing problema nito sa Git ay hindi mo maaaring baguhin ang isang file na may impormasyon tungkol sa commit pagkatapos mong na-commit, dahil ang Git ay nauna sa pag-checksums sa file.
+
+Gayunpaman, maaari mong i-inject ng teksto sa isang file kung ito ay naka-check out at alisin ito muli bago ito idinagdag sa isang commit.
+Ang mga katangian ng Git ay nag-aalok sa iyo ng dalawang paraan upang magawa ito.
 
-First, you can inject the SHA-1 checksum of a blob into an `$Id$` field in the file automatically.
-If you set this attribute on a file or set of files, then the next time you check out that branch, Git will replace that field with the SHA-1 of the blob.
-It's important to notice that it isn't the SHA-1 of the commit, but of the blob itself.
-Put the following line in your `.gitattributes` file:
+Una, maaari mong awtomatikong i-inject ang SHA-1 na checksum ng isang blob sa isang `$Id$` na field sa file.
+Kung itinakda mo ang katangiang ito sa isang file o hanay ng mga file, pagkatapos sa susunod na i-check out mo ang branch na iyon, papalitan ng Git ang field na iyon kasama ang SHA-1 na blob.
+
+Mahalagang mapansin na hindi ito ang SHA-1 ng commit, kundi ng mismong blob.
+Ilagay ang sumusunod na linya sa iyong `.gitattributes` na file:
 
 [source,ini]
 ----
 *.txt ident
 ----
 
-Add an `$Id$` reference to a test file:
+Magdagdag ng isang `$Id$` na sanggunian sa isang file na pagsusulit:
 
 [source,console]
 ----
 $ echo '$Id$' > test.txt
 ----
 
-The next time you check out this file, Git injects the SHA-1 of the blob:
+Sa susunod na i-check out mo ang file na ito, ang Git ay mag-inject ng SHA-1 ng blob:
 
 [source,console]
 ----
@@ -189,31 +193,32 @@ $ cat test.txt
 $Id: 42812b7653c7b88933f8a9d6cad0ca16714b9bb3 $
 ----
 
-However, that result is of limited use.
-If you've used keyword substitution in CVS or Subversion, you can include a datestamp – the SHA-1 isn't all that helpful, because it's fairly random and you can't tell if one SHA-1 is older or newer than another just by looking at them.
+Gayunpaman, ang resulta ay limitado ang paggamit.
+Kung ginamit mo ang pagpapalit ng keyword sa CVS o Subversion, maaari mong isama ang isang datestamp - ang SHA-1 ay hindi masyadong kapaki-pakinabang, dahil medyo alisaga ito at hindi mo masabi kung ang isang SHA-1 ay mas matanda o mas bago kaysa sa iba pa sa pamamagitan lamang ng pagtingin sa mga ito.
 
-It turns out that you can write your own filters for doing substitutions in files on commit/checkout.
-These are called ``clean'' and ``smudge'' filters.
-In the `.gitattributes` file, you can set a filter for particular paths and then set up scripts that will process files just before they're checked out (``smudge'', see <<filters_a>>) and just before they're staged (``clean'', see <<filters_b>>).
-These filters can be set to do all sorts of fun things.
+Iyon pala ay maari kang magsulat ng sarili mong mga pagsala para sa paggawa ng mga pamalit sa mga file sa commit/checkout.
+Ang mga ito ay tinatawag na ``clean'' at ``smudge'' na mga pagsala.
+Ang sa `.gitattributes` na file, maaari kang magtakda ng pagsasala para sa mga partikular na landas at pagkatapos ay i-set up ang mga script na magpoproseso ng mga file bago pa man sila i-check out (``smudge'', tingnan <<filters_a>>) at bago pa man ang mga ito ay i-stage (``clean'', tingnan <<filters_b>>).
+Ang mga pagsala na ito ay maaaring itakda upang gawin ang lahat ng uri ng mga bagay na masaya.
 
 [[filters_a]]
-.The ``smudge'' filter is run on checkout.
-image::images/smudge.png[The ``smudge'' filter is run on checkout.]
+.Ang ``smudge'' ang pagsala ay pinapatakbo sa checkout.
+image::images/smudge.png[Ang ``smudge'' na pagsasala ay pinapatakbo sa checkout.]
 
 [[filters_b]]
-.The ``clean'' filter is run when files are staged.
-image::images/clean.png[The ``clean'' filter is run when files are staged.]
+.Ang ``clean'' na pagsasala ay pinapatakbo kung ang mga file ay naka-stage.
+image::images/clean.png[Ang ``clean'' na pagsasala ay pinapatakbo kung ang mga file ay naka-stage.]
 
-The original commit message for this feature gives a simple example of running all your C source code through the `indent` program before committing.
-You can set it up by setting the filter attribute in your `.gitattributes` file to filter `*.c` files with the ``indent'' filter:
+Ang orihinal na mensahe ng commit para sa katangian na ito ay nagbibigay ng isang simpleng halimbawa ng pagpapatakbo ng lahat ng iyong source code sa C sa pamamagitan ng `indent` na programa bago i-commit.
+Maaari mo itong i-set up sa pamamagitan ng pagtatakda ng pagsasala na katangian sa iyong `.gitattributes` na file hanggang sa `*.c` na mga file kasama na ang ``indent'' na pagsala:
 
 [source,ini]
 ----
 *.c filter=indent
 ----
 
-Then, tell Git what the ``indent'' filter does on smudge and clean:
+Pagkatapos, sabihin sa Git kung ano ang ginagawa ng pagsasala na ``indent'' sa smudge at clean:
+
 
 [source,console]
 ----