kuma35
diff --git a/‎Documentation-ja/technical/rerere.html‎
Lines changed: 5 additions & 5 deletions b/‎Documentation-ja/technical/rerere.html‎
Lines changed: 5 additions & 5 deletions
diff --git a/‎Documentation-ja/technical/rerere.txt‎
Lines changed: 3 additions & 3 deletions b/‎Documentation-ja/technical/rerere.txt‎
Lines changed: 3 additions & 3 deletions
diff --git a/‎Documentation-ja/technical/sparse-checkout.html‎
Lines changed: 2 additions & 2 deletions b/‎Documentation-ja/technical/sparse-checkout.html‎
Lines changed: 2 additions & 2 deletions
diff --git a/‎Documentation-ja/technical/sparse-checkout.txt‎
Lines changed: 1 addition & 1 deletion b/‎Documentation-ja/technical/sparse-checkout.txt‎
Lines changed: 1 addition & 1 deletion
@@ -735,7 +735,7 @@
 <body class="article">
 <div id="header">
 <h1>Rerere</h1>
-<span id="revdate">2024-12-15</span>
+<span id="revdate">2025-10-19</span>
 </div>
 <div id="content">
 <div id="preamble">
@@ -779,7 +779,7 @@ <h3 id="_removing_the_common_ancestor_version">Removing the common ancestor vers
 行Aを行Dにすることが、
 ABとACがやりたかったことと互換性のある最善の方法であると私は信じています。</code></pre>
 </div></div>
-<div class="paragraph"><p>As branch AC2 refers to the same commit as AC, the above implies that this is also compatible with what AB and AC2 wanted to do.</p></div>
+<div class="paragraph"><p>ブランチ AC2 が AC と同じコミットを参照しているため、 上記は AB と AC2 が意図したこととも互換性があることを示しています。</p></div>
 <div class="paragraph"><p>ひいては、これは、rerereが上記の競合が同一であることを認識する必要があることを意味します。 これを行うには、競合マーカーのラベルを削除し、共通の祖先バージョンを削除します。 上記の例は両方とも、以下の正規化された競合を引き起こします:</p></div>
 <div class="literalblock">
 <div class="content">
@@ -792,7 +792,7 @@ <h3 id="_removing_the_common_ancestor_version">Removing the common ancestor vers
 </div>
 <div class="sect2">
 <h3 id="_sorting_hunks">Sorting hunks</h3>
-<div class="paragraph"><p>As before, let&#8217;s imagine that a common ancestor had a file with line A its early part, and line X in its late part. And then four branches are forked that do these things:</p></div>
+<div class="paragraph"><p>上記同様に、 共通の祖先がファイルを持ち、 そのファイルの前半にA行、 後半にX行があると想像してください。 そして、 以下のことを行う 4 つのブランチが分岐します:</p></div>
 <div class="ulist"><ul>
 <li>
 <p>
@@ -837,7 +837,7 @@ <h3 id="_conflict_id_calculation">Conflict ID calculation</h3>
 </div>
 <div class="sect2">
 <h3 id="_nested_conflicts">Nested conflicts</h3>
-<div class="paragraph"><p>Nested conflicts are handled very similarly to "simple" conflicts. Similar to simple conflicts, the conflict is first normalized by stripping the labels from conflict markers, stripping the common ancestor version, and sorting the conflict hunks, both for the outer and the inner conflict. This is done recursively, so any number of nested conflicts can be handled.</p></div>
+<div class="paragraph"><p>入れ子になった競合は、「単純な」競合と非常によく似た処理が行われます。 単純な競合と同様に、競合は最初に、競合マーカーからラベルを削除し、共通の祖先バージョンを削除し、外部と内部の両方の競合について競合ハンクを並べ替えることによって正規化されます。 これは再帰的に実行されるため、入れ子になった競合をいくつでも処理できます。</p></div>
 <div class="paragraph"><p>注意：これは、「きれいに入れ子になった」競合マーカーに対してのみ機能することに注意してください。 一致しない競合マーカーがある場合、rerereは競合の処理と競合解決の記録に失敗します。</p></div>
 <div class="paragraph"><p>唯一の違いは、競合IDの計算方法にあります。 内部競合の場合、sha1を計算する前に競合マーカー自体が削除されません。</p></div>
 <div class="paragraph"><p>たとえば、以下の競合があるとします:</p></div>
@@ -875,7 +875,7 @@ <h3 id="_nested_conflicts">Nested conflicts</h3>
 <div id="footer">
 <div id="footer-text">
 Last updated
- 2024-12-15 12:50:13 JST
+ 2025-10-22 08:21:12 JST
 </div>
 </div>
 </body>
 
