10Th Translation - 1108 Words

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

@@ -399,26 +399,27 @@ Kung ikaw ay nagpo-program sa Windows at nakipagtrabaho sa mga taong hindi gumag
 Ito ay dahil ginagamit ng Windows ang parehong titik na pag-carriage-return at isang titik ng linefeed para sa mga bagong linya sa mga file nito, samantalang ginagamit lamang ng Mac at Linux na sistema ang titik na linefeed.
 Ito ay isang banayad ngunit hindi kapani-paniwalang nakakainis na katotohanan ng cross-platform na trabaho; tahimik na pinapalitan ng maraming mga editor sa Windows ang mga umiiral na patapos na linyang LF sa CRLF, o ipasok ang parehong mga patapos na linyang titik kapag pinindot ng gumagamit ang enter na key.
 
-Git can handle this by auto-converting CRLF line endings into LF when you add a file to the index, and vice versa when it checks out code onto your filesystem.
-You can turn on this functionality with the `core.autocrlf` setting.
-If you're on a Windows machine, set it to `true` -- this converts LF endings into CRLF when you check out code:
+Kaya ng Git na pangasiwaan ito sa pamamagitan ng pag-awtomatikong pagpalit sa CRLF ng pagtatapos ng linya sa LF kung iyong idagdag ang isang file sa index, at kabaliktaran kung ito ay mag checkout ng code sa iyong sistema ng file.
+
+Maari mong paganahin ang pag-aandar na ito sa pamamagitan ng `core.autocrlf` na setting.
+Kung ikaw ay nasa Windows na makina, i-set ito sa `true` -- papalitan nito ang LF na pagtatapos sa CRLF kung iyong i-check out ang code:
 
 [source,console]
 ----
 $ git config --global core.autocrlf true
 ----
 
-If you're on a Linux or Mac system that uses LF line endings, then you don't want Git to automatically convert them when you check out files; however, if a file with CRLF endings accidentally gets introduced, then you may want Git to fix it.
-You can tell Git to convert CRLF to LF on commit but not the other way around by setting `core.autocrlf` to input:
+Kung ikaw ay nasa Linux o Mac na sistema na gumagamit ng LF na pagtatapos sa linya, hindi muna kailangan ang Git na awtomatikong pagpalit sa kanila kung iyong i-check out ang mga file; subalit, kung ang file na may CRLF na pagtatapos ay aksidenting naipakilala, nararapat lang na gustohin mong ayusin ito ng Git.
+Maari mong sabihin sa Git na palitan ang CRLF sa LF sa pag-commit ngunit hindi ang kabaliktaran nito sa pagtakda ng `core.autocrlf` para sa pag-input: 
 
 [source,console]
 ----
 $ git config --global core.autocrlf input
 ----
 
-This setup should leave you with CRLF endings in Windows checkouts, but LF endings on Mac and Linux systems and in the repository.
+Ang setup na ito ay dapat nag-iiwan sa iyo ng CRLF na pagtatapos sa mga checkout sa Windows, ngunit ang LF na pagtatapos sa Mac at Linux na mga sistema at sa repositoryo.
 
-If you're a Windows programmer doing a Windows-only project, then you can turn off this functionality, recording the carriage returns in the repository by setting the config value to `false`:
+Kung ikaw ay isang Windows na programmer na gumagawa ng Windows na proyekto lamang, maaari mong patayin ang pag-aandar na ito, pagtatala sa mga carriage return sa repositoryo sa pamamagitan ng pagtakda ng `false` sa halaga ng config: 
 
 [source,console]
 ----
@@ -427,92 +428,100 @@ $ git config --global core.autocrlf false
 
 ===== `core.whitespace`
 
