4

するとgit worktree list以下のように表示されます。

/path/to/workspace  c943d35 [master]
/path/to/workspace  ef4df56 (detached HEAD)

これは私の作業ディレクトリです (worktree ディレクトリではありません)。どうしてこうなったのか、掃除の仕方がわかりません。試してみましgit worktree pruneたが、何も変わりません。どんな助けでも大歓迎です。どうもありがとう。

4

1 に答える 1

7

git worktree-- 詳細は次のとおりです。

リンクされた各作業ツリーには、リポジトリのディレクトリにプライベート サブディレクトリがあります$GIT_DIR/worktrees。

の内容を確認し、main repo/.git/worktrees手動で削除できるサブフォルダーがあるかどうかを確認してください。

Git 2.20 (2018 年第 4 四半期) では、パスが欠落している場合 (たとえば、手動で削除された場合)、同じパスが複数のワークツリー エントリの下に登録される可能性があるというバグが修正されています。
また、便宜上、--force適用可能なケースの数を増やします。

Jeff King ( )によるcommit 684e742 (2018 年 8 月 30 日)を参照してください。commit 3a54043 、commit f414310、commit 68a6b3a、commit e19831c、commit cb56f55、commit 45059e6、commit 602aaed、commit e5353be、commit 4c5fa9e (2018 年 8 月 28 日) by Eric Sunshine ( )を参照してください。( 2018 年 9 月 17 日にコミット 1c515bfでJunio C Hamanoによってマージされました)peff
sunshineco
gitster

worktree: ' ' の.git/worktrees後に空の場合は削除しますremove

整理のため、" "は、プルーニングの完了後にディレクトリが空の場合はgit worktree prune削除します。.git/worktrees

一貫性を保つために、削除後に空の場合は" git worktree remove <path>" も同様に削除します。.git/worktrees

同じ Git 2.20 では、到達可能性のためにオブジェクトをトラバースし、どのオブジェクトが参照されておらず消耗可能であるかを判断するときに、データの損失を防ぐための開始点として、他のワークツリーのワークツリーごとの参照も考慮するように教えられています。

commit 14f74d5 ( 2018 年 11 月 3 日)、commit c9ef0d9、commit b29759d、commit ab3e1f7、commit 061e420、commit 3a3b9d8 (2018 年 10 月 21 日)、およびcommit 8aff1a9、commit 5c79f74 (29 Sep 2018) by Nguyễn Tháipclouds Ngọ を参照してください。Elijah Newren ( )によるcommit a8c754d (2018 年 10 月 21 日)
を参照してください。( 2018 年 11 月 13 日にコミット e146cc9でJunio C Hamanoによってマージされました)newren
gitster

特に ( commit 3a3b9d8 ):

refs: ワークツリーごとの参照をすべてのワークツリーから見えるようにするための新しい参照型

複数のワークツリーの問題の 1 つは、あるワークツリーのワークツリーごとの参照に別のワークツリーからアクセスすることです。
これは、コードが別のワークツリーの ref ストアを開くことができ、そのワークツリーの ref 空間にアクセスできる、複数の ref ストアによって一種の解決されました。

これに関する問題は、レポートです。
別の ref 空間の" HEAD" も、現在の ref 空間と同様に "HEAD" と呼ばれます。
それらを区別するために、すべてのコードは何らかの方法で ref ストアを持ち歩き、" " のように出力する必要がありますHEAD from this ref store。

別の ref スペースを入力する代わりに、他のワークツリーからの ref を現在の ref スペースで使用できるようにします。
したがって、" HEAD" は常に現在のワークツリーの HEAD ですが、" worktrees/blah/HEAD" という名前のワークツリーの HEAD を " " で表すことができますblah。
この構文は偶然にも基礎となるディレクトリ構造と一致するため、実装が少し簡単になります。

メインのワークツリーは、最初から特別なので、特別に扱う必要があります。
そのため、メイン ワークツリーの HEAD は、" main-worktree/HEAD" の代わりに " worktrees/main/HEAD"という名前を介してアクセスmainできます。

