問題タブ [rebase]

しようとするとhg rebase -s 1775 --collapse、rev 1774以降に触れたすべてのファイルをマージするように求められます。どうすればそれを回避できますか？

詳細

リベースする方法を学んでいます。ここに示した例といくつかのマイナーなバリエーションを試してみました。ただし、自分のリポジトリで同じ手順を実行すると、リベース時に大量のファイルをマージするように求められます。これが私がすることです。私は何が間違っているのですか？

-r1774にアップデートしたせいかと思ったので、-r1774にタグを付けてチップにアップデートしました。同じ結果。

はhg tag、新しいrev-r1784を作成します。そこで、特に-r1783にアップデートしてみました。同じ結果。

WebとSOで関連する質問を検索しましたが、何も見つかりませんでした。これは、回答が存在しないことを意味するものではありません。既存の回答へのポインタは大歓迎です。

編集：

これは、1.4で修正された報告された水銀のバグに関連しているようです。私はバージョン1.1を持っています。1.4以降にアップデートしようとしましたsudo apt-get install mercurialが、最新のものがあり、Mercurialページのダウンロードリンクが壊れています。したがって、答えは最新バージョンを入手することかもしれませんが、うまくいけば、これを回避する別の方法があります。

以前、クローンを作成してクローンでリベースを実行することでこれを実行しましたが、別のブランチで安全に実行できると思います。

feat-x約25のコミットがある機能ブランチがあります。これらのいくつかを（安全に）一緒に押しつぶしたいと思います。

（最初の数回押しつぶしたので、正しく理解できなかったので、「安全に」と言いますが、クローンで作業していたので、正しい呪文がわかるまで捨てました。）

邪魔することなく押しつぶす実験をすることができるように、どのコマンドのシーケンスが私feat-x-expにそれのコピーを与えるでしょうか？feat-xfeat-x

私は github にオープン ソースの Ruby プロジェクトを持っています。マスター ブランチはリリースされたものを表し、開発ブランチは次にリリースされるものを表します。

master ブランチは dev ブランチよりも 80 以上コミット遅れており、dev ブランチにはかなり重要なアーキテクチャの変更が含まれています。

コントリビューターから、マスター ブランチに基づいて行われた変更のプル リクエストが送られてきました。それらの変更を書き直したり、大量のマージ競合解決を実行したりせずに、これらの変更を開発ブランチに取り込みたい (基本的に変更を書き直すことになります)。

このような状況を処理するためのベストプラクティスは何ですか?

アップストリームブランチをトピックブランチにリベースしようとすると問題が発生します。ワークフローは次のようになります。

結果は次のようになります。

それは昨日私に起こりました、そして私は私の研究をしました、そして何も見つけませんでした、それで結局私はgit merge upstream代わりに使用しました、git rebase upstreamそして物事はうまくいきました。本当の問題は、エラーが今日も表示されることです。昨日のマージにより、すでにアップストリームと同期しています。また、昨日からチームメイトから紹介されたファイルは変更していません。

私のGitバージョンは1.5.6.5です（そして、このマシンでそれを更新する気はありません。望ましくない結果を恐れています）。

それで、昨日、アップストリーム ブランチをローカル トピック ブランチにリベースしようとしたときの奇妙な競合に関する質問を投稿しました。

最後にgit rebase --merge upstream、以前のリベース以降に触れていないファイル内の多くの競合を使用して解決しました。

このような場合のリベースについての私の理解では、コミットをそのトピック ブランチから切り離し、上流のブランチからコミットを適用してから、それらの上にコミットを (パッチとして) 適用します。そのため、早送り操作になってしまいます。私が理解していないのは...上流からのコミットとマージの競合が発生するのはなぜですか。それらもパッチとして適用されますか? 私はただ...同じブランチから来た前のコミットの上にいくつかのコミットを「溶接」する行為だと思いましたか？

触れていないファイルに多くの競合があったため、これを求めています。ああ、私はこのアップストリーム ブランチで毎日リベースを行っています。

アップデート

アップストリームからトピック ブランチに持ち込まれたコミットの一部で、SHA-1 ID が変更されていることに気付きました。Gitがこれを行う原因を知っている人はいますか? それは--mergeスイッチでしょうか？

私のgitバージョンは1.5.6.5です

さて、私はほとんどこのリベースのことを理解しています。