-Git comes preset to detect and fix some whitespace issues.
-It can look for six primary whitespace issues -- three are enabled by default and can be turned off, and three are disabled by default but can be activated.
+Ang Git ay may preset para tuklasin at ayusin ang iilang whitespace na mga isyu.
+Ito ay tumitingin sa anim na pangunahing whitespace na mga isyu -- tatlo ay pinagana sa pamamagitan ng default at maaaring patayin, at tatlo ay di-pinagana sa pamamagitan ng default ngunit pwedeng aktibahin.
+
+Ang tatlong nakapatay sa pamamagitang ng default ay ang `blank-at-eol`, kung saan ay humahanap ng mga patlang sa pagtatapos ng linya; `blank-at-eof`, kung saan ay napapansin ang mga linyang blangko sa dulo ng file; at `space-before-tab`, kung saan ay naghahanap ng mga puwang bago ang mga tab sa simula ng linya.
+
+Ang tatlong di-pinagana sa pamamagitan ng default ngunit pwedeng paganahin ay ang `indent-with-non-tab`, kung saan ay naghahanap ng mga linyang nagsisimula sa puwang imbes na sa mga tab (at kinokontrol sa pamamagitan ng `tabwidth` na opsyon); `tab-in-indent`, kung saan ay nagmamasid sa mga tab sa bahagi ng isang linya; at `cr-at-eol`, kung saan ay nagsasabi sa Git na OK ang carriage return sa dulo ng linya.
+
+Maari mong sabihin sa Git kung saan sa mga ito ang gusto mong paganahin sa pamamagitan ng pagtakda sa `core.whitespace` sa mga halagang gusto mo maaaring on o off, nakahiwalay sa kuwit
 
-The three that are turned on by default are `blank-at-eol`, which looks for spaces at the end of a line; `blank-at-eof`, which notices blank lines at the end of a file; and `space-before-tab`, which looks for spaces before tabs at the beginning of a line.
+Maari mong di-paganahin ang isang opsyun sa pamamagitan ng pag-prepend ng `-` sa harapan ng pangalan nito, o gamitin ang default na halaga sa pamamagitan ng pag-iwan nito sa pangkabuoang pagtakda sa string.
 
-The three that are disabled by default but can be turned on are `indent-with-non-tab`, which looks for lines that begin with spaces instead of tabs (and is controlled by the `tabwidth` option); `tab-in-indent`, which watches for tabs in the indentation portion of a line; and `cr-at-eol`, which tells Git that carriage returns at the end of lines are OK.
+Halimbawa, kung gusto mo ang lahat maliban nalang sa `space-before-tab` ay i-set, maaari mong gawin ito (may `trailing-space` sa pagiging short-hand upang masakop ng pareho ang `blank-at-eol` at `blank-at-eof`):
 
-You can tell Git which of these you want enabled by setting `core.whitespace` to the values you want on or off, separated by commas.
-You can disable an option by prepending a `-` in front of its name, or use the default value by leaving it out of the setting string entirely.
-For example, if you want all but `space-before-tab` to be set, you can do this (with `trailing-space` being a short-hand to cover both `blank-at-eol` and `blank-at-eof`):
 
 [source,console]
 ----
 $ git config --global core.whitespace \
     trailing-space,-space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol
 ----
 
-Or you can specify the customizing part only:
+O maaari mong tukuyin ang bahagi ng pag-angkop sa sariling pangangailagan lamang:
 
 [source,console]
 ----
 $ git config --global core.whitespace \
     -space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol
 ----
 
-Git will detect these issues when you run a `git diff` command and try to color them so you can possibly fix them before you commit.
+Matutuklasan ng Git ang mga isyung ito kapag pinatakbo mo ang `git diff` na utos at susubukan na kulayan ang mga ito upang maaari mong ayusin ang mga ito bago ka mag-commit.
+
 It will also use these values to help you when you apply patches with `git apply`.
-When you're applying patches, you can ask Git to warn you if it's applying patches with the specified whitespace issues:
+Gagamitin din nito ang mga halagang ito upang makatulong sa iyo kapag nag-aplay ka ng mga patch sa pamamagitan ng `git apply`.
+Kapag nag-aaplay ka ng mga patch, maaari mong hilingin sa Git na balaan ka kung nag-aaplay ito ng mga patch sa mga tinukoy na mga isyu sa whitespace:
+
 
 [source,console]
 ----
 $ git apply --whitespace=warn <patch>
 ----
 
-Or you can have Git try to automatically fix the issue before applying the patch:
+O maaari mong ipasubok sa Git na awtomatikong ayusin ang isyu bago ilapat ang patch:
 
 [source,console]
 ----
 $ git apply --whitespace=fix <patch>
 ----
 