このパッチにより、あるワークツリーからの参照を別のワークツリーで指定することも可能になります。

git log worktrees/foo/HEAD

これ (新しい参照 " worktrees/<name>/HEAD") は Git 2.23 (2019 年第 2 四半期) につながり、コードはワークツリーに指定された名前をサニタイズして、これらの参照が整形式であることを確認します。

Nguyễn Thái Ngọc Duy ( )によるコミット 1de16ae (2019 年 3 月 8 日)を参照してください。 支援者: Jeff King ( ) . ( 2019 年 6 月 13 日、コミット 0d107b1でJunio C Hamanoによってマージされました)pclouds
peff
gitster

worktree add: ワークツリー名をサニタイズします

ワークツリー名は に基づいてい$(basename $GIT_WORK_TREE)ます。
これらは3a3b9d8 ( refs: ワークツリーごとの参照をすべてのワークツリーから見えるようにするための新しい参照タイプ - 2018-10-21、Git v2.20.0-rc0) まで重要ではありません。ここで、ワークツリー名は参照名の一部である可能性があり、参照名の後に続く必要があります。ルール。

worktree addこれらの規則に従うために、' ' コードを更新して特殊文字を削除してください。将来的には、このばかげた文字の置換に満足できない場合、ユーザーはワークツリー名を自分で指定できるようになります。

また、同じ Git 2.22.1 (2019 年第 3 四半期)にはgit worktree add、同じリポジトリに接続された別のワークツリーが破損したときに失敗していた " " が記載されていましたが、これは修正されています。

Nguyễn Thái Ngọc Duy ( )によるcommit 105df73 (2019 年 5 月 13 日)を参照してください。( 2019 年 7 月 25 日、コミット 933f294でJunio C Hamanoによってマージされました)pclouds
gitster

worktree add: 破損したワークツリーに寛容であること

find_worktree()real_path() 穏やかなバージョンの代わりに使用するため、予期せず die() することができます。

「git worktree add」(cb56f55 で追加( :worktree同じパスを複数回追加することを禁止、2018-08-28、Git v2.20.0-rc0)、または v2.20.0 以降で使用されている場合。実際のバグfind_worktree()はもっと古いですが、 ) で、悪いワークツリーがあると、die()新しいワークツリーを追加できなくなる可能性があります。

これをトリガーする「悪い」条件は、ワークツリーの場所の親が削除されたときです。それからreal_path()文句を言うでしょう。

不良ワークツリーが ' worktree add' に影響しないように、他のバージョンを使用してください。
悪いものは最終的に剪定されますが、少しの間それらを許容する必要があります。

Git 2.26 (2020 年第 1 四半期) より前では、まれに " "が既に登録済みのワークツリーではないのに、それが既に登録されていると判断し、新しいワークツリーの追加を拒否することがありました。 これは修正されました。git worktree add <path><path>

commit bb69b3b、commit bb4995f、commit a80c4c2 (2020 年 2 月 24 日) by Eric Sunshine ( sunshineco)を参照してください。
( 2020 年 3 月 5 日、コミット 49e5043でJunio C Hamanoによってマージされました)gitster

worktreeadd:接尾辞の一致によって " " 検証がだまされることを許可しないでください

報告者: Cameron Gunnin
署名者: Eric Sunshine

" " は、新しいワークツリーの有効な場所として承認する前に、さまざまなチェックを実行します。git worktree add <path><path>

<path>が存在しないことを確認する以外に、質問の 1 つは、<path>がすでに登録されているワークツリーであるかどうかです。
このチェックを実行するために、クエリを実行し、 に一致するものが見つかった場合は " " 操作find_worktree()を許可しません。 ただし、便宜上、 は非常に広いネットワークをキャストして、ユーザーが入力を最小限に抑えるために省略形でワークツリーを識別できるようにします。 たとえば、サブツリー " " と " " が与えられた場合、" " のみを求められたときに後者を正しく選択できるサフィックス マッチングを実行します。addfind_worktree()<path>
find_worktree()
foo/barfoo/bazbaz