@@ -41,7 +41,7 @@ AC2と同様のことを行うと(ブランチABからブランチABAC2をフォ
     行Aを行Dにすることが、
     ABとACがやりたかったことと互換性のある最善の方法であると私は信じています。
 
-As branch AC2 refers to the same commit as AC, the above implies that this is also compatible with what AB and AC2 wanted to do.
+ブランチ AC2 が AC と同じコミットを参照しているため、 上記は AB と AC2 が意図したこととも互換性があることを示しています。
 
 ひいては、これは、rerereが上記の競合が同一であることを認識する必要があることを意味します。 これを行うには、競合マーカーのラベルを削除し、共通の祖先バージョンを削除します。 上記の例は両方とも、以下の正規化された競合を引き起こします:
 
@@ -54,7 +54,7 @@ As branch AC2 refers to the same commit as AC, the above implies that this is al
 Sorting hunks
 ~~~~~~~~~~~~~
 
-As before, let's imagine that a common ancestor had a file with line A its early part, and line X in its late part. And then four branches are forked that do these things:
+上記同様に、 共通の祖先がファイルを持ち、 そのファイルの前半にA行、 後半にX行があると想像してください。 そして、 以下のことを行う 4 つのブランチが分岐します:
 
     - AB: changes A to B
     - AC: changes A to C
@@ -91,7 +91,7 @@ Conflict ID calculation
 Nested conflicts
 ~~~~~~~~~~~~~~~~
 
-Nested conflicts are handled very similarly to "simple" conflicts. Similar to simple conflicts, the conflict is first normalized by stripping the labels from conflict markers, stripping the common ancestor version, and sorting the conflict hunks, both for the outer and the inner conflict. This is done recursively, so any number of nested conflicts can be handled.
+入れ子になった競合は、「単純な」競合と非常によく似た処理が行われます。 単純な競合と同様に、競合は最初に、競合マーカーからラベルを削除し、共通の祖先バージョンを削除し、外部と内部の両方の競合について競合ハンクを並べ替えることによって正規化されます。 これは再帰的に実行されるため、入れ子になった競合をいくつでも処理できます。
 
 注意：これは、「きれいに入れ子になった」競合マーカーに対してのみ機能することに注意してください。 一致しない競合マーカーがある場合、rerereは競合の処理と競合解決の記録に失敗します。
 
 
@@ -1007,7 +1007,7 @@ <h3 id="_主たる関心事に関するユースケース">主たる関心事に
 <pre><code>(振る舞いC)</code></pre>
 </div></div>
 <div class="paragraph"><p>この使用例は、 初期のスパース・チェックアウトに関する文書化された前提条件の一部に違反しています(SKIP_WORKTREE としてマークされたファイルは、 作業ツリーに存在するものとしてユーザーに表示されるため)。 この違反は、 スパース・チェックアウトに関連するさまざまな動作がこのユースケースにあまり適していないことを意味する可能性があり、 これを処理するにはドキュメントとコードの両方に調整が必要になる可能性があります。 ただし、 このユースケースは、 いくつかの例外を除いてすべてが高密度(まばらでない)チェックアウトのように動作するという点で、 おそらくサポートする最も単純なモデルでもあります(たとえば、VFS が必要に応じて残りを遅延的に書き込むことがわかっているため、 ブランチ・チェックアウトと switch は書き込む内容が少なくなります)。</p></div>
-<div class="paragraph"><p>Since there is no publicly available VFS-related code for folks to try, the number of folks who can test such a usecase is limited.</p></div>
+<div class="paragraph"><p>公開されているVFS関連のコードがないため、 このようなユースケースをテストできる人の数は限られています。</p></div>
 <div class="paragraph"><p>振る舞いC のユースケースに注目する主な理由は、 振る舞いA と 振る舞いB をより適切にサポートするために修正を行う際に、 このユースケースの人々が元の非スパース処理を受けられるように調整する必要がある追加の場所が存在する可能性があるためです。 例については、 ecc7c8841d ("repo_read_index: add config to expect files outside sparse patterns", 2022-02-25)を参照してください。 振る舞いC に注目する 2 番目の理由は、 振る舞いC を利用する人々が自分が 振る舞いB 陣営の一員であると思い込み、 実際の 振る舞いB の人々のために問題を解決するパッチを提案しないようにするためです。</p></div>
 </div>
 <div class="sect2">
@@ -2619,7 +2619,7 @@ <h3 id="_reference_emails">Reference Emails</h3>
 <div id="footer">
 <div id="footer-text">
 Last updated
- 2024-12-15 12:50:14 JST
+ 2025-10-22 08:27:56 JST
 </div>
 </div>
 </body>
 
@@ -110,7 +110,7 @@ Stolee はこのユースケースを以下のように説明しています[11]
 
 この使用例は、 初期のスパース・チェックアウトに関する文書化された前提条件の一部に違反しています(SKIP_WORKTREE としてマークされたファイルは、 作業ツリーに存在するものとしてユーザーに表示されるため)。 この違反は、 スパース・チェックアウトに関連するさまざまな動作がこのユースケースにあまり適していないことを意味する可能性があり、 これを処理するにはドキュメントとコードの両方に調整が必要になる可能性があります。 ただし、 このユースケースは、 いくつかの例外を除いてすべてが高密度(まばらでない)チェックアウトのように動作するという点で、 おそらくサポートする最も単純なモデルでもあります(たとえば、VFS が必要に応じて残りを遅延的に書き込むことがわかっているため、 ブランチ・チェックアウトと switch は書き込む内容が少なくなります)。 
 
-Since there is no publicly available VFS-related code for folks to try, the number of folks who can test such a usecase is limited.
+公開されているVFS関連のコードがないため、 このようなユースケースをテストできる人の数は限られています。
 
 振る舞いC のユースケースに注目する主な理由は、 振る舞いA と 振る舞いB をより適切にサポートするために修正を行う際に、 このユースケースの人々が元の非スパース処理を受けられるように調整する必要がある追加の場所が存在する可能性があるためです。 例については、 ecc7c8841d ("repo_read_index: add config to expect files outside sparse patterns", 2022-02-25)を参照してください。 振る舞いC に注目する 2 番目の理由は、 振る舞いC を利用する人々が自分が 振る舞いB 陣営の一員であると思い込み、 実際の 振る舞いB の人々のために問題を解決するパッチを提案しないようにするためです。