diff --git a/po/documentation.zh_HANS-CN.po b/po/documentation.zh_HANS-CN.po index 720e3cfa49294f290508c3d61eed2a8f816afe6a..fea532f9b107c5740f0a3f01700c80d4836a34fe 100644 --- a/po/documentation.zh_HANS-CN.po +++ b/po/documentation.zh_HANS-CN.po @@ -3,7 +3,7 @@ # This file is distributed under the same license as the Git package. # Matthias A횩hauer <mha1993@live.de>, 2019. msgid "" -msgstr "Project-Id-Version: git documentation\nReport-Msgid-Bugs-To: jn.avila@free.fr\nPOT-Creation-Date: 2022-11-26 21:11+0100\nPO-Revision-Date: 2023-02-18 23:49+0000\nLast-Translator: taotieren <admin@taotieren.com>\nLanguage-Team: LANGUAGE <LL@li.org>\nLanguage: zh_HANS-CN\nMIME-Version: 1.0\nContent-Type: text/plain; charset=UTF-8\nContent-Transfer-Encoding: 8bit\nPlural-Forms: nplurals=1; plural=0;\nX-Generator: Weblate 4.16-dev\n" +msgstr "Project-Id-Version: git documentation\nReport-Msgid-Bugs-To: jn.avila@free.fr\nPOT-Creation-Date: 2022-11-26 21:11+0100\nPO-Revision-Date: 2023-02-22 05:06+0000\nLast-Translator: 燁껃ㅄ��Ъ浴� <ttdlyu@163.com>\nLanguage-Team: LANGUAGE <LL@li.org>\nLanguage: zh_HANS-CN\nMIME-Version: 1.0\nContent-Type: text/plain; charset=UTF-8\nContent-Transfer-Encoding: 8bit\nPlural-Forms: nplurals=1; plural=0;\nX-Generator: Weblate 4.16-dev\n" #. type: Labeled list #: en/blame-options.txt:1 en/diff-options.txt:763 en/git-instaweb.txt:45 en/git-mailinfo.txt:49 en/git-mailsplit.txt:35 en/git-repack.txt:146 en/git-status.txt:31 @@ -68286,7 +68286,7 @@ msgstr "映삡세雅� \"git://example.org/path/to/repo.git\" �� URL 鴉싪˙�띶넍訝� #: en/git-bisect-lk2009.txt:2 #, no-wrap, priority:100 msgid "Fighting regressions with git bisect" -msgstr "�쭳it雅뚦늽�ζ돻鰲e넶�욃퐩��쥦" +msgstr "�쭳it雅뚦늽�ζ돻鰲e넶�욇����쥦" #. type: Title - #: en/git-bisect-lk2009.txt:8 @@ -68298,7 +68298,7 @@ msgstr "�섋쫨" #: en/git-bisect-lk2009.txt:17 #, priority:100 msgid "\"git bisect\" enables software users and developers to easily find the commit that introduced a regression. We show why it is important to have good tools to fight regressions. We describe how \"git bisect\" works from the outside and the algorithms it uses inside. Then we explain how to take advantage of \"git bisect\" to improve current practices. And we discuss how \"git bisect\" could improve in the future." -msgstr "\"Git雅뚦늽�ζ돻\"鵝욤쉴餓띄뵪�룟뭽凉��묋�낁꺗鸚잒슥�얏돻�겼폊�ε썮壤믥쉪�먧벡�귝닊餓у콝鹽뷰틙訝뷰�阿덃떏�됧��꾢램�룡씎野방뒚�욃퐩��푽�띹쫨�꾠�귝닊餓ф룒瓦겻틙 \"Git雅뚦늽�ζ돻 \"餓롥쨼�ⓨ쫩鵝뺝램鵝쒙펽餓ε룋若껃쑉�낂깿鵝욜뵪�꾤츞力뺛�귞꽫�롦닊餓ц㎗�듿쫩鵝뺝닶�� \"Git雅뚦늽�ζ돻\"�ζ뵻瓦쎾퐪�띸쉪若욆럿�귝닊餓ц퓲溫②�雅� \"Git雅뚦늽�ζ돻\"�ⓩ쑋�ε룾餓ε쫩鵝뺞뵻瓦쎼��" +msgstr "\"Git雅뚦늽�ζ돻\"鵝욤쉴餓띄뵪�룟뭽凉��묋�낁꺗鸚잒슥�얏돻�겼폊�ε썮���꾣룓雅ㅳ�귝닊餓у콝鹽뷰틙訝뷰�阿덃떏�됧��꾢램�룡씎鰲e넶�욇����푽�띹쫨�꾠�귝닊餓ф룒瓦겻틙 \"Git雅뚦늽�ζ돻 \"餓롥쨼�ⓨ쫩鵝뺝램鵝쒙펽餓ε룋若껃쑉�낂깿鵝욜뵪�꾤츞力뺛�귞꽫�롦닊餓ц㎗�듿쫩鵝뺝닶�� \"Git雅뚦늽�ζ돻\"�ζ뵻瓦쎾퐪�띸쉪鵝볣챿�귝닊餓ц퓲溫②�雅� \"Git雅뚦늽�ζ돻\"�ⓩ쑋�ε룾餓ε쫩鵝뺞뵻瓦쎼��" #. type: Title - #: en/git-bisect-lk2009.txt:20 @@ -68340,19 +68340,19 @@ msgstr "�졿�竊�\"Git雅뚦늽�ζ돻\"熬ヨ�溫←뵪�ε리�⒵돻�� \"寧т�訝ゅ쓯 #: en/git-bisect-lk2009.txt:51 #, no-wrap, priority:100 msgid "Fighting regressions overview" -msgstr "鰲e넶�욃퐩礖귟염" +msgstr "鰲e넶�욇��礖귟염" #. type: Title ~ #: en/git-bisect-lk2009.txt:54 #, no-wrap, priority:100 msgid "Regressions: a big problem" -msgstr "�욃퐩竊싦�訝ゅㄷ��쥦" +msgstr "�욇��竊싦�訝ゅㄷ��쥦" #. type: Plain text #: en/git-bisect-lk2009.txt:58 #, priority:100 msgid "Regressions are a big problem in the software industry. But it's difficult to put some real numbers behind that claim." -msgstr "�욃퐩��쉴餓띈죱訝싩쉪訝�訝ゅㄷ��쥦�귚퐜��푽�양뵪�겼춻�θ��롨퓳訝ら뿮窯섅��" +msgstr "�욇����쉴餓띈죱訝싩쉪訝�訝ゅㄷ��쥦�귚퐜��푽�양뵪�겼춻�θ��롨퓳訝ら뿮窯섅��" #. type: Plain text #: en/git-bisect-lk2009.txt:61 @@ -68418,7 +68418,7 @@ msgstr "鵝녷닊餓у룾餓η뙗役뗰펽�①렟�됭쉴餓뜸툓瓦쏂죱�배퓵�꾡빰餓룡삸�욃만 #: en/git-bisect-lk2009.txt:121 #, priority:100 msgid "Of course some kind of software is developed, then used during some time without being improved on much, and then finally thrown away. In this case, of course, regressions may not be a big problem. But on the other hand, there is a lot of big software that is continually developed and maintained during years or even tens of years by a lot of people. And as there are often many people who depend (sometimes critically) on such software, regressions are a really big problem." -msgstr "壤볡꽫竊뚧쐣雅쏂쉴餓띈˙凉��묈눣�ο펽�뜹릮�ⓧ�餘득뿶�닷냵鵝욜뵪訝�펽亦→쐣孃쀥댆孃덂ㄷ�꾣뵻瓦쏉펽���롨˙佯잌펱�귛퐪�띰펽�②퓳燁띷깄�듕툔竊뚪��閭ε룾�썰툖���訝ゅㄷ��쥦�귚퐜�╊��백씊竊뚧쐣孃덂쩀鸚㎩엹饔�뻑��뵳孃덂쩀雅뷴쑉�졾뭅�싪눛�졾뛻�졾뭅�꾣뿶�닻뇤訝띷뼪凉��묈뭽瀯닸뒪�꾠�귞뵳雅롧퍘躍멩쐣溫멨쩀雅뷰풚壅뽬퓳燁띹쉴餓띰펷�됪뿶��뀽���㎫쉪竊됵펽��餓ε썮壤믤삸訝�訝ょ쐿閭g쉪鸚㏝뿮窯섅��" +msgstr "壤볡꽫竊뚧쐣雅쏂쉴餓띈˙凉��묈눣�ο펽�뜹릮�ⓧ�餘득뿶�닷냵鵝욜뵪訝�펽亦→쐣孃쀥댆孃덂ㄷ�꾣뵻瓦쏉펽���롨˙佯잌펱�귛퐪�띰펽�②퓳燁띷깄�듕툔竊뚪��閭ε룾�썰툖���訝ゅㄷ��쥦�귚퐜�╊��백씊竊뚧쐣孃덂쩀鸚㎩엹饔�뻑��뵳孃덂쩀雅뷴쑉�졾뭅�싪눛�졾뛻�졾뭅�꾣뿶�닻뇤訝띷뼪凉��묈뭽瀯닸뒪�꾠�귞뵳雅롧퍘躍멩쐣溫멨쩀雅뷰풚壅뽬퓳燁띹쉴餓띰펷�됪뿶��뀽���㎫쉪竊됵펽��餓ε썮�����訝ょ쐿閭g쉪鸚㏝뿮窯섅��" #. type: Plain text #: en/git-bisect-lk2009.txt:128 @@ -68430,7 +68430,7 @@ msgstr "Linux�끾졇弱길삸瓦숁졆訝�訝よ쉴餓뜰�귛쫩�쒏닊餓х쐦訝�訝딯inux�끾졇 #: en/git-bisect-lk2009.txt:134 #, priority:100 msgid "The time between the first rc release and the final release is supposed to be used to test rc versions and fight bugs and especially regressions. And this time is more than 80% of the release cycle time. But this is not the end of the fight yet, as of course it continues after the release." -msgstr "餓롧К訝�訝챩c�덃쑍�경�瀯덄뎵�т퉳�당쉪�띌뿴佯붻���뵪�ζ탩瑥븈c�덃쑍�뚩㎗�쿫ug竊뚨돶�ユ삸�욃퐩bug�귟�뚩퓳餘득뿶�닷뜝�겻틙�묈툋�ⓩ쐿��80%餓δ툓�귛룕躍껃뭉訝띷꼷�녕��섉뼏瀯볠씇竊뚦썱訝튯ug�ⓨ룕躍껃릮瓦섆폏瀯㎫뺌�븀렟��" +msgstr "餓롧К訝�訝챩c�덃쑍�경�瀯덄뎵�т퉳�당쉪�띌뿴佯붻���뵪�ζ탩瑥븈c�덃쑍�뚩㎗�쿫ug竊뚨돶�ユ삸�욇����쥦�귟�뚩퓳餘득뿶�닷뜝�겻틙�묈툋�ⓩ쐿��80%餓δ툓�귛룕躍껃뭉訝띷꼷�녕��섉뼏瀯볠씇竊뚦썱訝튯ug�ⓨ룕躍껃릮瓦섆폏瀯㎫뺌�븀렟��" #. type: Plain text #: en/git-bisect-lk2009.txt:137 @@ -68448,55 +68448,55 @@ msgstr "�묈쑉�덂뭉囹쀥룭�잍�燁�엨�겻슴�ⓨ츆竊덂퐪鸚㏝뇧�꾣젒熬ュ릦亮뜹댆 #: en/git-bisect-lk2009.txt:149 #, priority:100 msgid "So regressions are fought all the time by developers, and indeed it is well known that bugs should be fixed as soon as possible, so as soon as they are found. That's why it is interesting to have good tools for this purpose." -msgstr "�졿�竊뚦��묇볶�섆��닷쑉訝롥썮壤믢퐳�쀤틝竊뚥틟若욂툓竊뚥폌���①윥竊뚪뵗瑥�틪瑥θ˙弱썲엮岳�쨳竊뚧�餓δ���룕�겼갚佯붻�弱썲엮岳�쨳�귟퓳弱길삸訝뷰�阿덃쐣也썹쉪藥ε끁�θ씨�계퓳訝ょ쎅�꾣삸孃덃쐣擁g쉪��" +msgstr "�졿�竊뚦��묇볶�섆��닷쑉訝롥썮��鵝쒏뼏雅됵펽雅뗥츩訝딉펽鴉쀦��①윥竊뚪뵗瑥�틪瑥θ˙弱썲엮岳�쨳竊뚧�餓δ���룕�겼갚佯붻�弱썲엮岳�쨳�귟퓳弱길삸訝뷰�阿덃쐣也썹쉪藥ε끁�θ씨�계퓳訝ょ쎅�꾣삸孃덃쐣擁g쉪��" #. type: Title ~ #: en/git-bisect-lk2009.txt:151 #, no-wrap, priority:100 msgid "Other tools to fight regressions" -msgstr "野방뒚�욃퐩�꾢끀餓뽩램��" +msgstr "鰲e넶�욇���꾢끀餓뽩램��" #. type: Plain text #: en/git-bisect-lk2009.txt:156 #, priority:100 msgid "So what are the tools used to fight regressions? They are nearly the same as those used to fight regular bugs. The only specific tools are test suites and tools similar as \"git bisect\"." -msgstr "" +msgstr "�d퉰竊뚨뵪雅롨㎗�녑썮���꾢램�룡삸餓�阿덂몾竊잌츆餓у뇿阿롣툗�d틳�ⓩ씎野밥퍡躍멱쭊bug�꾢램�루쎑�뚣�귛뵱訝��방츏�꾢램�룡삸役뗨캊也쀤뻑�뚨굳鴉쇌틢 \"Git雅뚦늽�ζ돻\"�꾢램�룔��" #. type: Plain text #: en/git-bisect-lk2009.txt:162 #, priority:100 msgid "Test suites are very nice. But when they are used alone, they are supposed to be used so that all the tests are checked after each commit. This means that they are not very efficient, because many tests are run for no interesting result, and they suffer from combinatorial explosion." -msgstr "" +msgstr "役뗨캊也쀤뻑��씆躍멨��꾠�귚퐜壤볟츆餓ц˙�뺟떖鵝욜뵪�띰펽若껂뺄佯붻�熬ョ뵪�ε쑉驪뤸А�먧벡�롦��ζ��됬쉪役뗨캊�귟퓳�뤷뫑��若껂뺄�꾣븞�뉐뭉訝띺쳵竊뚦썱訝븃�鸚싨탩瑥뺟쉪瓦먫죱亮뜻깹�됪꼷鸚뽫쉪瀯볠옖竊뚩�뚥툝若껂뺄鴉싧룛�곁퍍�덄쉪壤긷뱧��" #. type: Plain text #: en/git-bisect-lk2009.txt:167 #, priority:100 msgid "In fact the problem is that big software often has many different configuration options and that each test case should pass for each configuration after each commit. So if you have for each release: N configurations, M commits and T test cases, you should perform:" -msgstr "" +msgstr "雅뗥츩訝딉펽��쥦�ⓧ틢鸚㎩엹饔�뻑�싧만�됭�鸚싦툖�뚨쉪�띸쉰�됮」竊뚧캀轝→룓雅ㅵ릮竊뚧캀訝ゆ탩瑥뺟뵪堊뗩꺗佯붻��싪퓝驪뤶릉�띸쉰�귛썱閭ㅿ펽倻귝옖鵝졾�驪뤶릉�덃쑍�덻訝ら뀓營�펽M訝ゆ룓雅ㅿ펽T訝ゆ탩瑥뺟뵪堊뗰펽鵝졾틪瑥ζ돢烏뚳폏" #. type: delimited block - #: en/git-bisect-lk2009.txt:170 #, no-wrap, priority:100 msgid "N * M * T tests\n" -msgstr "" +msgstr "N * M * T 訝ゆ탩瑥�\n" #. type: Plain text #: en/git-bisect-lk2009.txt:173 #, priority:100 msgid "where N, M and T are all growing with the size your software." -msgstr "" +msgstr "�뜸릎N�갡�똖�썸삸�뤹�鵝좂쉪饔�뻑鸚㎩컦�뚦쥭�욜쉪��" #. type: Plain text #: en/git-bisect-lk2009.txt:175 #, priority:100 msgid "So very soon it will not be possible to completely test everything." -msgstr "" +msgstr "�졿�竊뚦푽恙ュ갚訝띶룾�썲����됬쉪訝쒑�瓦쏂죱役뗨캊��" #. type: Plain text #: en/git-bisect-lk2009.txt:182 #, priority:100 msgid "And if some bugs slip through your test suite, then you can add a test to your test suite. But if you want to use your new improved test suite to find where the bug slipped in, then you will either have to emulate a bisection process or you will perhaps bluntly test each commit backward starting from the \"bad\" commit you have which may be very wasteful." -msgstr "" +msgstr "�뚦쫩�쒏쐣雅쌴ug�ⓧ퐷�꾣탩瑥뺝쪞餓뜸릎繹쒑뎔雅놅펽�d퉰鵝졾룾餓ε쑉鵝좂쉪役뗨캊也쀤뻑訝�쥭�졽�訝ゆ탩瑥뺛�귚퐜��펽倻귝옖鵝졿꺍�ⓧ퐷�경뵻瓦쏁쉪役뗨캊也쀤뻑�ζ돻�캼ug繹쒑퓵�사쉪�경뼶竊뚪궍阿덁퐷弱녵툖孃쀤툖與▽뼁訝��녵맏雅뚨쉪瓦뉒쮮竊뚧닑�끺퐷阿잒�鴉싩쎍�や틙壤볟쑑餓롣퐷�� \"�� \"�먧벡凉�冶뗥릲�롦탩瑥뺞캀訝ゆ룓雅ㅿ펽瓦쇿룾�썸삸�욃만役よ뉩�꾠��" #. type: Title - #: en/git-bisect-lk2009.txt:184 @@ -68508,13 +68508,13 @@ msgstr "\"git bisect\" overview" #: en/git-bisect-lk2009.txt:187 #, no-wrap, priority:100 msgid "Starting a bisection" -msgstr "" +msgstr "凉�冶뗤틠��" #. type: Plain text #: en/git-bisect-lk2009.txt:194 #, priority:100 msgid "The first \"git bisect\" subcommand to use is \"git bisect start\" to start the search. Then bounds must be set to limit the commit space. This is done usually by giving one \"bad\" and at least one \"good\" commit. They can be passed in the initial call to \"git bisect start\" like this:" -msgstr "" +msgstr "寧т�訝よ쫨鵝욜뵪�� \"Git雅뚦늽�ζ돻\"耶먨뫝餓ㅶ삸 \"git bisect start \"�ε�冶뗦맂榮㏂�귞꽫�롥퓚窈삭�營�씁�뚧씎�먨댍�먧벡令븅뿴�귟퓳�싧만���싪퓝瀯쇿눣訝�訝� \"�� \"�뚩눛弱묇�訝� \"也� \"�꾣룓雅ㅶ씎若욅렟�꾠�귛츆餓у룾餓ε깗瓦숁졆�ⓨ닜冶뗨컘�� \"git bisect start \"�뜸폖�믭폏" #. type: delimited block - #: en/git-bisect-lk2009.txt:197 @@ -68526,7 +68526,7 @@ msgstr "$ git bisect start [BAD [GOOD...]]\n" #: en/git-bisect-lk2009.txt:200 #, priority:100 msgid "or they can be set using:" -msgstr "" +msgstr "�뽬�끻룾餓η뵪餓δ툔�밧폀溫양쉰竊�" #. type: delimited block - #: en/git-bisect-lk2009.txt:203 @@ -68550,13 +68550,13 @@ msgstr "$ git bisect good [COMMIT...]\n" #: en/git-bisect-lk2009.txt:213 #, priority:100 msgid "where BAD, GOOD and COMMIT are all names that can be resolved to a commit." -msgstr "" +msgstr "�뜸릎BAD�갍OOD�똂OMMIT�썲룾餓θ㎗�먧맏�먧벡�꾢릫燁겹��" #. type: Plain text #: en/git-bisect-lk2009.txt:216 #, priority:100 msgid "Then \"git bisect\" will checkout a commit of its choosing and ask the user to test it, like this:" -msgstr "" +msgstr "�뜹릮 \"git bisect \"鴉싩퍢�뷴츆���됪떓�꾡�訝ゆ룓雅ㅿ펽亮띈쫨黎귞뵪�룡탩瑥뺝츆竊뚦갚�뤺퓳�뤄폏" #. type: delimited block - #: en/git-bisect-lk2009.txt:221 @@ -68565,13 +68565,13 @@ msgid "" "$ git bisect start v2.6.27 v2.6.25\n" "Bisecting: 10928 revisions left to test after this (roughly 14 steps)\n" "[2ec65f8b89ea003c27ff7723525a2ee335a2b393] x86: clean up using max_low_pfn on 32-bit\n" -msgstr "" +msgstr "$ git bisect start v2.6.27 v2.6.25\nBisecting: 10928 revisions left to test after this (roughly 14 steps)\n[2ec65f8b89ea003c27ff7723525a2ee335a2b393] x86: clean up using max_low_pfn on 32-bit\n" #. type: Plain text #: en/git-bisect-lk2009.txt:229 #, priority:100 msgid "Note that the example that we will use is really a toy example, we will be looking for the first commit that has a version like \"2.6.26-something\", that is the commit that has a \"SUBLEVEL = 26\" line in the top level Makefile. This is a toy example because there are better ways to find this commit with Git than using \"git bisect\" (for example \"git blame\" or \"git log -S<string>\")." -msgstr "" +msgstr "瑥룡낏�륅펽�묇뺄弱녵슴�①쉪堊뗥춴若욇솀訝딀삸訝�訝ゅ컦�뗤풃耶먲펽�묇뺄弱녶��양К訝�訝ょ뎵�т맏 \"2.6.26-something \"�꾣룓雅ㅿ펽�녑쑉窈뜹콆 Makefile 訝�쐣 \"SUBLEVEL = 26 \"烏뚨쉪�먧벡�귟퓳�ゆ삸訝�訝ゅ컦�뗤풃耶먲펽�졽맏�ㅴ틙鵝욜뵪 \"git bisect\"竊뚩퓲�됪쎍也썹쉪�방퀡�ζ돻�계퓳訝ゆ룓雅ㅿ펷堊뗥쫩 \"git blame \"�� \"git log -S<string>\"竊됥��" #. type: Title ~ #: en/git-bisect-lk2009.txt:231 @@ -68583,13 +68583,13 @@ msgstr "" #: en/git-bisect-lk2009.txt:236 #, priority:100 msgid "At this point there are basically 2 ways to drive the search. It can be driven manually by the user or it can be driven automatically by a script or a command." -msgstr "" +msgstr "�②퓳訝��밥툓竊뚦읃�т툓�됦륵燁띷뼶凉뤸씎要긷뒯�쒐뇨�귛츆��빳�긺뵪�룡뎸�③㈀�⑨펽阿잌룾餓η뵳訝�訝よ꽊�ф닑�썰빱�ゅ뒯要긷뒯��" #. type: Plain text #: en/git-bisect-lk2009.txt:241 #, priority:100 msgid "If the user is driving it, then at each step of the search, the user will have to test the current commit and say if it is \"good\" or \"bad\" using the \"git bisect good\" or \"git bisect bad\" commands respectively that have been described above. For example:" -msgstr "" +msgstr "倻귝옖�긺뵪�룡씎要긷뒯竊뚪궍阿덂쑉�쒐뇨�꾣캀訝�閭ο펽�ⓩ댎�썲퓚窈삥탩瑥뺝퐪�띸쉪�먧벡竊뚦뭉�녶닽鵝욜뵪訝딀뻼��瓦곁쉪 \"git bisect good \"�� \"git bisect bad \"�썰빱瑥닷츆�� \"也� \"瓦섉삸 \"��\"�귝캈倻귨폏" #. type: delimited block - #: en/git-bisect-lk2009.txt:246 @@ -68598,13 +68598,13 @@ msgid "" "$ git bisect bad\n" "Bisecting: 5480 revisions left to test after this (roughly 13 steps)\n" "[66c0b394f08fd89236515c1c84485ea712a157be] KVM: kill file->f_count abuse in kvm\n" -msgstr "" +msgstr "$ git bisect bad\nBisecting: 5480 revisions left to test after this (roughly 13 steps)\n[66c0b394f08fd89236515c1c84485ea712a157be] KVM: kill file->f_count abuse in kvm\n" #. type: Plain text #: en/git-bisect-lk2009.txt:250 #, priority:100 msgid "And after a few more steps like that, \"git bisect\" will eventually find a first bad commit:" -msgstr "" +msgstr "瀯㎫뺌瓦숁졆�싷펽\"git bisect \"��瀯덁폏�얍댆寧т�訝ゅ쓯�먧벡竊�" #. type: delimited block - #: en/git-bisect-lk2009.txt:257 @@ -68632,13 +68632,13 @@ msgstr " Linux 2.6.26-rc1\n" #: en/git-bisect-lk2009.txt:261 #, ignore-ellipsis, no-wrap, priority:100 msgid ":100644 100644 5cf82581... 4492984e... M Makefile\n" -msgstr "" +msgstr ":100644 100644 5cf82581... 4492984e... M Makefile\n" #. type: Plain text #: en/git-bisect-lk2009.txt:265 #, priority:100 msgid "At this point we can see what the commit does, check it out (if it's not already checked out) or tinker with it, for example:" -msgstr "" +msgstr "�②퓳訝��밥툓竊뚧닊餓у룾餓η쐦�경룓雅ㅷ쉪�끻�竊뚧��ο펷倻귝옖若껇퓲亦→쐣熬ユ��ε눣�ο펹�뽨엶烏ε츆竊뚧캈倻귨폏" #. type: delimited block - #: en/git-bisect-lk2009.txt:271 @@ -68670,19 +68670,19 @@ msgid "" "+SUBLEVEL = 26\n" "+EXTRAVERSION = -rc1\n" " NAME = Funky Weasel is Jiggy wit it\n" -msgstr "" +msgstr "diff --git a/Makefile b/Makefile\nindex 5cf8258..4492984 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -1,7 +1,7 @@\n VERSION = 2\n PATCHLEVEL = 6\n-SUBLEVEL = 25\n-EXTRAVERSION =\n+SUBLEVEL = 26\n+EXTRAVERSION = -rc1\n NAME = Funky Weasel is Jiggy wit it\n" #. type: delimited block - #: en/git-bisect-lk2009.txt:288 #, no-wrap, priority:100 msgid " # *DOCUMENTATION*\n" -msgstr "" +msgstr " # *�뉑。*\n" #. type: Plain text #: en/git-bisect-lk2009.txt:292 #, priority:100 msgid "And when we are finished we can use \"git bisect reset\" to go back to the branch we were in before we started bisecting:" -msgstr "" +msgstr "壤볠닊餓у츑�먨릮竊뚧닊餓у룾餓δ슴�� \"git bisect reset \"�욃댆�묇뺄凉�冶뗤틠�녶뎺���①쉪�녷뵱竊�" #. type: delimited block - #: en/git-bisect-lk2009.txt:298 @@ -68692,19 +68692,19 @@ msgid "" "Checking out files: 100% (21549/21549), done.\n" "Previous HEAD position was 2ddcca3... Linux 2.6.26-rc1\n" "Switched to branch 'master'\n" -msgstr "" +msgstr "$ git bisect reset\nChecking out files: 100% (21549/21549), done.\nPrevious HEAD position was 2ddcca3... Linux 2.6.26-rc1\nSwitched to branch 'master'\n" #. type: Title ~ #: en/git-bisect-lk2009.txt:301 #, no-wrap, priority:100 msgid "Driving a bisection automatically" -msgstr "" +msgstr "�ゅ뒯要긷뒯訝�訝や틠�녷윥��" #. type: Plain text #: en/git-bisect-lk2009.txt:307 #, priority:100 msgid "The other way to drive the bisection process is to tell \"git bisect\" to launch a script or command at each bisection step to know if the current commit is \"good\" or \"bad\". To do that, we use the \"git bisect run\" command. For example:" -msgstr "" +msgstr "�╊�燁띺㈀�ⓨ늽�뚩퓵葉뗧쉪�방퀡��몜瑥� \"git bisect \"�ⓩ캀訝ゅ늽�뚧�謠ㅵ맦�ⓧ�訝よ꽊�ф닑�썰빱竊뚥빳雅녻㎗壤볟뎺�먧벡�� \"也� \"瓦섉삸 \"��\"�귟쫨�싧댆瓦쇾��뱄펽�묇뺄鵝욜뵪 \"git bisect run \"�썰빱�귝캈倻귟�竊�" #. type: delimited block - #: en/git-bisect-lk2009.txt:331 @@ -68732,71 +68732,69 @@ msgid "" "commit 2ddcca36c8bcfa251724fe342c8327451988be0d\n" "Author: Linus Torvalds <torvalds@linux-foundation.org>\n" "Date: Sat May 3 11:59:44 2008 -0700\n" -msgstr "" +msgstr "$ git bisect start v2.6.27 v2.6.25\nBisecting: 10928 revisions left to test after this (roughly 14 steps)\n[2ec65f8b89ea003c27ff7723525a2ee335a2b393] x86: clean up using max_low_pfn on 32-bit\n$\n$ git bisect run grep '^SUBLEVEL = 25' Makefile\nrunning grep ^SUBLEVEL = 25 Makefile\nBisecting: 5480 revisions left to test after this (roughly 13 steps)\n[66c0b394f08fd89236515c1c84485ea712a157be] KVM: kill file->f_count abuse in kvm\nrunning grep ^SUBLEVEL = 25 Makefile\nSUBLEVEL = 25\nBisecting: 2740 revisions left to test after this (roughly 12 steps)\n[671294719628f1671faefd4882764886f8ad08cb] V4L/DVB(7879): Adding cx18 Support for mxl5005s\n...\n...\nrunning grep ^SUBLEVEL = 25 Makefile\nBisecting: 0 revisions left to test after this (roughly 0 steps)\n[2ddcca36c8bcfa251724fe342c8327451988be0d] Linux 2.6.26-rc1\nrunning grep ^SUBLEVEL = 25 Makefile\n2ddcca36c8bcfa251724fe342c8327451988be0d is the first bad commit\ncommit 2ddcca36c8bcfa251724fe342c8327451988be0d\nAuthor: Linus Torvalds <torvalds@linux-foundation.org>\nDate: Sat May 3 11:59:44 2008 -0700\n" #. type: delimited block - #: en/git-bisect-lk2009.txt:336 -#, fuzzy, ignore-ellipsis, no-wrap, priority:100 +#, ignore-ellipsis, no-wrap, priority:100 msgid "" ":100644 100644 5cf82581... 4492984e... M Makefile\n" "bisect run success\n" -msgstr "" -":100644 100644 5cf82581... 4492984e... M Makefile\n" -"bisect run success\n" +msgstr ":100644 100644 5cf82581... 4492984e... M Makefile\nbisect run success\n" #. type: Plain text #: en/git-bisect-lk2009.txt:345 #, priority:100 msgid "In this example, we passed \"grep '^SUBLEVEL = 25' Makefile\" as parameter to \"git bisect run\". This means that at each step, the grep command we passed will be launched. And if it exits with code 0 (that means success) then git bisect will mark the current state as \"good\". If it exits with code 1 (or any code between 1 and 127 included, except the special code 125), then the current state will be marked as \"bad\"." -msgstr "" +msgstr "�②퓳訝や풃耶먧릎竊뚧닊餓ф뒍 \"grep '^SUBLEVEL = 25' Makefile \"鵝쒍맏�귝빊鴉좂퍢 \"git bisect run\"�귟퓳�뤷뫑���ⓩ캀訝ゆ�謠ㅴ릎竊뚧닊餓т폖�믥쉪grep�썰빱弱녻˙��뒯�귛쫩�쒎츆餓δ빰��0���븝펷瓦숁꼷�녕��먨뒣竊됵펽�d퉰git bisect弱녷뒍壤볟뎺�뜻�곫젃溫겻맏 \"也�\"�귛쫩�쒎츆餓δ빰��1���븝펷�뽬�끻똿��1��127阿뗩뿴�꾡뻣鵝뺜빰�곻펽�ㅴ틙�방츏餓g쟻125竊됵펽�d퉰壤볟뎺�뜻�곩컛熬ユ젃溫겻맏 \"��\"��" #. type: Plain text #: en/git-bisect-lk2009.txt:350 #, priority:100 msgid "Exit code between 128 and 255 are special to \"git bisect run\". They make it stop immediately the bisection process. This is useful for example if the command passed takes too long to complete, because you can kill it with a signal and it will stop the bisection process." -msgstr "" +msgstr "128��255阿뗩뿴�꾦���뷰빰�곫삸 \"git bisect run \"�꾤돶餘듾빰�곥�귛츆餓у룾餓θ�若껆쳦�녑걶閭㏘틠�녷윥�얕퓵葉뗣�귚풃倻귨펽倻귝옖鴉좈�믥쉪�썰빱��誤곩푽�욘뿶�닸뎺�썲츑�먲펽瓦쇿푽�됬뵪竊뚦썱訝뷰퐷��빳�ⓧ�訝や에�룡��됭�瓦쏁쮮竊뚦츆弱긴폏�쒏�雅뚦늽�ζ돻��" #. type: Plain text #: en/git-bisect-lk2009.txt:353 #, priority:100 msgid "It can also be useful in scripts passed to \"git bisect run\" to \"exit 255\" if some very abnormal situation is detected." -msgstr "" +msgstr "�ⓧ폖�믥퍢 \"git bisect run \"�꾥꽊�т릎竊뚦쫩�쒏�役뗥댆訝�雅쎿엨塋�툖閭e만�꾣깄�듸펽若껂튋��빳壅룟댆 \"exit 255 \"�꾡퐳�ⓦ��" #. type: Title ~ #: en/git-bisect-lk2009.txt:355 #, no-wrap, priority:100 msgid "Avoiding untestable commits" -msgstr "" +msgstr "�욕뀓訝띸㉢若싩쉪�먧벡" #. type: Plain text #: en/git-bisect-lk2009.txt:362 #, priority:100 msgid "Sometimes it happens that the current state cannot be tested, for example if it does not compile because there was a bug preventing it at that time. This is what the special exit code 125 is for. It tells \"git bisect run\" that the current commit should be marked as untestable and that another one should be chosen and checked out." -msgstr "" +msgstr "�됪뿶鴉싧룕�잌퐪�띸듁�곫뿞力뺞탩瑥뺟쉪�끻넻竊뚥풃倻귨펽�졽맏壤볠뿶�됦�訝ら뵗瑥�샍閭㏘틙若껆쉪煐뽬캂�귟퓳弱길삸�방츏���뷰빰��125�꾡퐳�ⓦ�귛츆�딂칹 \"git bisect run\"竊뚦퐪�띸쉪�먧벡佯붻�熬ユ젃溫겻맏訝띶룾役뗨캊竊뚦틪瑥ι�됪떓�╊�訝ゆ룓雅ㅵ뭉瓦쏂죱汝��γ��" #. type: Plain text #: en/git-bisect-lk2009.txt:366 #, priority:100 msgid "If the bisection process is driven manually, you can use \"git bisect skip\" to do the same thing. (In fact the special exit code 125 makes \"git bisect run\" use \"git bisect skip\" in the background.)" -msgstr "" +msgstr "倻귝옖e=雅뚦늽�ζ돻瓦뉒쮮��뎸�③㈀�①쉪竊뚥퐷��빳鵝욜뵪 \"git bisect skip \"�ε걳�뚧졆�꾡틟�끹��(雅뗥츩訝딉펽�방츏�꾦���뷰빰��125鵝� \"git bisect run \"�ⓨ릮�겻슴�� \"git bisect skip\"竊됥��" #. type: Plain text #: en/git-bisect-lk2009.txt:371 #, priority:100 msgid "Or if you want more control, you can inspect the current state using for example \"git bisect visualize\". It will launch gitk (or \"git log\" if the `DISPLAY` environment variable is not set) to help you find a better bisection point." -msgstr "" +msgstr "�뽬�끻쫩�쒍퐷�녘쫨�닷쩀�꾣렒�띰펽鵝졾룾餓δ슴�� \"git bisect visualize \"汝��ε퐪�띸듁�곥�귛츆弱녶맦�쮏itk竊덂쫩�쒏깹�됭�營�`DISPLAY`��쥊�섌뇧竊뚦닕��뒯 \"git log\"竊됪씎躍�뒰鵝졿돻�겻�訝ゆ쎍也썹쉪�녺븣�밤��" #. type: Plain text #: en/git-bisect-lk2009.txt:376 #, priority:100 msgid "Either way, if you have a string of untestable commits, it might happen that the regression you are looking for has been introduced by one of these untestable commits. In this case it's not possible to tell for sure which commit introduced the regression." -msgstr "" +msgstr "�좄�倻귚퐬竊뚦쫩�쒍퐷�됦�訝꿜툖��탩瑥뺟쉪�먧벡竊뚥퐷誤곫돻�꾢썮����꺗��뵳�뜸릎訝�訝や툖��탩瑥뺟쉪�먧벡凉뺝뀯�꾠�귛쑉瓦숂쭕�끻넻訝뗰펽�묇뺄訝띶룾�썹‘若싨삸�や릉�먧벡凉뺝뀯雅녶썮����" #. type: Plain text #: en/git-bisect-lk2009.txt:379 #, priority:100 msgid "So if you used \"git bisect skip\" (or the run script exited with special code 125) you could get a result like this:" -msgstr "" +msgstr "�졿�竊뚦쫩�쒍퐷鵝욜뵪 \"git bisect skip\"竊덃닑�낁퓧烏뚩꽊�т빳�방츏餓g쟻125���븝펹竊뚥퐷��빳孃쀥댆瓦숁졆�꾤퍜�쒙폏" #. type: delimited block - #: en/git-bisect-lk2009.txt:388 @@ -68809,19 +68807,19 @@ msgid "" "e15b73ad3db9b48d7d1ade32f8cd23a751fe0ace\n" "070eab2303024706f2924822bfec8b9847e4ac1b\n" "We cannot bisect more!\n" -msgstr "" +msgstr "There are only 'skip'ped commits left to test.\nThe first bad commit could be any of:\n15722f2fa328eaba97022898a305ffc8172db6b1\n78e86cf3e850bd755bb71831f42e200626fbd1e0\ne15b73ad3db9b48d7d1ade32f8cd23a751fe0ace\n070eab2303024706f2924822bfec8b9847e4ac1b\nWe cannot bisect more!\n" #. type: Title ~ #: en/git-bisect-lk2009.txt:391 #, no-wrap, priority:100 msgid "Saving a log and replaying it" -msgstr "" +msgstr "岳앭춼�ε퓱亮띌뇥�겼콝鹽�" #. type: Plain text #: en/git-bisect-lk2009.txt:395 #, priority:100 msgid "If you want to show other people your bisection process, you can get a log using for example:" -msgstr "" +msgstr "倻귝옖鵝졿꺍�묈끀餓뽨볶掠뺟ㅊ鵝좂쉪�ζ돻瓦뉒쮮竊뚥퐷��빳�ⓧ빳訝뗧쉪鹽뷰풃孃쀥댆訝�訝ゆ뿥恙쀯폏" #. type: delimited block - #: en/git-bisect-lk2009.txt:398 @@ -68833,7 +68831,7 @@ msgstr "$ git bisect log > bisect_log.txt\n" #: en/git-bisect-lk2009.txt:401 #, priority:100 msgid "And it is possible to replay it using:" -msgstr "" +msgstr "�뚥툝��빳�띷뼭掠뺟ㅊ竊�" #. type: delimited block - #: en/git-bisect-lk2009.txt:404 @@ -68851,49 +68849,49 @@ msgstr "\"git bisect\" details" #: en/git-bisect-lk2009.txt:411 #, no-wrap, priority:100 msgid "Bisection algorithm" -msgstr "" +msgstr "雅뚦늽嶸쀦퀡" #. type: Plain text #: en/git-bisect-lk2009.txt:417 #, priority:100 msgid "As the Git commits form a directed acyclic graph (DAG), finding the best bisection commit to test at each step is not so simple. Anyway Linus found and implemented a \"truly stupid\" algorithm, later improved by Junio Hamano, that works quite well." -msgstr "" +msgstr "�긴틢Git�먧벡壤€닇雅녵�訝ゆ쐣�묉뿞��쎗竊뉲AG竊됵펽�ⓩ캀訝�閭ζ돻�경�鵝녕쉪�녺븣�먧벡�ζ탩瑥뺝뭉訝띺궍阿덄��뺛�귚툖嶸→�롦졆竊똋inus�묊렟亮뜹츩�겻틙訝�燁� \"�욃만�사뱶\"�꾤츞力뺧펽�롦씎熬첡unio Hamano�배퓵竊뚧븞�쒐쎑壤볟���" #. type: Plain text #: en/git-bisect-lk2009.txt:420 #, priority:100 msgid "So the algorithm used by \"git bisect\" to find the best bisection commit when there are no skipped commits is the following:" -msgstr "" +msgstr "�졿�竊뚦퐪亦→쐣瓮녘퓝�꾣룓雅ㅶ뿶竊�\"git bisect \"�ⓩ씎野삥돻��鵝녑늽�뚧룓雅ㅷ쉪嶸쀦퀡倻귚툔竊�" #. type: Plain text #: en/git-bisect-lk2009.txt:422 #, priority:100 msgid "keep only the commits that:" -msgstr "" +msgstr "�や퓷�쇾빳訝뗧쉪�먧벡竊�" #. type: Plain text #: en/git-bisect-lk2009.txt:424 #, priority:100 msgid "are ancestor of the \"bad\" commit (including the \"bad\" commit itself)," -msgstr "" +msgstr "��\"�� \"�먧벡�꾤쪝�덌펷�끾떖 \"�� \"�먧벡�ц벴竊됵펽" #. type: Plain text #: en/git-bisect-lk2009.txt:425 #, priority:100 msgid "are not ancestor of a \"good\" commit (excluding the \"good\" commits)." -msgstr "" +msgstr "��\"也� \"�먧벡�꾤쪝�덌펷訝띶똿�� \"也� \"�먧벡竊됥��" #. type: Plain text #: en/git-bisect-lk2009.txt:427 #, priority:100 msgid "This means that we get rid of the uninteresting commits in the DAG." -msgstr "" +msgstr "瓦숁꼷�녕��묇뺄�녻꽦雅낪AG訝�뿞擁g쉪�먧벡��" #. type: Plain text #: en/git-bisect-lk2009.txt:429 #, priority:100 msgid "For example if we start with a graph like this:" -msgstr "" +msgstr "堊뗥쫩竊뚦쫩�쒏닊餓т퍗訝�訝よ퓳�루쉪�얍�冶뗰폏" #. type: delimited block - #: en/git-bisect-lk2009.txt:438 @@ -68906,7 +68904,7 @@ msgid "" "Y---G-W---W\n" " \\ / \\\n" "Y-Y X-X-X-X\n" -msgstr "" +msgstr "G-Y-G-W-W-W-X-X-X-X\n\t \\ /\n\t W-W-B\n\t /\nY---G-W---W\n \\ / \\\nY-Y X-X-X-X\n" #. type: delimited block - #: en/git-bisect-lk2009.txt:440 @@ -68918,7 +68916,7 @@ msgstr "-> 壅계퓳�↑러 ->\n" #: en/git-bisect-lk2009.txt:445 #, priority:100 msgid "where B is the \"bad\" commit, \"G\" are \"good\" commits and W, X, and Y are other commits, we will get the following graph after this first step:" -msgstr "" +msgstr "�뜸릎B�� \"�� \"�꾣룓雅ㅿ펽\"G \"�� \"也� \"�꾣룓雅ㅿ펽W�갲�갳��끀餓뽫쉪�먧벡竊뚨퍘瓦뉓퓳寧т�閭ο펽�묇뺄鴉싧풓�겻빳訝뗧쉪�억폏" #. type: delimited block - #: en/git-bisect-lk2009.txt:452 @@ -68940,13 +68938,13 @@ msgstr "" #: en/git-bisect-lk2009.txt:457 #, priority:100 msgid "So only the W and B commits will be kept. Because commits X and Y will have been removed by rules a) and b) respectively, and because commits G are removed by rule b) too." -msgstr "" +msgstr "��餓ε룵�뎉�똁�꾣룓雅ㅴ폏熬ヤ퓷�쇻�귛썱訝튪�똜�꾣룓雅ㅵ컛�녶닽熬ヨ쭊�셙)�똟)���좈솮竊뚩�뚥툝G�꾣룓雅ㅴ튋熬ヨ쭊�셚)���좈솮��" #. type: Plain text #: en/git-bisect-lk2009.txt:460 #, priority:100 msgid "Note for Git users, that it is equivalent as keeping only the commit given by:" -msgstr "" +msgstr "瑥룡낏�륅펽野밥틢Git�ⓩ댎�θ�竊뚩퓳�멨퐪雅롥룵岳앯븰雅녷�瀯숂쉪瓦쇾틳�먧벡竊�" #. type: delimited block - #: en/git-bisect-lk2009.txt:463 @@ -68958,7 +68956,7 @@ msgstr "git rev-list BAD --not GOOD1 GOOD2...\n" #: en/git-bisect-lk2009.txt:468 #, priority:100 msgid "Also note that we don't require the commits that are kept to be descendants of a \"good\" commit. So in the following example, commits W and Z will be kept:" -msgstr "" +msgstr "��쨼瑥룡낏�륅펽�묇뺄亮뜸툖誤곫콆熬ヤ퓷�숂쉪�먧벡恙낂』�� \"也� \"�먧벡�꾢릮餓c�귝�餓ε쑉訝뗩씊�꾡풃耶먧릎竊똚�똝�꾣룓雅ㅵ컛熬ヤ퓷�숋폏" #. type: delimited block - #: en/git-bisect-lk2009.txt:473 @@ -68967,19 +68965,19 @@ msgid "" "G-W-W-W-B\n" " /\n" "Z-Z\n" -msgstr "" +msgstr "G-W-W-W-B\n /\nZ-Z\n" #. type: Plain text #: en/git-bisect-lk2009.txt:477 #, priority:100 msgid "starting from the \"good\" ends of the graph, associate to each commit the number of ancestors it has plus one" -msgstr "" +msgstr "餓롥쎗訝� \"也� \"�꾡륵塋��冶뗰펽弱녷캀訝ゆ룓雅ㅷ쉪曄뽩뀍�곈뇧�졽툓訝�訝ゅ뭉訝롣퉳�멨뀽��" #. type: Plain text #: en/git-bisect-lk2009.txt:480 #, priority:100 msgid "For example with the following graph where H is the \"bad\" commit and A and D are some parents of some \"good\" commits:" -msgstr "" +msgstr "堊뗥쫩竊뚥툔�얌릎H�� \"�� \"�꾣룓雅ㅿ펽A�똃���雅� \"也� \"�꾣룓雅ㅷ쉪�뜻룓雅ㅿ폏" #. type: delimited block - #: en/git-bisect-lk2009.txt:487 @@ -68990,13 +68988,13 @@ msgid "" " F-G-H\n" " /\n" "D---E\n" -msgstr "" +msgstr "A-B-C\n \\\n F-G-H\n /\nD---E\n" #. type: Plain text #: en/git-bisect-lk2009.txt:490 #, priority:100 msgid "this will give:" -msgstr "" +msgstr "瓦쇿컛瀯쇿눣竊�" #. type: delimited block - #: en/git-bisect-lk2009.txt:498 @@ -69020,19 +69018,19 @@ msgstr "" #: en/git-bisect-lk2009.txt:501 #, priority:100 msgid "associate to each commit: min(X, N - X)" -msgstr "" +msgstr "�녘걫�경캀訝ゆ룓雅ㅿ폏 min竊늌竊� N - X竊�" #. type: Plain text #: en/git-bisect-lk2009.txt:504 #, priority:100 msgid "where X is the value associated to the commit in step 2) and N is the total number of commits in the graph." -msgstr "" +msgstr "�뜸릎X��툗閭ιい2訝�쉪�먧벡�멨뀽�꾣빊�쇽펽N��쎗訝�쉪�먧벡�삥빊��" #. type: Plain text #: en/git-bisect-lk2009.txt:506 #, priority:100 msgid "In the above example we have N = 8, so this will give:" -msgstr "" +msgstr "�ⓧ툓�®쉪堊뗥춴訝�펽�묇뺄�덻=8竊뚧�餓θ퓳弱녶풓�곤폏" #. type: delimited block - #: en/git-bisect-lk2009.txt:514 @@ -69056,43 +69054,43 @@ msgstr "" #: en/git-bisect-lk2009.txt:518 #, priority:100 msgid "the best bisection point is the commit with the highest associated number" -msgstr "" +msgstr "��鵝녑늽�뚨궧��끁�됪�遙섇뀽�붹빊�꾣룓雅�" #. type: Plain text #: en/git-bisect-lk2009.txt:520 #, priority:100 msgid "So in the above example the best bisection point is commit C." -msgstr "" +msgstr "��餓ε쑉訝딃씊�꾡풃耶먧릎竊뚧�也썹쉪�녺븣�방삸C��" #. type: Plain text #: en/git-bisect-lk2009.txt:522 #, priority:100 msgid "note that some shortcuts are implemented to speed up the algorithm" -msgstr "" +msgstr "瑥룡낏�륅펽瓦숅뇤若욄뼺雅녵�雅쎾엮�룡뼶凉뤶빳�좈�잏츞力�" #. type: Plain text #: en/git-bisect-lk2009.txt:528 #, priority:100 msgid "As we know N from the beginning, we know that min(X, N - X) can't be greater than N/2. So during steps 2) and 3), if we would associate N/2 to a commit, then we know this is the best bisection point. So in this case we can just stop processing any other commit and return the current commit." -msgstr "" +msgstr "�긴틢�묇뺄餓롣�凉�冶뗥갚�ι걪N竊뚧�餓η윥�뱈in(X, N - X)訝띶룾�썲ㄷ雅랲/2�귝�餓ε쑉閭ιい2竊됧뭽3竊됦릎竊뚦쫩�쒏닊餓у컛N/2訝롣�訝ゆ룓雅ㅷ쎑�녘걫竊뚪궍阿덃닊餓у갚�ι걪瓦숁삸訝�訝ゆ�鵝녕쉪�녺븣�밤�귝�餓ε쑉瓦숂쭕�끻넻訝뗰펽�묇뺄��빳�닸렏�쒏�鸚꾤릤餓삡퐬�뜸퍟�꾣룓雅ㅿ펽亮띈퓭�욃퐪�띸쉪�먧벡��" #. type: Title ~ #: en/git-bisect-lk2009.txt:530 #, no-wrap, priority:100 msgid "Bisection algorithm debugging" -msgstr "" +msgstr "雅뚦늽力뺟츞力뺠컘瑥�" #. type: Plain text #: en/git-bisect-lk2009.txt:534 #, priority:100 msgid "For any commit graph, you can see the number associated with each commit using \"git rev-list --bisect-all\"." -msgstr "" +msgstr "野밥틢餓삡퐬�먧벡�억펽鵝졾룾餓η뵪 \"git rev-list --bisect-all \"�η쐦訝롦캀訝ゆ룓雅ㅷ쎑�녕쉪�겼춻��" #. type: Plain text #: en/git-bisect-lk2009.txt:536 #, priority:100 msgid "For example, for the above graph, a command like:" -msgstr "" +msgstr "堊뗥쫩竊뚦�雅롣툓�®쉪�얕〃竊뚥슴�ⓨ쫩訝뗥뫝餓ㅿ폏" #. type: delimited block - #: en/git-bisect-lk2009.txt:539 @@ -69104,7 +69102,7 @@ msgstr "$ git rev-list --bisect-all BAD --not GOOD1 GOOD2\n" #: en/git-bisect-lk2009.txt:542 #, priority:100 msgid "would output something like:" -msgstr "" +msgstr "鴉싪풏�븀굳鴉쇘쉪�끻�竊�" #. type: delimited block - #: en/git-bisect-lk2009.txt:552 @@ -69118,139 +69116,139 @@ msgid "" "a3864d4f32a3bf5ed177ddef598490a08760b70d (dist=1)\n" "a41baa717dd74f1180abf55e9341bc7a0bb9d556 (dist=1)\n" "9e622a6dad403b71c40979743bb9d5be17b16bd6 (dist=0)\n" -msgstr "" +msgstr "e15b73ad3db9b48d7d1ade32f8cd23a751fe0ace (dist=3)\n15722f2fa328eaba97022898a305ffc8172db6b1 (dist=2)\n78e86cf3e850bd755bb71831f42e200626fbd1e0 (dist=2)\na1939d9a142de972094af4dde9a544e577ddef0e (dist=2)\n070eab2303024706f2924822bfec8b9847e4ac1b (dist=1)\na3864d4f32a3bf5ed177ddef598490a08760b70d (dist=1)\na41baa717dd74f1180abf55e9341bc7a0bb9d556 (dist=1)\n9e622a6dad403b71c40979743bb9d5be17b16bd6 (dist=0)\n" #. type: Title ~ #: en/git-bisect-lk2009.txt:555 #, no-wrap, priority:100 msgid "Bisection algorithm discussed" -msgstr "" +msgstr "溫②�雅뚦늽嶸쀦퀡" #. type: Plain text #: en/git-bisect-lk2009.txt:561 #, priority:100 msgid "First let's define \"best bisection point\". We will say that a commit X is a best bisection point or a best bisection commit if knowing its state (\"good\" or \"bad\") gives as much information as possible whether the state of the commit happens to be \"good\" or \"bad\"." -msgstr "" +msgstr "腰뽩뀍溫⒵닊餓у츣阿됤�쒏�鵝념틠�녺궧�앫�귛쫩�쒐윥�볞�訝ゆ룓雅ㅷ쉪�뜻��(�쒎��앮닑�쒎쓯��)�썲갹��꺗鸚싧쑑�먧풘�먧벡�뜻�곫삸�쒎��앲퓲���쒎쓯�앯쉪岳→겘竊뚧닊餓у갚燁겼츆訝뷸�鵝념틠�녺궧�뽪�鵝념틠�녷룓雅ㅳ��" #. type: Plain text #: en/git-bisect-lk2009.txt:564 #, priority:100 msgid "This means that the best bisection commits are the commits where the following function is maximum:" -msgstr "" +msgstr "瓦숁꼷�녕���也썹쉪雅뚦늽�먧벡��빳訝뗥눦�경�鸚㎫쉪�먧벡竊�" #. type: delimited block - #: en/git-bisect-lk2009.txt:567 #, no-wrap, priority:100 msgid "f(X) = min(information_if_good(X), information_if_bad(X))\n" -msgstr "" +msgstr "f(X) = min(information_if_good(X), information_if_bad(X))\n" #. type: Plain text #: en/git-bisect-lk2009.txt:571 #, priority:100 msgid "where information_if_good(X) is the information we get if X is good and information_if_bad(X) is the information we get if X is bad." -msgstr "" +msgstr "�뜸릎information_if_good竊늌竊됪삸X也썸뿶�묇뺄�룟풓�꾡에��펽information_if_bad竊늌竊됪삸X�뤸뿶�묇뺄孃쀥댆�꾡에����" #. type: Plain text #: en/git-bisect-lk2009.txt:580 #, priority:100 msgid "Now we will suppose that there is only one \"first bad commit\". This means that all its descendants are \"bad\" and all the other commits are \"good\". And we will suppose that all commits have an equal probability of being good or bad, or of being the first bad commit, so knowing the state of c commits gives always the same amount of information wherever these c commits are on the graph and whatever c is. (So we suppose that these commits being for example on a branch or near a good or a bad commit does not give more or less information)." -msgstr "" +msgstr "�겼쑉�묇뺄�뉓��ゆ쐣訝�轝△�쒐К訝�轝↓뵗瑥�룓雅ㅲ�앫�귟퓳�뤷뫑��若껆쉪���됧릮餓i꺗���쒎쓯�꾟�앾펽�뚧��됧끀餓뽪룓雅ㅹ꺗���쒎��꾟�앫�귝닊餓у걞溫얏��됬쉪�먧벡�썸쐣�멨릪�꾣쫩�뉑삸也썹쉪�뽩쓯�꾬펽�뽬�끾삸寧т�訝ら뵗瑥�쉪�먧벡竊뚧�餓η윥�밹�먧벡�꾤듁�곭퍢�븀쉪岳→겘�삥삸�멨릪�꾣뿞溫븃퓳雅쌵�먧벡�ⓨ쎗訝딁쉪�や릉鵝띸쉰竊뚧뿞溫튰���阿덀��(��餓ζ닊餓у걞溫얕퓳雅쎿룓雅ㅶ삸�ⓧ�訝ゅ늽��툓竊뚧닑�끻쑉訝�訝ゅ��꾣닑�뤹쉪�먧벡�꾥퓩竊뚥툖鴉싩퍢�뷸쎍鸚싨닑�닷컩�꾡에��)��" #. type: Plain text #: en/git-bisect-lk2009.txt:582 #, priority:100 msgid "Let's also suppose that we have a cleaned up graph like one after step" -msgstr "" +msgstr "�묇뺄瓦섇걞溫얏닊餓ф쐣訝�訝ゆ툍�녻퓝�꾢쎗烏⑨펽堊뗥쫩訝�訝ゆ�謠ㅵ릮" #. type: Plain text #: en/git-bisect-lk2009.txt:585 #, priority:100 msgid "in the bisection algorithm above. This means that we can measure the information we get in terms of number of commit we can remove from the graph.." -msgstr "" +msgstr "�ⓧ툓�®쉪雅뚦늽嶸쀦퀡訝��귟퓳�뤷뫑���묇뺄��빳�방뜮��빳餓롥쎗訝�닠�ㅷ쉪�먧벡�곈뇧�θ �뤸닊餓ц렩孃쀧쉪岳→겘��" #. type: Plain text #: en/git-bisect-lk2009.txt:587 #, priority:100 msgid "And let's take a commit X in the graph." -msgstr "" +msgstr "溫⒵닊餓у쑉�얌릎�먧벡訝�訝� X��" #. type: Plain text #: en/git-bisect-lk2009.txt:590 #, priority:100 msgid "If X is found to be \"good\", then we know that its ancestors are all \"good\", so we want to say that:" -msgstr "" +msgstr "倻귝옖�묊렟X���쒎��앯쉪竊뚪궍阿덃닊餓х윥�볟츆�꾤쪝�덆꺗���쒎��앯쉪竊뚧�餓ζ닊餓ф꺍瑥댐폏" #. type: delimited block - #: en/git-bisect-lk2009.txt:593 #, no-wrap, priority:100 msgid "information_if_good(X) = number_of_ancestors(X) (TRUE)\n" -msgstr "" +msgstr "information_if_good竊늌竊� = number_of_ancestors竊늌竊� 竊늇RUE竊�\n" #. type: Plain text #: en/git-bisect-lk2009.txt:597 #, priority:100 msgid "And this is true because at step 1) b) we remove the ancestors of the \"good\" commits." -msgstr "" +msgstr "瓦숁삸�잏쉪竊뚦썱訝뷴쑉閭ιい 1竊� b竊� �묇뺄�좈솮雅녳�쒎��앮룓雅ㅷ쉪曄뽩뀍��" #. type: Plain text #: en/git-bisect-lk2009.txt:600 #, priority:100 msgid "If X is found to be \"bad\", then we know that its descendants are all \"bad\", so we want to say that:" -msgstr "" +msgstr "倻귝옖�묊렟 X ���쒎쓯�앯쉪竊뚪궍阿덃닊餓х윥�볟츆�꾢릮餓i꺗���쒎쓯�꾟�앾펽��餓ζ닊餓ф꺍瑥댐폏" #. type: delimited block - #: en/git-bisect-lk2009.txt:603 #, no-wrap, priority:100 msgid "information_if_bad(X) = number_of_descendants(X) (WRONG)\n" -msgstr "" +msgstr "information_if_bad竊늌竊� = number_of_descendants竊늌竊� 竊늋RONG竊�\n" #. type: Plain text #: en/git-bisect-lk2009.txt:612 #, priority:100 msgid "But this is wrong because at step 1) a) we keep only the ancestors of the bad commit. So we get more information when a commit is marked as \"bad\", because we also know that the ancestors of the previous \"bad\" commit that are not ancestors of the new \"bad\" commit are not the first bad commit. We don't know if they are good or bad, but we know that they are not the first bad commit because they are not ancestor of the new \"bad\" commit." -msgstr "" +msgstr "鵝녻퓳��뵗瑥�쉪竊뚦썱訝뷴쑉閭ιい1竊뎎竊됪닊餓у룵岳앯븰�숃��욤��꾤쪝�덀�귛썱閭ㅿ펽壤볠룓雅ㅸ˙�뉓�訝뷜�쒎쓯�앮뿶竊뚧닊餓т폏孃쀥댆�닷쩀岳→겘竊뚦썱訝뷸닊餓т튋�ι걪竊뚥툖��뼭�쒎쓯�앮룓雅ㅷ쉪曄뽩뀍�꾡툓訝�訝も�쒎쓯�앮룓雅ㅷ쉪曄뽩뀍訝띷삸寧т�訝ら뵗瑥�룓雅ㅳ�귝닊餓т툖�ι걪若껂뺄�����쓯竊뚥퐜�묇뺄�ι걪若껂뺄訝띷삸寧т�訝ら뵗瑥�룓雅ㅿ펽�졽맏若껂뺄訝띷삸�겸�쒎쓯�앮룓雅ㅷ쉪曄뽩뀍��" #. type: Plain text #: en/git-bisect-lk2009.txt:616 #, priority:100 msgid "So when a commit is marked as \"bad\" we know we can remove all the commits in the graph except those that are ancestors of the new \"bad\" commit. This means that:" -msgstr "" +msgstr "�졿�竊뚦퐪訝�訝ゆ룓雅ㅸ˙�뉓�訝뷜�쒎쓯�앮뿶竊뚧닊餓х윥�볠닊餓у룾餓ε닠�ㅵ쎗壤㏘릎�꾣��됪룓雅ㅿ펽�ㅴ틙�d틳��뼭�쒎쓯�앮룓雅ㅷ쉪曄뽩뀍�귟퓳�뤷뫑��竊�" #. type: delimited block - #: en/git-bisect-lk2009.txt:619 #, no-wrap, priority:100 msgid "information_if_bad(X) = N - number_of_ancestors(X) (TRUE)\n" -msgstr "" +msgstr "information_if_bad竊늌竊� = N - number_of_ancestors竊늌竊� 竊늇RUE竊�\n" #. type: Plain text #: en/git-bisect-lk2009.txt:622 #, priority:100 msgid "where N is the number of commits in the (cleaned up) graph." -msgstr "" +msgstr "�뜸릎 N ��펷歷끿릤�꾬펹�얌릎�꾣룓雅ㅶ빊��" #. type: Plain text #: en/git-bisect-lk2009.txt:625 #, priority:100 msgid "So in the end this means that to find the best bisection commits we should maximize the function:" -msgstr "" +msgstr "��餓ζ��롨퓳�뤷뫑��誤곫돻�경�也썹쉪雅뚦늽�먧벡竊뚧닊餓у틪瑥ζ�鸚㎩뙑�썸빊竊�" #. type: delimited block - #: en/git-bisect-lk2009.txt:628 #, no-wrap, priority:100 msgid "f(X) = min(number_of_ancestors(X), N - number_of_ancestors(X))\n" -msgstr "" +msgstr "f(X) = min(number_of_ancestors(X), N - number_of_ancestors(X))\n" #. type: Plain text #: en/git-bisect-lk2009.txt:632 #, priority:100 msgid "And this is nice because at step 2) we compute number_of_ancestors(X) and so at step 3) we compute f(X)." -msgstr "" +msgstr "瓦쇿푽也쏙펽�졽맏�ⓩ�謠�2竊됪닊餓ц�嶸뾫umber_of_ancestors(X)竊뚧�餓ε쑉閭ιい3竊됪닊餓ц�嶸뾣(X)��" #. type: Plain text #: en/git-bisect-lk2009.txt:634 #, priority:100 msgid "Let's take the following graph as an example:" -msgstr "" +msgstr "溫⒵닊餓т빳訝뗥쎗訝뷰풃竊�" #. type: delimited block - #: en/git-bisect-lk2009.txt:641 @@ -69261,25 +69259,25 @@ msgid "" "A-B-C-D-E-F O\n" " \\ /\n" " K-L-M-N\n" -msgstr "" +msgstr " G-H-I-J\n / \\\nA-B-C-D-E-F O\n \\ /\n K-L-M-N\n" #. type: Plain text #: en/git-bisect-lk2009.txt:644 #, priority:100 msgid "If we compute the following non optimal function on it:" -msgstr "" +msgstr "倻귝옖�묇뺄�ⓨ끀訝딂�嶸쀤빳訝뗩씆��鴉섇눦�곤폏" #. type: delimited block - #: en/git-bisect-lk2009.txt:647 #, no-wrap, priority:100 msgid "g(X) = min(number_of_ancestors(X), number_of_descendants(X))\n" -msgstr "" +msgstr "g(X) = min(number_of_ancestors(X), number_of_descendants(X))\n" #. type: Plain text #: en/git-bisect-lk2009.txt:650 #, priority:100 msgid "we get:" -msgstr "" +msgstr "�묇뺄孃쀥댆竊�" #. type: delimited block - #: en/git-bisect-lk2009.txt:659 @@ -69292,13 +69290,13 @@ msgid "" " \\ /\n" " K-L-M-N\n" " 4 3 2 1\n" -msgstr "" +msgstr " 4 3 2 1\n G-H-I-J\n1 2 3 4 5 6/ \\0\nA-B-C-D-E-F O\n \\ /\n K-L-M-N\n 4 3 2 1\n" #. type: Plain text #: en/git-bisect-lk2009.txt:662 #, priority:100 msgid "but with the algorithm used by git bisect we get:" -msgstr "" +msgstr "鵝녷삸鵝욜뵪Git雅뚦늽�ζ돻嶸쀦퀡竊뚧닊餓у풓�곤폏" #. type: delimited block - #: en/git-bisect-lk2009.txt:671 @@ -69311,145 +69309,145 @@ msgid "" " \\ /\n" " K-L-M-N\n" " 7 7 6 5\n" -msgstr "" +msgstr " 7 7 6 5\n G-H-I-J\n1 2 3 4 5 6/ \\0\nA-B-C-D-E-F O\n \\ /\n K-L-M-N\n 7 7 6 5\n" #. type: Plain text #: en/git-bisect-lk2009.txt:678 #, priority:100 msgid "So we chose G, H, K or L as the best bisection point, which is better than F. Because if for example L is bad, then we will know not only that L, M and N are bad but also that G, H, I and J are not the first bad commit (since we suppose that there is only one first bad commit and it must be an ancestor of L)." -msgstr "" +msgstr "�졿�竊뚧닊餓ч�됪떓G�갎�갞�뻃鵝쒍맏��鵝녑뭄�녺궧竊뚩퓳驪봃�닷��귛썱訝븝펽倻귝옖L��쓯�꾬펽�d퉰�묇뺄訝띴퍎�ι걪L�갡�똍��쓯�꾬펽�뚥툝瓦섊윥�밎�갎�갏�똉訝띷삸寧т�訝ゅ쓯�먧벡(�졽맏�묇뺄�뉓��ゆ쐣訝�訝ょК訝�訝ゅ쓯�먧벡竊뚩�뚥툝若껃퓚窈삥삸L�꾤쪝��)��" #. type: Plain text #: en/git-bisect-lk2009.txt:681 #, priority:100 msgid "So the current algorithm seems to be the best possible given what we initially supposed." -msgstr "" +msgstr "�졿�竊뚪돱雅롦닊餓ф��앭걞溫양쉪嶸쀦퀡竊뚦퐪�띸쉪嶸쀦퀡鴉쇌퉶���也썹쉪��" #. type: Title ~ #: en/git-bisect-lk2009.txt:683 #, no-wrap, priority:100 msgid "Skip algorithm" -msgstr "" +msgstr "瓮녘퓝嶸쀦퀡" #. type: Plain text #: en/git-bisect-lk2009.txt:688 #, priority:100 msgid "When some commits have been skipped (using \"git bisect skip\"), then the bisection algorithm is the same for step 1) to 3). But then we use roughly the following steps:" -msgstr "" +msgstr "壤볢럼瓦뉏�雅쎿룓雅ㅿ펷鵝욜뵪�쐅it bisect skip�앾펹�띰펽閭ιい 1 �� 3 �꾡틠�녺츞力뺞삸�멨릪�꾬펹�귚퐜��펽溫⒵닊餓ф씎鵝욜뵪餓δ툔閭ιい竊�" #. type: Plain text #: en/git-bisect-lk2009.txt:690 #, priority:100 msgid "sort the commit by decreasing associated value" -msgstr "" +msgstr "�싪퓝�뤷컩�녘걫�쇔��먧벡瓦쏂죱�믣틣" #. type: Plain text #: en/git-bisect-lk2009.txt:693 #, priority:100 msgid "if the first commit has not been skipped, we can return it and stop here" -msgstr "" +msgstr "倻귝옖亦→쐣瓮녘퓝寧т�轝→룓雅ㅿ펽�묇뺄��빳瓦붷썮若껃뭉�ⓩ�鸚꾢걶閭�" #. type: Plain text #: en/git-bisect-lk2009.txt:695 #, priority:100 msgid "otherwise filter out all the skipped commits in the sorted list" -msgstr "" +msgstr "��닕瓦뉑빱�됪럲佯뤷닓烏ⓧ릎���됭럼瓦뉒쉪�먧벡" #. type: Plain text #: en/git-bisect-lk2009.txt:698 #, priority:100 msgid "use a pseudo random number generator (PRNG) to generate a random number between 0 and 1" -msgstr "" +msgstr "鵝욜뵪鴉ら쉹�뷸빊�잍닇�� 竊늁RNG竊� �잍닇餓뗤틢 0 �� 1 阿뗩뿴�꾦쉹�뷸빊" #. type: Plain text #: en/git-bisect-lk2009.txt:701 #, priority:100 msgid "multiply this random number with its square root to bias it toward 0" -msgstr "" +msgstr "弱녷��뤸쑛�겻툗�뜹뭄�방졊�멧튂竊뚥슴�뜹걦�� 0" #. type: Plain text #: en/git-bisect-lk2009.txt:704 #, priority:100 msgid "multiply the result by the number of commits in the filtered list to get an index into this list" -msgstr "" +msgstr "弱녺퍜�쒍튂餓θ퓝譯ㅵ릮�꾢닓烏ⓧ릎�꾣룓雅ㅶ빊�륅펽孃쀥댆瑥ε닓烏①쉪榮℡폊" #. type: Plain text #: en/git-bisect-lk2009.txt:706 #, priority:100 msgid "return the commit at the computed index" -msgstr "" +msgstr "瓦붷썮溫←츞�븀쉪榮℡폊鸚꾤쉪�먧벡" #. type: Title ~ #: en/git-bisect-lk2009.txt:708 #, no-wrap, priority:100 msgid "Skip algorithm discussed" -msgstr "" +msgstr "瓮녘퓝嶸쀦퀡溫②�" #. type: Plain text #: en/git-bisect-lk2009.txt:715 #, priority:100 msgid "After step 7) (in the skip algorithm), we could check if the second commit has been skipped and return it if it is not the case. And in fact that was the algorithm we used from when \"git bisect skip\" was developed in Git version 1.5.4 (released on February 1st 2008) until Git version 1.6.4 (released July 29th 2009)." -msgstr "" +msgstr "�ⓩ�謠�7竊됵펷瓮녘퓝嶸쀦퀡訝�펹阿뗥릮竊뚧닊餓у룾餓ζ��ηК雅뚧А�먧벡��맔藥꿰퍘熬ヨ럼瓦뉛펽倻귝옖訝띷삸瓦숁졆竊뚦닕瓦붷썮若껁�귚틟若욂툓竊뚩퓳弱길삸�묇뺄餓랦it 1.5.4�덃쑍竊�2008亮�2��1�ε룕躍껓펹凉��� \"git bisect skip \"�뜹�冶뗤슴�①쉪嶸쀦퀡竊뚨쎍�캢it 1.6.4�덃쑍竊�2009亮�7��29�ε룕躍껓펹��" #. type: Plain text #: en/git-bisect-lk2009.txt:721 #, priority:100 msgid "But Ingo Molnar and H. Peter Anvin (another well known linux kernel developer) both complained that sometimes the best bisection points all happened to be in an area where all the commits are untestable. And in this case the user was asked to test many untestable commits, which could be very inefficient." -msgstr "" +msgstr "鵝녷삸Ingo Molnar�똇. Peter Anvin竊덂룱訝�訝よ몭�띸쉪Linux�끾졇凉��묋�낉펹�썸뒻�②�竊뚧쐣�뜻�也썹쉪�녺븣�백꺗閻겼랫�ⓧ�訝ゆ��됪룓雅ㅹ꺗�졿퀡役뗨캊�꾢뙷�잆�귟�뚦쑉瓦숂쭕�끻넻訝뗰펽�ⓩ댎熬ヨ쫨黎귝탩瑥뺠�鸚싦툖��탩瑥뺟쉪�먧벡竊뚩퓳��꺗��씆躍멧퐥�덄쉪��" #. type: Plain text #: en/git-bisect-lk2009.txt:725 #, priority:100 msgid "Indeed untestable commits are often untestable because a breakage was introduced at one time, and that breakage was fixed only after many other commits were introduced." -msgstr "" +msgstr "雅뗥츩訝딉펽訝띶룾役뗨캊�꾣룓雅ㅵ�孃���썱訝뷸윇轝▼폊�δ틙訝�訝ょ졃瀯쏙펽�뚩퓳訝ょ졃瀯썸삸�ⓨ폊�δ틙溫멨쩀�뜸퍟�꾣룓雅ㅴ퉳�롦뎺熬ヤ엶鸚띸쉪��" #. type: Plain text #: en/git-bisect-lk2009.txt:729 #, priority:100 msgid "This breakage is of course most of the time unrelated to the breakage we are trying to locate in the commit graph. But it prevents us to know if the interesting \"bad behavior\" is present or not." -msgstr "" +msgstr "壤볡꽫竊뚩퓳燁띸졃�뤷쑉鸚㎩쩀�경뿶�쇾툗�묇뺄瑥뺝쎗�ⓩ룓雅ㅵ쎗訝�츣鵝띸쉪�닷쓯�졾뀽�귚퐜若껃뜶溫⒵닊餓ф뿞力뺟윥�볠쐣擁g쉪 \"�뤺죱訝� \"��맔耶섇쑉��" #. type: Plain text #: en/git-bisect-lk2009.txt:733 #, priority:100 msgid "So it is a fact that commits near an untestable commit have a high probability of being untestable themselves. And the best bisection commits are often found together too (due to the bisection algorithm)." -msgstr "" +msgstr "�졿�竊뚦쑉訝띶룾役뗨캊�꾣룓雅ㅹ셿瓦묊쉪�먧벡竊뚦끀�ц벴阿잍쐣孃덂ㄷ��꺗��툖��탩瑥뺟쉪�귟�뚥툝竊뚧�也썹쉪�녺븣瀛욘룓雅ㅴ튋瀯뤷만熬ュ룕�겼쑉訝�壅뤄펷�긴틢雅뚦늽嶸쀦퀡�꾢렅�좑펹��" #. type: Plain text #: en/git-bisect-lk2009.txt:736 #, priority:100 msgid "This is why it is a bad idea to just chose the next best unskipped bisection commit when the first one has been skipped." -msgstr "" +msgstr "瓦쇿갚��맏餓�阿덂퐪寧т�訝ゅ늽�뚨봇熬ヨ럼瓦뉑뿶竊뚨쎍�ι�됪떓訝뗤�訝ゆ�也썹쉪�よ럼瓦뉒쉪�녺븣瀛욘룓雅ㅶ삸訝ゅ쓯訝삥꼷��" #. type: Plain text #: en/git-bisect-lk2009.txt:741 #, priority:100 msgid "We found that most commits on the graph may give quite a lot of information when they are tested. And the commits that will not on average give a lot of information are the one near the good and bad commits." -msgstr "" +msgstr "�묇뺄�묊렟竊뚦쎗訝�쉪鸚㎩쩀�경룓雅ㅵ쑉熬ユ탩瑥뺞뿶��꺗鴉싨룓堊쏁쎑壤볟쩀�꾡에���귟�뚪궍雅쎾뭄�뉑씎瑥답툖鴉싨룓堊쎾ㄷ�뤶에��쉪�먧벡��씈瓦묈��꾢뭽�뤹쉪�먧벡��" #. type: Plain text #: en/git-bisect-lk2009.txt:744 #, priority:100 msgid "So using a PRNG with a bias to favor commits away from the good and bad commits looked like a good choice." -msgstr "" +msgstr "�졿�竊뚥슴�ⓧ�訝ゆ쐣�뤷릲�㎫쉪PRNG�ε걦�묇틢瓦쒐┿也썹쉪�뚦쓯�꾣룓雅ㅿ펽�뗨돈�ζ삸訝�訝や툖�숂쉪�됪떓��" #. type: Plain text #: en/git-bisect-lk2009.txt:751 #, priority:100 msgid "One obvious improvement to this algorithm would be to look for a commit that has an associated value near the one of the best bisection commit, and that is on another branch, before using the PRNG. Because if such a commit exists, then it is not very likely to be untestable too, so it will probably give more information than a nearly randomly chosen one." -msgstr "" +msgstr "瓦쇾릉嶸쀦퀡�꾡�訝ゆ삇�양쉪�배퓵��펽�ⓧ슴�쭾RNG阿뗥뎺竊뚦��얌�訝や툗��鵝녑늽�됪룓雅ㅷ쉪�쇗렏瓦묊쉪�먧벡竊뚩�뚥툝��쑉�╊�訝ゅ늽��툓�귛썱訝뷴쫩�쒑퓳�루쉪�먧벡耶섇쑉竊뚪궍阿덂츆阿잋툖鸚ゅ룾�썸삸訝띶룾役뗨캊�꾬펽��餓ε츆��꺗鴉싨캈�졽퉶�뤸쑛�됪떓�꾣룓雅ㅶ룓堊쎿쎍鸚싦에����" #. type: Title ~ #: en/git-bisect-lk2009.txt:753 #, no-wrap, priority:100 msgid "Checking merge bases" -msgstr "" +msgstr "汝��ε릦亮뜹읃��" #. type: Plain text #: en/git-bisect-lk2009.txt:757 #, priority:100 msgid "There is another tweak in the bisection algorithm that has not been described in the \"bisection algorithm\" above." -msgstr "" +msgstr "�녶돯嶸쀦퀡訝�퓲�됦�訝よ컘�댐펽�ⓧ툓�®쉪 \"雅뚦늽嶸쀦퀡 \"訝�깹�됪룒瓦겹��" #. type: Plain text #: en/git-bisect-lk2009.txt:761