" add" 検証は問い合わせている正確なパスを認識しているため、この種のヒューリスティック ベースのマッチングは、せいぜいこのユース ケースでは疑わしく、最悪の場合、<path>誤って既存のワークツリーと一致すると解釈され、誤って既に存在すると報告される可能性があります。そうでない場合でも登録されます。
(実際、validate_worktree_add()この問題が原因で、誤ってメインのワークツリーと一致することを避けるための特別なケースが既に含まれています。)

find_worktree_by_path()によって実行される魔法の短縮形のマッチングを適用せずに、決定論的に一致するパスを代わりに利用することで、既存のワークツリーとの潜在的な偶発的なマッチングの問題を回避しfind_worktree()ます。

と：

worktreefind_worktree():ドキュメントを改善する

署名者: Eric Sunshine

find_worktree()の主な目的は、ユーザーからの入力に基づいてワークツリーを見つけることであると説明するより良い仕事をしてください。

たとえば、ユーザーがワークツリーを識別するために使用できる省略表現の 1 つは、一意のパス接尾辞によるものです (つまり、パス " foo/bar" および " foo/baz" にワークツリーがあり、後者は単純に " " と識別できますbaz)。
ワークツリーを選択するために実際に使用されるヒューリスティックfind_worktree()は、将来拡張される可能性があります (たとえば、ある日<id>、.git/worktrees/<id>/管理ディレクトリによるワークツリーの選択が可能になる可能性があります)。将来の拡張を可能にするためのオープンエンド。

その間、非 NULL 要件についての言及をやめてprefixから、NULL長い間許可されてきました。