ブレークスルーが来るのを感じることができます-ここに転換点があります：

リベースを行うにはどうすればよいですか？

に：

HEAD〜1をbranch1にマージするだけでなく、branch1をリベースしたいと思いますか？

私はこれをほとんど理解しているような気がします-助けて！？

master から "feature" ブランチを作成し、長い間作業しました。次に、最新のマスター ブランチのコミットを取得し、その上に「機能」ブランチのコミットをリベースしました。次に、「機能」をマスターにマージしました。しかし、マージのことを忘れて、「feature」ブランチにコミットし続けました。これらのコミットを新しいブランチに入れたいので、マスターへの最後のマージ以降の「feature」ブランチでのコミットに基づいて、別のブランチ「feature_2」を作成したいと思います。助言がありますか？

クライアントごとにカスタマイズされた基本システムがあります。ベースは独自のリポジトリに存在し、各クライアントは独自のリポジトリに存在します (元はベースからクローンされています)。

目標は、必要に応じてクライアントに伝播できるバグ修正/機能をベースに追加できるようにすることです。

これまでのワークフローは次のとおりです。

• ベースの修正/機能のコミット/トピック ブランチを作成します: (ベース、マスター)git commit -m "Fix admin typo"
• これらの変更をクライアントにマージします: (on client, master) git merge base/master。明らかに、これにはベースとクライアントのカスタマイズ間の競合の修正が含まれます。
• マージをクライアントのオリジンにプッシュします: (クライアント、マスター上)git push origin master
• 私たちの慣例は、rebase でプルすることです (履歴を読みやすくするため)。そのため、クライアント プロジェクトで作業している別の開発者が (クライアント、マスターで)git pull --rebase origin master

この時点で、そのプル/リベースで重大な問題が発生します。開発者は、ベースからクライアントへのマージ後に実行されるプル/リベースで競合を取得します。そして、それはほんの少しの競合ではなく、多くの競合であり (多くのコミットがリプレイされていますか?)、特定の開発者がまったく触れていないコードが頻繁に発生します。これは理不尽で持続不可能だと思います。

ここで最善の解決策は何ですか？

私の唯一の考えは、プルするときにリベースの使用をやめ、ずさんで読みにくいログに対処することですが、これを行う必要はありません。これらのクライアント プロジェクトは何年も存続する可能性があり、今後も基本システムのマージをある程度理解できるようにしたいと考えています。

VS2008（それは正しいですか？）以降、MSVCリンカーオプションにはベースアドレスのランダム化があります。

この機能の主な目的は何ですか？

私が嬉しいのは、DLLを手動でリベースする必要がなくなったことです。

それで全部ですか？それは彼らの目的でしたか？
他に何かメリットはありますか？

基本的に、私が試したいのは、実験リポジトリのブランチからメインラインのクローンに hg リビジョンをプルすることです。しかし、サーバー側のメインライン リポジトリに直接プッシュできるように、ブランチ名を破棄したいと考えています。簡単な例を挙げるのがおそらく最善です：

ご覧のとおり、メインラインには「branch: bar_branch」を含むリビジョンが含まれています。このリビジョンにブランチを持たせたくありません (つまり、デフォルトにする必要があります)。

これがrebase、移植、または別のツールで履歴を書き換える必要がある場合は問題ありません。私はこれらの両方を試しましたが、うまくいきませんでした。最新のリビジョン ハッシュは、2 つのリポジトリ間で異なる場合があります。

したがって、hg_mainline の最上位リビジョンを次のようにしたいと考えています。

名前付きブランチなし。

繰り返しますが、ハッシュが hg_experimental から保存されていなくても問題ありません。

現在、Ubuntu PPA から hg 1.6.2+55-18e1e7520b67 を使用しています。

編集：

1.3.1も使用しました。両方で以下をテストしましたが、ここでの結果は同じです。

grep -v移植で動作しましたが、クラッジでのみ動作しました。

と：

hg export は、適切な grep の有無にかかわらず機能しませんでした。

変更セットのパッチは次のようになります。

私は実験からエクスポートしました：

そして、メインラインにインポートしようとしました:

次のエラーで失敗します。

編集2：

前述のように、エクスポート メソッドは、ファイルが空だったという理由だけで失敗しました。--git空でないファイルでも正しく動作します。