Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Translation #12 #87

Open
wants to merge 7 commits into
base: master
Choose a base branch
from
Open

Translation #12 #87

wants to merge 7 commits into from

Conversation

cherryloua
Copy link

Hi everyone,

Please, take some time to review my PR. Thank you!

Copy link

@heywens heywens left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed. Kindly check the following suggestions. Thanks!

If the pusher is trying to push to multiple branches, `pre-receive` runs only once, whereas update runs once per branch they're pushing to.
Instead of reading from stdin, this script takes three arguments: the name of the reference (branch), the SHA-1 that reference pointed to before the push, and the SHA-1 the user is trying to push.
If the update script exits non-zero, only that reference is rejected; other references can still be updated.
Ang `update` na script ay masyadong kapareho sa `pre-receive` na script, maliban nalang na ito ay tumatakbo sa bawat branch na sinubakang i-push ng pusher para i-update.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nalang -> please put space character (na lang)

If the update script exits non-zero, only that reference is rejected; other references can still be updated.
Ang `update` na script ay masyadong kapareho sa `pre-receive` na script, maliban nalang na ito ay tumatakbo sa bawat branch na sinubakang i-push ng pusher para i-update.
Kung ang pusher ay sinusubukang i-push ang maraming mga branch, ang `pre-receive` ay tumaktabo ng isang beses lamang, samantalang ang pag-update ay tumatakbo nang isang beses sa bawat branch na pinu-push nila.
Sa halip na pagbabasa mula sa stdin, ang script na ito ay kukuha ng tatlong mga argumento: ang pangalan ng sanggunian (branch), ang SHA-1 na tinuturo ng sanggunian bago ang push, at ang SHA-1 na sinusubukang i-push ng manggagamit.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

na to ng

Ang `update` na script ay masyadong kapareho sa `pre-receive` na script, maliban nalang na ito ay tumatakbo sa bawat branch na sinubakang i-push ng pusher para i-update.
Kung ang pusher ay sinusubukang i-push ang maraming mga branch, ang `pre-receive` ay tumaktabo ng isang beses lamang, samantalang ang pag-update ay tumatakbo nang isang beses sa bawat branch na pinu-push nila.
Sa halip na pagbabasa mula sa stdin, ang script na ito ay kukuha ng tatlong mga argumento: ang pangalan ng sanggunian (branch), ang SHA-1 na tinuturo ng sanggunian bago ang push, at ang SHA-1 na sinusubukang i-push ng manggagamit.
Kung ang binagong script ay nagpapalabas ng di-sero, ang tinatanggihang sanggunian lamang; ang ibang sanggunian ay maaari paring baguhin.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

paring to pa ring

Sa seksyong ito, gagamitin mo ang natutunan para magtatag ng isang workflow ng Git na siyang magsusuri sa pinasadyang format ng mensahe ng commit, at magpapahintulot lamang sa ilang manggagamit para baguhin ang ilang mga subdirectory sa isang proyekto.
Ikaw ay gagawa ng mga script na client na tutulong sa developer para malaman kung ang push nila ay hindi tatanggihan at mga script na server na aktwal na nagpatupad ng mga patakaran.
Ang mga script na ipapakita namin ay isinulat sa Ruby; bahagyang dahil sa aming intelektwal na pagkawalang-galaw, ngunit dahil din sa madaling basahin ang Ruby, kahit na hindi mo kinakailangang isulat ito.
Gayunpaman, kahit anong linggwahe ay gagana - ang lahat ng halimbawa na mga script na hook na ibinahagi sa Git ay nasa alinman sa Perl o Bash, kaya maari karing makakita ng maraming mga halimbawa ng mga hook sa mga linggwaheng iyon sa pamamagitan ng pagtingin sa mga halimbawa.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

linggwahe to lenggwahe