たとえば、116fb64e43 ( : 長さパラメーターのドロップ、2017-03-20、Git v2.13.0-rc0) 以降、およびe4da43b1f0以降のそれ自体prefix_filename()が明示的に許可されています: 新しく割り当てられた文字列を返す、2017-03-20、Git v2.13.0-rc0 ）。NULLprefix_filenamefind_worktree() (prefix_filename

同じ作業ツリー ディレクトリは 1 回だけ登録する必要がありますが、" git worktree move" はこの不変条件に違反することを許可しており、Git 2.28 (2020 年第 3 四半期) で修正されています。

commit 810382e、commit d179af6、commit 916133e、commit 4a3ce47、commit dd9609a、commit 1b14d40 (2020 年 6 月 10 日)、commit c9b77f2 (sunshineco 2020 年 6 月 8 日) を参照してください。
( 2020 年 6 月 22 日、コミット 9740ef8でJunio C Hamanoによってマージされました)gitster

Git 2.28 (2020 年第 3 四半期) では、同じ作業ツリー ディレクトリを 1 回だけ登録する必要がありますが、「git worktree移動」によりこの不変条件が破られることがありましたが、修正されました。

commit 810382e、commit d179af6、commit 916133e、commit 4a3ce47、commit dd9609a、commit 1b14d40 (2020 年 6 月 10 日)、commit c9b77f2 (sunshineco 2020 年 6 月 8 日) を参照してください。
( 2020 年 6 月 22 日、コミット 9740ef8でJunio C Hamanoによってマージされました)gitster

worktree: 同じワークツリー パスを参照する重複エントリを削除します

署名者: Eric Sunshine

リンクされた作業ツリーの基本的な制限は、特定のパスに関連付けられた単一の作業ツリーのみが存在する必要があることです。したがって、" git worktree add" は、既存の登録済み作業ツリーと同じ場所に新しい作業ツリーを作成することを明示的に禁止します。

とはいえ、ユーザーは .xml の管理ファイルをいじることによって、「自分自身を撃つ」ことができます.git/worktree/<id>/。

さらに悪いことに、" git worktree move" は不注意で、ワークツリーが登録されているが欠落しているワークツリーの上に移動される可能性があります (たとえば、ワークツリーがリムーバブル メディア上にある場合に発生する可能性があります)。

例えば：

$ git clone foo.git
$ cd foo
$ git worktree add ../bar
$ git worktree add ../baz
$ rm -rf ../bar
$ git worktree move ../baz ../bar
$ git worktree list
.../foo beefd00f [master]
.../bar beefd00f [bar]
.../bar beefd00f [baz]

git worktree prune複数のワークツリーが同じパスに関連付けられている場合に検出するよう " " に教えることで、ユーザーがこの形式の破損から回復できるようにします。

と：

worktree: メインのワークツリー パスを参照するリンクされたワークツリーを削除します

報告者: Jonathan Müller
署名者: Eric Sunshine

" git worktree prune" は、複数のエントリが同じパスに関連付けられていることを検出し、重複を排除します。

ただし、リンクされたワークツリーがメイン ワークツリーのパスを指している場合は検出されません。
" " では、メインのワークツリーと同じパスを持つ新しいワークツリーを作成することはできませんが、このようなケースは、ユーザーが管理ファイルgit worktree addをいじらなくても、Git の制御外で発生する可能性があります。.git/worktree/<id>/

例えば：

$ git clone foo.git
$ git -C foo worktree add ../bar
$ rm -rf bar
$ mv foo bar
$ git -C bar worktree list
.../bar deadfeeb [master]
.../bar deadfeeb [bar]

git worktree prune" " を拡張して、リンクされたワークツリーがメイン ワークツリーのパスに関連付けられていることも検出できるようにすることで、ユーザーがこのような破損から回復できるようにします。

Git 2.30 では、ロックされたワークツリーが一覧表示されることに注意してください。

コミット c57b336を参照してください。

ワークツリー:listロックされたワークツリーに注釈を付けるように教える

" git worktree list" は、作業ツリーへの絶対パス、チェックアウトされたコミット、およびブランチの名前を示しています。どのワークツリーがロックされているかは、すぐにはわかりません。

「git worktree remove」は、ロックされたワークツリーの削除を拒否し、エラー メッセージが表示されます。git worktree listどのワークツリーがロックされているかを" " 出力で通知した場合、ユーザーはそのようなワークツリーを削除しようとさえしないか、または " git worktree remove -f -f <path>" が必要であることに気付くでしょう。

" " に " " をその出力git worktree listに追加するように教えます。 コマンドからの出力は次のようになります。locked

$ git worktree list
/path/to/main             abc123 [master]
/path/to/worktree         456def (detached HEAD)
/path/to/locked-worktree  123abc (detached HEAD) locked

Git 2.33 (2021 年第 3 四半期) で、" git worktree add --lock" (男性)はカスタム メッセージでワークツリーがロックされている理由を記録することを学びました。

commit 0db4961 (2021 年 7 月 15 日) およびcommit f7c35ea、commit f9365c0 (2021 年 7 月 11 日) by Stephen Manz ( SRManz)を参照してください。
( 2021 年 7 月 28 日、コミット 01369fdでJunio C Hamanoによってマージされました)gitster

worktreeadd:受け入れること--reason <string>を教える--lock

署名者: Stephen Manz
レビュー者: Eric Sunshine

ロックファイル " added with --lock" に保存されているデフォルトの理由は、ユーザーが別の( man )コマンドで指定したものである可能性は低いです。 作業ツリーを追加するときに指定できるようにすることで、ユーザーは 2 番目のコマンドを必要とせずにロックの理由を制御できます。git worktree lock
--reason--lock

git worktreemanページに含まれるようになりました：

git worktree add [-f] [--detach] [--checkout] [--lock [--reason <string>]] [-b <new-branch>] <path> [<commit-ish>]

git worktreemanページに含まれるようになりました：

withlockまたは with 、作業ツリーがロックされている理由add --lockの説明。

于 2016-02-24T10:19:50.887 に答える