-These options apply to the `git rebase` command as well.
-If you've committed whitespace issues but haven't yet pushed upstream, you can run `git rebase --whitespace=fix` to have Git automatically fix whitespace issues as it's rewriting the patches.
+Ang mga opsyun na ito ay inilapat din sa `git rebase` na utos.
+Kung ikaw ay nakagawa ng whitespace na mga isyu ngunit hindi mo na i-push na pasalungat sa agos, maaari kang magpatakbo ng `git rebase --whitespace=fix` para automatikong ayusin ng Git ang whitespace na mga isyu gaya ng muling pagsusulat sa mga patch.
 
 ==== Server Configuration
 
-Not nearly as many configuration options are available for the server side of Git, but there are a few interesting ones you may want to take note of.
+Hindi masyadong marami ang mga pagpipilian ng kompigurasyon na magagamit para sa server na bahagi sa Git, ngunit may kakaunting kawili-wili na gugustuhin mong tandaan.
 
 ===== `receive.fsckObjects`
 
-Git is capable of making sure every object received during a push still matches its SHA-1 checksum and points to valid objects.
-However, it doesn't do this by default; it's a fairly expensive operation, and might slow down the operation, especially on large repositories or pushes.
-If you want Git to check object consistency on every push, you can force it to do so by setting `receive.fsckObjects` to true:
+Ang Git ay may kakayahang tiyakin na ang bawat bagay na natanggap sa panahon ng isang push ay tumutugma pa rin sa kanyang SHA-1 na checksum at mga puntos para sa balidong mga bagay.
+Gayunpaman, hindi ito ginagawa bilang default; ito ay medyo napakagastos na operasyon, at maaring pabagalin ang operasyon, lalo na sa mga malalaking repositoryo o mga push.
+Kung gusto mong suriin ng Git ang bagay na pare-pareho sa bawat push, maaari mong sapilitang gawin ito sa pamamagitan ng pagtakda sa `receive.fsckObjects` bilang true:
 
 [source,console]
 ----
 $ git config --system receive.fsckObjects true
 ----
 
-Now, Git will check the integrity of your repository before each push is accepted to make sure faulty (or malicious) clients aren't introducing corrupt data.
+Ngayon, ang Git ay susuri sa integridad ng iyong repositoryo bago ang bawat push ay tinanggap para siguraduhin na ang may sira (o malisiyoso) na mga kliyente ay hindi nagpapakilala ng masamang data.
 
 ===== `receive.denyNonFastForwards`
 
-If you rebase commits that you've already pushed and then try to push again, or otherwise try to push a commit to a remote branch that doesn't contain the commit that the remote branch currently points to, you'll be denied.
-This is generally good policy; but in the case of the rebase, you may determine that you know what you're doing and can force-update the remote branch with a `-f` flag to your push command.
+Kung gusto mong i-rebase ang mga commit na nai-push mo na at pagkatapos ay subukang i-push ulit, o kung hindi man ay subukang i-push ang commit sa isang remote na branch na walang laman ng commit kung saan ang kasalukuyang nakaturo sa remote na branch, ikaw ay tatanggihan. 
+
+Sa pangkalahatan ito ay magandang patakaran; ngunit sa kaso ng rebase, maaari mong malaman na alam mo kung ano ang iyong ginagawa at maaring sapilitang baguhin ang remote na branch na mayroong isang `-f` na flag sa iyong push na utos.
 
-To tell Git to refuse force-pushes, set `receive.denyNonFastForwards`:
+Para sabihin sa Git na tanggihan ang mga sapilitang pag-push, itakda ang `receive.denyNonFastForwards`:
 
 [source,console]
 ----
 $ git config --system receive.denyNonFastForwards true
 ----
 
-The other way you can do this is via server-side receive hooks, which we'll cover in a bit.
-That approach lets you do more complex things like deny non-fast-forwards to a certain subset of users.
+Ang ibang paraan na maaari mong gawin ito ay sa pamamagitan ng pagtanggap sa server na bahagi na mga hook, kung saan ay tatalakayin natin maya-maya.
+Ang diskarteng iyon ay hinahayaan kang gawin ang mas kumplikadong mga bagay kagaya ng pagtanggi sa mga non-fast-forward hanggang sa tiyak na subset na mga manggagamit.
 
 ===== `receive.denyDeletes`
 