Sa seksyong ito, gagamitin mo ang natutunan para magtatag ng isang workflow ng Git na siyang magsusuri sa pinasadyang format ng mensahe ng commit, at magpapahintulot lamang sa ilang manggagamit para baguhin ang ilang mga subdirectory sa isang proyekto.
Ikaw ay gagawa ng mga script na client na tutulong sa developer para malaman kung ang push nila ay hindi tatanggihan at mga script na server na aktwal na nagpatupad ng mga patakaran.
Ang mga script na ipapakita namin ay isinulat sa Ruby; bahagyang dahil sa aming intelektwal na pagkawalang-galaw, ngunit dahil din sa madaling basahin ang Ruby, kahit na hindi mo kinakailangang isulat ito.
Gayunpaman, kahit anong linggwahe ay gagana - ang lahat ng halimbawa na mga script na hook na ibinahagi sa Git ay nasa alinman sa Perl o Bash, kaya maari karing makakita ng maraming mga halimbawa ng mga hook sa mga linggwaheng iyon sa pamamagitan ng pagtingin sa mga halimbawa.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

karing > ka ring

A simple way to get the commit message from a commit when you have the SHA-1 value is to go to the first blank line and take everything after that.
You can do so with the `sed` command on Unix systems:
Isang simpleng paraan para makuha ang mensahe ng commit galing sa isang commit kung meron kang SHA-1 na halaga ay pagpunta sa isang blankong unang linya at kunin ang lahat pakatapon nito.
Maaari mong gawing ito sa pamamagitan ng `sed` na utos sa mga sistemang Unix:
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gawing


[source,console]
----
$ git cat-file commit ca82a6 | sed '1,/^$/d'
changed the version number
nabago ang numero ng bersyun
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bersyun > bersyon

The whole method looks like this:
Maaari mong gamitin ang ganitong kasinungalingan upang makuha ang mensahe ng commit mula sa bawat commit na sinusubukang i-push at lalabas kung makakakita ng kahit na ano na hindi tugma.

Pata ipalabas ang script at tanggihan ang push. ipalabas ang di-sero.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pata > Para

Ipagpalagay natin na gusto mong magdagdag ng mga mekanismo na gumagamit ng pagkontrol sa access na listahan (ACL) na tinutukoy kung aling mga manggagamit ang pinapayagan na i-push ang mga pagbabago sa kung aling mga bahagi ng iyong mga proyekto.
Iilang mga tao ay merong buong access, at iba ay maaari lamang mag-push ng mga pagbabago sa tiyak na subdirectories o tiyak na file.
Para ipatupad ito, isusulat mo ang mga patakarang iyon sa isa file na may pangalang `acl` na nakatira sa iyong Git na repositoryo sa server.
Kinakailangan mong ipakita sa `update` na hook ang mga panuntunang iyon, tingnan kung anong mga file ang ipinapakilala para sa lahat ng mga commit na pinu-push, at matukoy kung ang user na gumagawa ng push ay may access upang i-update ang lahat ng mga file na iyon.

The first thing you'll do is write your ACL.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please translate the last paragraph.

To enforce this, you'll write those rules to a file named `acl` that lives in your bare Git repository on the server.
You'll have the `update` hook look at those rules, see what files are being introduced for all the commits being pushed, and determine whether the user doing the push has access to update all those files.
Ipagpalagay natin na gusto mong magdagdag ng mga mekanismo na gumagamit ng pagkontrol sa access na listahan (ACL) na tinutukoy kung aling mga manggagamit ang pinapayagan na i-push ang mga pagbabago sa kung aling mga bahagi ng iyong mga proyekto.
Iilang mga tao ay merong buong access, at iba ay maaari lamang mag-push ng mga pagbabago sa tiyak na subdirectories o tiyak na file.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

at iba
could be

at ang iba

@cherryloua
Copy link
Author

Hi @heywens

Thank you for the review. I understand your concern to translate the remaining sentences of the last paragraph for this contribution. I will be translating it to my next contribution, if I'll translate it now the number of words will be lacking to my next contributions. I hope you'll understand. Thanks!

@severinolorillajr I already updated my PR from the suggested changes. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants