Translation #7: 1122 Words Translated #73
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There was a problem hiding this comment.
Hello @cherryloua. I have reviewed your work. Good job! I only have a few suggestions. Thanks.
| This combination effectively filters all C source code files through `indent` before committing. | ||
| Sa kasong ito, kapag nag-commit ka ng mga file na tumutugma sa `*.c`, ang Git ay tatakbo sa mga ito sa pamamagitan ng indent na programa bago ito i-stage nila at pagkatapos patakbuhin ang mga ito sa programa ng `cat` bago suriin ang mga ito pabalik sa disk. | ||
| Ang `cat` na programa ay talagang walang magawa: iniluwa palabas nito ang parehong data na pinasok dito. | ||
| Ang kumbinasyon na ito ay epektibong sinasala ang lahat ng mga file ng source code C sa `indent` bago ito i-commit. |
| Another interesting example gets `$Date$` keyword expansion, RCS style. | ||
| To do this properly, you need a small script that takes a filename, figures out the last commit date for this project, and inserts the date into the file. | ||
| Here is a small Ruby script that does that: | ||
| Ang isa pang interesanteng halimbawa ay nakakuha ng pagpapalawak ng keyword na `$Date$`, estilo ng RCS. |
| You can name this file `expand_date` and put it in your path. | ||
| Now, you need to set up a filter in Git (call it `dater`) and tell it to use your `expand_date` filter to smudge the files on checkout. | ||
| You'll use a Perl expression to clean that up on commit: | ||
| Ang lahat ng script ay makakakuha ng pinakabagong petsa ng pag-commit mula sa `git log` na utos, i-stick sa anumang `$Date$` na mga string na nakikita sa stdin, at i-print ang mga resulta - ito ay dapat madaling gawin sa anumang language na ikaw ay pinaka-komportable. Maaari mong pangalanan ang file na ito `expand_date` at ilagay ito sa iyong path. Sa ngayon, kailangan mong mag-set up ng isang filter sa Git (tawagin mo `dater`) at sabihin ito upang gamitin ang iyong `expand_date` na filter sa smudge ng mga file sa checkout. |
| @@ -266,7 +264,7 @@ date*.txt filter=dater | |||
| $ echo '# $Date$' > date_test.txt | |||
| ---- | |||
|
|
|||
| If you commit those changes and check out the file again, you see the keyword properly substituted: | |||
| Kung nag-commit ka ng mga pagbabago at tignan mo muli ang file, nakikita mo ang keyword na maayos na pinalitan: | |||
|
|
||
| For example, say you have some test files in a `test/` subdirectory, and it doesn't make sense to include them in the tarball export of your project. | ||
| You can add the following line to your Git attributes file: | ||
| Halimbawa, sabihin natin mayroon kang ilang mga test file sa `test/` subdirectory, at hindi ito makatwiran upang isama ang mga ito sa pag-export ng tarball ng iyong proyekto. |
|
|
||
| For instance, if you want to include a file named `LAST_COMMIT` in your project, and have metadata about the last commit automatically injected into it when `git archive` runs, you can for example set up your `.gitattributes` and `LAST_COMMIT` files like this: | ||
| Halimbawa, kung gusto mong isama ang isang file na pinangalanang `LAST_COMMIT` sa iyong proyekto, at may metadata tungkol sa huling nag-commit awtomatikong na-inject ito kapag ang `git archive` ay tumatakbo, kaya mo tulad ng halimbawang i-set up ang iyong mga `.gitattributes` at` LAST_COMMIT` na mga file tulad nito: |
There was a problem hiding this comment.
proper spacing in -
at LAST_COMMIT
| @@ -330,7 +327,7 @@ $ cat ../deployment-testing/LAST_COMMIT | |||
| Last commit date: Tue Apr 21 08:38:48 2009 -0700 by Scott Chacon | |||
| ---- | |||
|
|
|||
| The substitutions can include for example the commit message and any `git notes`, and `git log` can do simple word wrapping: | |||
| Maaaring isama sa mga pamalit halimbawa ang na i-commit mensahe at anumang `git notes`, at` git log` ay maaaring gumawa ng simpleng word wrapping: | |||
There was a problem hiding this comment.
- Maaaring isama sa mga pamalit na halimbawa ang na i-commit na mensahe
- proper spacing at - at
git log
|
|
||
| ==== Merge Strategies | ||
| ==== Pagsamahin ang Istratehiya |
There was a problem hiding this comment.
Pagsamahin ang mga Istratehiya
|
|
||
| (((merging, strategies))) | ||
| You can also use Git attributes to tell Git to use different merge strategies for specific files in your project. | ||
| One very useful option is to tell Git to not try to merge specific files when they have conflicts, but rather to use your side of the merge over someone else's. | ||
| Maaari mo ring gamitin ang mga katangian ng Git upang sabihin sa Git na gumamit ng iba't ibang mga estratehiya sa pagsasama para sa mga partikular na file sa iyong proyekto. |
There was a problem hiding this comment.
is it estratehiya or istratehiya?
| Say you have a database settings file called `database.xml` that is different in two branches, and you want to merge in your other branch without messing up the database file. | ||
| You can set up an attribute like this: | ||
| Ito ay kapaki-pakinabang kung ang isang branch sa iyong proyekto ay diverged o dalubhasa, ngunit nais mong ma-merge ang mga pagbabago sa likod mula dito, at nais mong huwag pansinin ang ilang mga file. | ||
| Sabihing mayroon kang database settings file na tinatawag na `database.xml` na iba sa dalawang branches, at nais mong pagsamahin |
jjrang11
reviewed
Feb 21, 2018
There was a problem hiding this comment.
hey @cherryloua great work! I do have a few suggestions. thanks
| In this case, when you commit files that match `*.c`, Git will run them through the indent program before it stages them and then run them through the `cat` program before it checks them back out onto disk. | ||
| The `cat` program does essentially nothing: it spits out the same data that it comes in. | ||
| This combination effectively filters all C source code files through `indent` before committing. | ||
| Sa kasong ito, kapag nag-commit ka ng mga file na tumutugma sa `*.c`, ang Git ay tatakbo sa mga ito sa pamamagitan ng indent na programa bago ito i-stage nila at pagkatapos patakbuhin ang mga ito sa programa ng `cat` bago suriin ang mga ito pabalik sa disk. |
There was a problem hiding this comment.
you could change ang Git ay tatakbo sa mga ito sa pamamagitan ng indent na programa bago ito i-stage nila to something like Idadaan ng Git ang mga ito sa indent na programa bago ito i-stage
|
|
||
| (((git commands, config))) | ||
| As you read briefly in <<_getting_started#_getting_started>>, you can specify Git configuration settings with the `git config` command. | ||
| One of the first things you did was set up your name and email address: | ||
| Habang binabasa mo agad sa <<_getting_started#_getting_started>>, matutukoy mo ang Kompigurasyon ng Git sa `git config` na utos. |
| @@ -1,28 +1,29 @@ | |||
| [[_git_config]] | |||
| === Git Configuration | |||
| === Kompigurasyon ng Git | |||
| First, a quick review: Git uses a series of configuration files to determine non-default behavior that you may want. | ||
| The first place Git looks for these values is in the system-wide `/etc/gitconfig` file, which contains settings that are applied to every user on the system and all of their repositories. | ||
| If you pass the option `--system` to `git config`, it reads and writes from this file specifically. | ||
| Una, isang mabilis na pagsusuri: Gumagamit ang Git ng isang serye ng mga kompigurasyon na file upang matukoy ang non-default behavior na maaaring gusto mo. |
| The first place Git looks for these values is in the system-wide `/etc/gitconfig` file, which contains settings that are applied to every user on the system and all of their repositories. | ||
| If you pass the option `--system` to `git config`, it reads and writes from this file specifically. | ||
| Una, isang mabilis na pagsusuri: Gumagamit ang Git ng isang serye ng mga kompigurasyon na file upang matukoy ang non-default behavior na maaaring gusto mo. | ||
| Ang unang titingnan ng Git para sa mga halagang ito ay nasa buong sistema ng `/etc/gitconfig` na file, na naglalaman ng mga setting na inilapat sa bawat user sa system at lahat ng kanilang mga repositoryo. |
There was a problem hiding this comment.
ay nasa buong sistema ng /etc/gitconfig na file to ay ang buong sistema ng /etc/gitconfig na file
sa system at lahat ng kanilang mga repositoryo to sa sistem at lahat ng kanilang mga repositoryo
|
|
||
| Finally, Git looks for configuration values in the configuration file in the Git directory (`.git/config`) of whatever repository you're currently using. | ||
| These values are specific to that single repository, and represent passing the `--local` option to `git config`. | ||
| (If you don't specify which level you want to work with, this is the default.) | ||
| Sa katapusan, hinahanap ng Git ang mga value ng konpigurasyon sa konpigurasyon na file sa direktoryo ng Git (`.git/config`) ng anumang repositoryo na kasalukuyang ginagamit mo. |
|
Thank you @josteinfrancois for taking time reviewing my work😄
…On Wed, 21 Feb 2018 at 7:01 PM Jostein Francois ***@***.***> wrote:
***@***.**** commented on this pull request.
Hello @cherryloua <https://github.com/cherryloua>. I have reviewed your
work. Good job! I only have a few suggestions. Thanks.
------------------------------
In book/08-customizing-git/sections/attributes.asc
<#73 (comment)>:
> @@ -226,13 +226,13 @@ $ git config --global filter.indent.clean indent
$ git config --global filter.indent.smudge cat
----
-In this case, when you commit files that match `*.c`, Git will run them through the indent program before it stages them and then run them through the `cat` program before it checks them back out onto disk.
-The `cat` program does essentially nothing: it spits out the same data that it comes in.
-This combination effectively filters all C source code files through `indent` before committing.
+Sa kasong ito, kapag nag-commit ka ng mga file na tumutugma sa `*.c`, ang Git ay tatakbo sa mga ito sa pamamagitan ng indent na programa bago ito i-stage nila at pagkatapos patakbuhin ang mga ito sa programa ng `cat` bago suriin ang mga ito pabalik sa disk.
+Ang `cat` na programa ay talagang walang magawa: iniluwa palabas nito ang parehong data na pinasok dito.
+Ang kumbinasyon na ito ay epektibong sinasala ang lahat ng mga file ng source code C sa `indent` bago ito i-commit.
source code sa C
------------------------------
In book/08-customizing-git/sections/attributes.asc
<#73 (comment)>:
>
-Another interesting example gets `$Date$` keyword expansion, RCS style.
-To do this properly, you need a small script that takes a filename, figures out the last commit date for this project, and inserts the date into the file.
-Here is a small Ruby script that does that:
+Ang isa pang interesanteng halimbawa ay nakakuha ng pagpapalawak ng keyword na `$Date$`, estilo ng RCS.
interesanteng to kawili-wili
------------------------------
In book/08-customizing-git/sections/attributes.asc
<#73 (comment)>:
> @@ -242,19 +242,17 @@ last_date = `git log --pretty=format:"%ad" -1`
puts data.gsub('$Date$', '$Date: ' + last_date.to_s + '$')
----
-All the script does is get the latest commit date from the `git log` command, stick that into any `$Date$` strings it sees in stdin, and print the results – it should be simple to do in whatever language you're most comfortable in.
-You can name this file `expand_date` and put it in your path.
-Now, you need to set up a filter in Git (call it `dater`) and tell it to use your `expand_date` filter to smudge the files on checkout.
-You'll use a Perl expression to clean that up on commit:
+Ang lahat ng script ay makakakuha ng pinakabagong petsa ng pag-commit mula sa `git log` na utos, i-stick sa anumang `$Date$` na mga string na nakikita sa stdin, at i-print ang mga resulta - ito ay dapat madaling gawin sa anumang language na ikaw ay pinaka-komportable. Maaari mong pangalanan ang file na ito `expand_date` at ilagay ito sa iyong path. Sa ngayon, kailangan mong mag-set up ng isang filter sa Git (tawagin mo `dater`) at sabihin ito upang gamitin ang iyong `expand_date` na filter sa smudge ng mga file sa checkout.
i-stick to idikit
------------------------------
In book/08-customizing-git/sections/attributes.asc
<#73 (comment)>:
> @@ -266,7 +264,7 @@ date*.txt filter=dater
$ echo '# $Date$' > date_test.txt
----
-If you commit those changes and check out the file again, you see the keyword properly substituted:
+Kung nag-commit ka ng mga pagbabago at tignan mo muli ang file, nakikita mo ang keyword na maayos na pinalitan:
tignan to tingnan
------------------------------
In book/08-customizing-git/sections/attributes.asc
<#73 (comment)>:
>
-For example, say you have some test files in a `test/` subdirectory, and it doesn't make sense to include them in the tarball export of your project.
-You can add the following line to your Git attributes file:
+Halimbawa, sabihin natin mayroon kang ilang mga test file sa `test/` subdirectory, at hindi ito makatwiran upang isama ang mga ito sa pag-export ng tarball ng iyong proyekto.
sabihin nating
------------------------------
In book/08-customizing-git/sections/attributes.asc
<#73 (comment)>:
>
===== `export-subst`
-When exporting files for deployment you can apply `git log`'s formatting and keyword-expansion processing to selected portions of files marked with the
-`export-subst` attribute.
+Kapag nag-export ng mga file para sa pag-deploy maaari mong gamitin ang `git log`sa pag-format at pagpapalawak ng keyword-expansion ng mga napiling bahagi ng mga file na minarkahan ng katangian ng `export-subst`.
proper spacing in -
git logsa
------------------------------
In book/08-customizing-git/sections/attributes.asc
<#73 (comment)>:
>
-For instance, if you want to include a file named `LAST_COMMIT` in your project, and have metadata about the last commit automatically injected into it when `git archive` runs, you can for example set up your `.gitattributes` and `LAST_COMMIT` files like this:
+Halimbawa, kung gusto mong isama ang isang file na pinangalanang `LAST_COMMIT` sa iyong proyekto, at may metadata tungkol sa huling nag-commit awtomatikong na-inject ito kapag ang `git archive` ay tumatakbo, kaya mo tulad ng halimbawang i-set up ang iyong mga `.gitattributes` at` LAST_COMMIT` na mga file tulad nito:
proper spacing in -
atLAST_COMMIT
------------------------------
In book/08-customizing-git/sections/attributes.asc
<#73 (comment)>:
> @@ -330,7 +327,7 @@ $ cat ../deployment-testing/LAST_COMMIT
Last commit date: Tue Apr 21 08:38:48 2009 -0700 by Scott Chacon
----
-The substitutions can include for example the commit message and any `git notes`, and `git log` can do simple word wrapping:
+Maaaring isama sa mga pamalit halimbawa ang na i-commit mensahe at anumang `git notes`, at` git log` ay maaaring gumawa ng simpleng word wrapping:
- Maaaring isama sa mga pamalit na halimbawa ang na i-commit na mensahe
- proper spacing at - atgit log
------------------------------
In book/08-customizing-git/sections/attributes.asc
<#73 (comment)>:
>
-==== Merge Strategies
+==== Pagsamahin ang Istratehiya
Pagsamahin ang mga Istratehiya
------------------------------
In book/08-customizing-git/sections/attributes.asc
<#73 (comment)>:
>
(((merging, strategies)))
-You can also use Git attributes to tell Git to use different merge strategies for specific files in your project.
-One very useful option is to tell Git to not try to merge specific files when they have conflicts, but rather to use your side of the merge over someone else's.
+Maaari mo ring gamitin ang mga katangian ng Git upang sabihin sa Git na gumamit ng iba't ibang mga estratehiya sa pagsasama para sa mga partikular na file sa iyong proyekto.
is it estratehiya or istratehiya?
------------------------------
In book/08-customizing-git/sections/attributes.asc
<#73 (comment)>:
>
-This is helpful if a branch in your project has diverged or is specialized, but you want to be able to merge changes back in from it, and you want to ignore certain files.
-Say you have a database settings file called `database.xml` that is different in two branches, and you want to merge in your other branch without messing up the database file.
-You can set up an attribute like this:
+Ito ay kapaki-pakinabang kung ang isang branch sa iyong proyekto ay diverged o dalubhasa, ngunit nais mong ma-merge ang mga pagbabago sa likod mula dito, at nais mong huwag pansinin ang ilang mga file.
+Sabihing mayroon kang database settings file na tinatawag na `database.xml` na iba sa dalawang branches, at nais mong pagsamahin
change branches to branch
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#73 (review)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AikzCa7GmL6njCuiSLl5IwjWfA1uhiv6ks5tW_drgaJpZM4SNX3Y>
.
|
|
Thank you @jjrang11 for taking time reviewing my work😄
…On Wed, 21 Feb 2018 at 7:01 PM jepu ***@***.***> wrote:
***@***.**** commented on this pull request.
hey @cherryloua <https://github.com/cherryloua> great work! I do have a
few suggestions. thanks
------------------------------
In book/08-customizing-git/sections/attributes.asc
<#73 (comment)>:
> @@ -226,13 +226,13 @@ $ git config --global filter.indent.clean indent
$ git config --global filter.indent.smudge cat
----
-In this case, when you commit files that match `*.c`, Git will run them through the indent program before it stages them and then run them through the `cat` program before it checks them back out onto disk.
-The `cat` program does essentially nothing: it spits out the same data that it comes in.
-This combination effectively filters all C source code files through `indent` before committing.
+Sa kasong ito, kapag nag-commit ka ng mga file na tumutugma sa `*.c`, ang Git ay tatakbo sa mga ito sa pamamagitan ng indent na programa bago ito i-stage nila at pagkatapos patakbuhin ang mga ito sa programa ng `cat` bago suriin ang mga ito pabalik sa disk.
you could change ang Git ay tatakbo sa mga ito sa pamamagitan ng indent
na programa bago ito i-stage nila to something like Idadaan ng Git ang
mga ito sa indent na programa bago ito i-stage
------------------------------
In book/08-customizing-git/sections/config.asc
<#73 (comment)>:
>
(((git commands, config)))
-As you read briefly in <<_getting_started#_getting_started>>, you can specify Git configuration settings with the `git config` command.
-One of the first things you did was set up your name and email address:
+Habang binabasa mo agad sa <<_getting_started#_getting_started>>, matutukoy mo ang Kompigurasyon ng Git sa `git config` na utos.
Kompigurasyon to kumpigurasyon
------------------------------
In book/08-customizing-git/sections/config.asc
<#73 (comment)>:
> @@ -1,28 +1,29 @@
[[_git_config]]
-=== Git Configuration
+=== Kompigurasyon ng Git
Kompigurasyon to Kumpigurasyon
------------------------------
In book/08-customizing-git/sections/config.asc
<#73 (comment)>:
>
-First, a quick review: Git uses a series of configuration files to determine non-default behavior that you may want.
-The first place Git looks for these values is in the system-wide `/etc/gitconfig` file, which contains settings that are applied to every user on the system and all of their repositories.
-If you pass the option `--system` to `git config`, it reads and writes from this file specifically.
+Una, isang mabilis na pagsusuri: Gumagamit ang Git ng isang serye ng mga kompigurasyon na file upang matukoy ang non-default behavior na maaaring gusto mo.
kompigurasyon to kumpigurasyon
------------------------------
In book/08-customizing-git/sections/config.asc
<#73 (comment)>:
>
-First, a quick review: Git uses a series of configuration files to determine non-default behavior that you may want.
-The first place Git looks for these values is in the system-wide `/etc/gitconfig` file, which contains settings that are applied to every user on the system and all of their repositories.
-If you pass the option `--system` to `git config`, it reads and writes from this file specifically.
+Una, isang mabilis na pagsusuri: Gumagamit ang Git ng isang serye ng mga kompigurasyon na file upang matukoy ang non-default behavior na maaaring gusto mo.
+Ang unang titingnan ng Git para sa mga halagang ito ay nasa buong sistema ng `/etc/gitconfig` na file, na naglalaman ng mga setting na inilapat sa bawat user sa system at lahat ng kanilang mga repositoryo.
ay nasa buong sistema ng/etc/gitconfigna file to ay ang buong sistema ng
/etc/gitconfigna file
sa system at lahat ng kanilang mga repositoryo to sa sistem at lahat ng
kanilang mga repositoryo
------------------------------
In book/08-customizing-git/sections/config.asc
<#73 (comment)>:
>
Finally, Git looks for configuration values in the configuration file in the Git directory (`.git/config`) of whatever repository you're currently using.
-These values are specific to that single repository, and represent passing the `--local` option to `git config`.
-(If you don't specify which level you want to work with, this is the default.)
+Sa katapusan, hinahanap ng Git ang mga value ng konpigurasyon sa konpigurasyon na file sa direktoryo ng Git (`.git/config`) ng anumang repositoryo na kasalukuyang ginagamit mo.
konpigurasyon to kumpigurasyon
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#73 (review)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AikzCVH5r0fmQELGciODry6OPO_6BzTrks5tW_eTgaJpZM4SNX3Y>
.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi guys!
Good day!
Please, take some time to review may Pull Request. Thank you!