-One of the workarounds to the `denyNonFastForwards` policy is for the user to delete the branch and then push it back up with the new reference.
+Isa sa mga ibang paraan na maaring gawin sa `denyNonFastForwards` na patakaran ay para sa manggagamit upang tanggalin ang branch at pagkatapos ay i-push ito pabalik na may bagong kaugnayan.
 To avoid this, set `receive.denyDeletes` to true:
+Para maiwasan ito, itakda ang `receive.denyDeletes` sa true:
 
 [source,console]
 ----
 $ git config --system receive.denyDeletes true
 ----
 
-This denies any deletion of branches or tags -- no user can do it.
-To remove remote branches, you must remove the ref files from the server manually.
-There are also more interesting ways to do this on a per-user basis via ACLs, as you'll learn in <<_customizing_git#_an_example_git_enforced_policy>>.
+Tinanggihan nito ang anumang pagtanggal ng mga branch o mga tag -- walang manggagamit ang makagawa nito.
+Para matanggal ang remote na mga branch, kailangan mong mano-manong tanggalin ang ref na mga file galing sa server.
+Mayroon ding mas kawili-wiling mga paraan para gawin ito sa isang pangmanggagamit na basihan sa pamamagitan ng mga ACL, na matutunan mo sa <<_customizing_git#_an_example_git_enforced_policy>>.

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

@@ -1,19 +1,19 @@
 [[_git_hooks]]
-=== Git Hooks
+=== Mga Hook ng Git
 
 (((hooks)))
-Like many other Version Control Systems, Git has a way to fire off custom scripts when certain important actions occur.
-There are two groups of these hooks: client-side and server-side.
-Client-side hooks are triggered by operations such as committing and merging, while server-side hooks run on network operations such as receiving pushed commits.
-You can use these hooks for all sorts of reasons.
-
-==== Installing a Hook
-
-The hooks are all stored in the `hooks` subdirectory of the Git directory.
-In most projects, that's `.git/hooks`.
-When you initialize a new repository with `git init`, Git populates the hooks directory with a bunch of example scripts, many of which are useful by themselves; but they also document the input values of each script.
-All the examples are written as shell scripts, with some Perl thrown in, but any properly named executable scripts will work fine – you can write them in Ruby or Python or whatever language you are familiar with.
-If you want to use the bundled hook scripts, you'll have to rename them; their file names all end with `.sample`.
+Kagaya ng ibang maraming mga Sistema ng Pagkontrol sa Bersyon, ang Git ay may paraan para patakbuhin ang pasadyang mga script kung ang tiyak na importanteng mga aksyon ay nagyari.
+Mayroong dalawang grupo sa mga hook na ito: kliyente na panig at server na panig.
+Ang kliyenteng panig na mga hook ay gumagana sa pamamagitan ng mga operasyong kagaya ng pag-commit and pagsasama, habang ang server na panig na mga hook ay tumatakbo sa operasyon ng network kagaya ng pagtanggap sa na-push na mga commit.
+Maari mong gamitin ang mga hook na ito para sa lahat ng uri ng mga dahilan.
+
+==== Pag-install ng Hook
+
+Ang lahat ng mga hook ay nakalagay sa `hooks` na subdirectory ng direktoryo ng Git.
+Karamihan sa mga proyekto, ito ay `.git/hooks`.
+Kung ikaw ay nagpasimula ng bagong repositoryo sa pamamagitan ng `git init`, ang Git ay naglalagay ng mga halimbawang script sa direktoryo ng mga hook, karamihan sa mga ito ay nakakatulong sa kanilang sarili; ngunit sila ay nagdokumento sa mga halagang pinapasok sa bawat script. 
+Lahat ng mga halimbawa ay sinusulat bilang shell na mga script, na may iilang Perl na binato papasok, ngunit kahit na anong maayos na pinangalanang gumaganang mga script ay tatakbo ng mabuti - maari mong isulat sila sa Ruby o Python o kahit na anong lengguwahe na pamilyar ka. 
+Kung gusto mong gamitin ang mga hook na nakabigkis na script, kailangan mong baguhin ang pangalan nila; ang lahat ng mga pangalan ng kanilang file ay nagtatapos na may `.sample`.
 
 To enable a hook script, put a file in the `hooks` subdirectory of your .git directory that is named appropriately (without any extension) and is executable.
 From that point forward, it should be called.