問題タブ [refspec]

私はGerrit Code Reviewで Git をセットアップしており、Git を初めて使用するユーザーにとって必要な Git コマンドを比較的簡単にする方法を探しています。

新しい機能ブランチを開始するために現在持っているコマンドは基本的に次のとおりです (Gerrit が であると仮定origin):

work1234これにより、いくつかの から分岐した新しい作業パッケージが開始されbaseline、最後のプッシュで Gerrit に分岐が作成され、上流が設定されます。したがって、.git/config次のようになります。

現在、Gerrit は、たとえば、レビュー用の新しいコミットを特別な refspec にプッシュすることを望んでrefs/for/work1234います。私はこれを手動で行うことができます：

私がやりたいことは、プレーンが現在のブランチを Gerrit が必要とするリモートの refspec にプッシュするように設定する方法を見つけること.git/configですgit push。私は次のgit config分野を見てきました：

• branch.<name>.*-プッシュ参照仕様を設定するための特定のオプションがないようです
• push.default- 私はupstreamここが欲しい
• remote.<name>.pushrefs/heads/*:refs/for/*-私はここで試しましたが、この場合は常にすべてのローカルブランチgit pushをプッシュしたいのですが、現在のブランチだけが必要です

Git だけでこれを行うことができない場合は、refspec を完全に指定する小さなラッパー スクリプトを作成します。ただし、Git がネイティブに適切な場所にプッシュできるとよいでしょう。

git cloneいくつかのリポジトリを作成すると、そこからすべてのブランチが取得されます。

次に、build1ミラーとして使用してクローンを作成すると、すべてのリモートブランチが表示されません（build1のローカルマスターブランチのみが表示されます）

リモートブランチのリモートをチェックアウトするにはどうすればよいですか？

コマンドを使用してbuild1ミラーのすべてのリモートブランチをチェックアウトできることを知っています

すべてのリモートgitブランチをローカルブランチとして追跡し ますが、build1ディレクトリにアクセスできない場合はどうなりますか？

また、git ls-remote originすべてのリモート参照を表示するコマンドがありますが、リモートブランチのそれらのリモートをチェックアウトするためのエレガントな方法はありますか？

現在、接続が非常に遅いため、会社の git サーバーに新しいブランチをプッシュする必要があります。SVN を使用すると、必要に応じてファイルを一度に 1 つずつリモート SVN サーバーにコミット/プッシュできます。以前は、接続が遅かったとき、一度に 1 つのフォルダーをアップロードでき、うまく機能していました。私は確かにgitで似たようなものを使うことができました。

BitBucket のリポジトリにファイルを追加しようとしていますが、問題が発生しています。

私はGITを使用しており、これが私が入力したものです

次に、これを入力します (これは、BitBucket が入力するように指示するものです)

そして、私はこのエラーメッセージを受け取り続けます:

誰かが私を助けてくれますか？git commit から rm -rf * まですべてを試しましたが、まったく機能しません。

コードレビューにはGerritを使用しています。Gerrit はレビュー済みのコードを非標準の参照パス - に保存しますrefs/changes。したがって、 commit への参照は のようになりrefs/changes/95/295/2ます。プロジェクトを Gerrit からスーパープロジェクトにサブモジュールとして追加したいと考えています。

私は2つのステップでそれを行うことができます:

• プロジェクトをサブモジュールとして、現在マスターが指している commit-hash に追加します
• 変更を実行git fetch origin refs/changes/95/295/2 && git checkout FETCH_HEADしてコミットします。

しかし、スーパープロジェクトをチェックアウトしてgit update --initgit を実行しようとすると、失敗が報告されます。refs/changesGit はサブモジュールでハッシュを見つけることができません。これは、git がデフォルトで参照を認識せず、それらからオブジェクトをダウンロードしないためです。

git config --add remote.origin.fetch '+refs/changes/*:refs/remotes/origin/changes/*'わかりました。私の gerrit リポジトリで実行して修正し、サブモジュールの更新を再試行すれば問題ありません。

質問は、通常のワークフローのように、サブモジュールの「追加」と「初期化/更新」を 1 つのステップで実行できますか? 基本的には、"clone"/"pull"/"submodule add"/"sumbodule update" 実行開始前に refspec を設定する機能が必要です。

GerritとTortoiseGitを使用しています。ログを表示すると、コメント付きの多くのコミットが表示されます

それらは私の作業コミットに接続されていません。それらはrefs「notes/review」から来ているようです。どうすればそれらを隠すことができますか？

私は長い間 Eclipse を GIT および Gerrit と共に使用してきましたが、IntelliJ IDEA (12.1.3) のコミュニティー版を試してみることにしました。リポジトリから変更をフェッチしてプルすることはできますが、プッシュ操作の refspec を指定できる IntelliJ のオプションが見つかりません。IntelliJ内でこれを行う方法はありますか?

私は、マージする必要があるさまざまな Git リポジトリを使用しています。ワークフローは次のようになります。

これで問題ありませんが、タグを使用して各リモートの特定のコミットをプルできるようにしたいと考えています。

各レポの変更は 1 つのサブフォルダーに限定されるため、マージの競合が発生することはありませんが、あったとしてもタコのマージによりトランザクション全体が原子的に失敗します。

問題はタグ参照にあります。このブログ投稿(私のものではありません) で説明されているように、すべてのタグは不可解にもグローバル名前空間にダンプされます。言う方法はありませんfork1/v1.0.0-それはただのことv1.0.0であり、複数のリポジトリに同じタグがある場合、それらは互いに押しつぶされます。

この回答に続いて、refspecs を使用してこれを回避することを検討してきました。これまでのところ、次のことを思いつきました。

これには、fork1 のv1.0.0タグを として到着させるという意図した効果がありfork1/v1.0.0ます。残念ながら、名前空間のない;としても届きます。タグ マッピング セクションで 2 倍の行を出力し、プルされたタグとマージします。refspec に関する適切なドキュメントがどこにも見つかりません (このトピックに関する Git のドキュメントはまったく役に立ちません)。v1.0.0git fetchgit merge v1.0.0

複数のリポジトリのタグが競合しないようにするにはどうすればよいですか?

これについて愚かなことをしているのであれば、他のワークフローの提案にもオープンです。共有コンポーネントと構造を保持する 1 つのコア リポジトリと、コードだけが追加されたコアの完全なクローンである多数のモジュール リポジトリがあります。私の現在の計画は、各モジュールがコアへのリモート ポインター (共有部分の最新情報を取得するため) と、それが依存する他の各モジュールへのポインターを持つことです。共有ビットは同じなのでマージされ、モジュール ビットは独立しているためマージされます。ここで従うべき別のパターンはありますか？(私はサブモジュールを避けてきました。なぜなら、(a) サブモジュールについて良いことを聞いたことがなく、(b) 共有部分はプロジェクト ディレクトリ構造の観点からトップ レベルであり、リポジトリ構造が非常にぎこちなくなります。)

問題は次のとおりです。

私がするたびに

$ git pull 'https://github.com/username/reponame.github.io.git'

その後にURLが続きますが、問題はありませんが、問題が発生した場合

git pull origin master 'https://github.com/username/reponame.github.io.git'

その後に、返される URL が続きます

fatal: Invalid refspec 'https://github.com/username/reponame.github.io.git'

これは何を意味し、どのように修正すればよいですか?

私は現在、Jon Loeliger による本Version Control with Git を読んでいます。

ハードリンクと の 2 つの微妙な違いについて説明しfile://ます。

これまで見てきたように、Git URL の最も単純な形式は、ローカル ファイル システム上のリポジトリを参照します。これは、実際の物理ファイル システムでも、ネットワーク ファイル システム (NFS) 経由でローカルにマウントされた仮想ファイル システムでもかまいません。次の 2 つの順列があります。

/path/to/repo.git

file:///path/to/repo.git

これら 2 つの形式は本質的に同じですが、微妙ではありますが重要な違いがあります。前者は、ファイルシステム内のハード リンクを使用して、現在のリポジトリとリモート リポジトリ間でまったく同じオブジェクトを直接共有します。後者は、オブジェクトを直接共有する代わりにコピーします。共有リポジトリに関連する問題を回避するには、file://フォームを使用することをお勧めします。

./git/object最初は、複製したレポフォルダーがリモートへのリンクだと思っていましたが、そうではないと思います.git/object。

誰かがこれを説明できますか？