記事「MQL5 Algo Forgeへの移行（第2回）：複数のリポジトリの操作」についてのディスカッション - ページ 2

新しいコメント
 
Vladislav Boyko #:

改良の過程で、MetaEditorとウェブ・インターフェイスだけを使って、いくつかの原始的な分岐戦略を何度か繰り返してみることをお勧めする。

  1. nextブランチを作成し、そこでいくつかのコミットを行う。
  2. nextをmainに流し、nextを削除
  3. 新しい親コミットで再度nextを作成し、数回コミット。
  4. ...

3は、外部ツールを使わないとできない。そのため、ポイント2がサイトを通して行えるからといって、それが簡単になるわけではなく、行き止まりになってしまう。

私はこの議論で新しいことは何も言っていない。私はすでに数ヶ月前にこのすべてを報告した。現在、ポイント1と2を説明した記事があるが、どういうわけかポイント3はその記事にはない（ポイント3は論理的に続いているが）。

項目3が欠落しているのは、私は異なる特徴の枝に異なる名前を付けるアプローチを好むからであり、常に同じ名前を付けるわけではない（次へ）。あなたのアプローチでは、なぜnextが削除されなければならないのか、私にはわかりません。これは、main/developバンドルのdevelopブランチと同じような意味に思えます。

 
Vladislav Boyko #:

数日間ブレインストーミングをした結果、少なくとも "壊れた "ファイルのリストを埋める方法を見つけることができた。

そうそう、一時期、共通リポジトリからコンパイル済みのファイルをすべて消去するスクリプトも試したが、これはすぐに不要だと判明した。ファイルの差分を処理するためにウェブ・インターフェイスを使うことはなかったので、そこに内容が表示されないことはどうでもよかったのだ。だから、"壊れた "ファイルのリストを見つけることは可能だ。それらがすべてMEによって作成されたファイル（UTF-16 LEエンコード）であることがすでに分かっているのなら、それはREADME.md、.gitignoreと他のいくつかのファイルを除いた私のリポジトリファイルすべてです。

 
Yuriy Bykov #:

レナトさん、すべてのソースをUTF-8に変換することに意味があるのか、それともMEはUTF-16 LEだけを指向し続けるのか教えてください。新しいビルドのブランチかどこかのどこかに、UTF-8への移行について言及されていたと思うのですが、もしかしたらそう思われたのでしょうか？

あ、MEで新規ファイルを作成（New Class）しただけなので、すぐにUTF-8で作成されました。

 
Yuriy Bykov #:
あなたのやり方では、なぜ次のブランチを削除するのかがわかりません。

私はいつも、ブランチがより高い安定性レベルのブランチに完全にマージされたら、すぐにブランチを削除します。これは習慣だし、とても便利な習慣だと確信している。

純粋に技術的なレベルでは、ブランチを再構築すると、親コミット（次のコミットの親コミット）という形で目に見える違いが出ることがよくあります。これは重要ではなく、コミットグラフの使い勝手に影響するだけということもありますし、作り直さないとどうにもならないこともあります。

[編集]。

一般論として、ローカルリポジトリからブランチを削除する必要があると主張するのはおかしいと思います。GitのブランチモデルはGitのキラー機能であり、Gitは頻繁にブランチを作成、削除、マージすることを推奨しています。

 
Yuriy Bykov #:
ファイルの違いを扱うのにウェブインターフェイスを使うことはなかったので、そこにコンテンツが表示されないことは私には問題ではなかった。

私もウェブ・インターフェイスを使うことはほとんどない。MetaEditorのGitボタンも使わない。ターミナルでGit Bash for Windowsを見ている。

Yuriy Bykov#:
「壊れた」ファイルのリストを知ることができるわけですが、なぜでしょう？

壊れたファイルのリストを知るのは、それを修正するためです。diffを見るために修正する。

diffは何のためにあるのか？[自動翻訳機に問題を引き起こしていた重要でない文章を削除]。

 
Yuriy Bykov #:
これらがすべてMEによって作成されたファイル（UTF-16 LEエンコーディング）であることがすでに知られている場合

私は数ヶ月前にこれをテストしました。ウィザードはUTF-8（壊れたファイルではなく正常なファイル）を作成します。MT4のウィザードでさえ、正常なファイルを作成します。これらのテスト中、ウィザードから「壊れた」ファイルを入手できたことは一度もなかった。

私はコミットする前にそのスクリプトで ファイルをチェックすることがある。正常なファイルが突然エンコードを変更するケースもあった。おそらくクリップボードから何かを挿入した後だろう。キリル文字がそこにあったとは考えにくい - 私はずいぶん前にコメントでさえ使うのをやめた。

 
Vladislav Boyko #:
キリル文字はほとんどなかった。私はずっと前に、コメントでもキリル文字を使うのをやめた。

どうやら私の思い違いだったようだ。これを.mq5ファイルにUTF-8エンコーディングで追加した：

// キリル文字

保存するとエンコーディングが「UTF-16 LE BOM」に変わった。

MetaEditorのせいらしい。キリル文字を追加し、Notepad++を使ってファイルを保存したところ、エンコーディングはUTF-8のままでした。

 
Vladislav Boyko #:

また、ローカルリポジトリからブランチを削除できるようにする必要性を主張するのは奇妙だと思います。GitのブランチモデルはGitのキラー機能であり、Gitはブランチの頻繁な作成、削除、マージを推奨しています。

ですから、メインブランチにマージした後にブランチを削除することにも賛成です。ただ、削除した後に、新しいブランチではなく同じ名前の新しいフィッシュ用のブランチを作るというのは初めて聞きました。

diffを見る目的は何ですか？

そうですね、とても必要なものです。私も積極的に使っていますが、VS Codeでしか使っていません。そしてそこでは、不思議なことに、"悪い "エンコーディングのファイルに目を通しても、クラッシュすることはない。

コミット 前に そのスクリプトで ファイルをチェックすることもある。そして、結局のところ、何もなかったわけではないのだ。正常なファイルが突然エンコーディングを変更するケースがあった。おそらくクリップボードから何かを挿入した後だろう。

そんなことに遭遇したのは初めてだ。それもかなり予想外のことだ。もしかしたら、正常なファイルが壊れたのは、同じファイルを扱うために異なるMEビルドを同時に使ったせいかもしれない？わからないけど...。

コミット履歴を見たところ、2ヶ月前に追加されたファイルは確かにすでにUTF-8エンコーディングで、3ヶ月前に追加されたファイルはまだUTF-16 LEでした。どうやらその頃にどこかでUTF-8エンコーディングへの切り替えがあったようだ。

 
Vladislav Boyko #:

私が間違っていたようだ。これを.mq5ファイルにUTF-8エンコーディングで追加しただけだ：

保存後、ファイルのエンコーディングが「UTF-16 LE BOM」に変更されました。

MetaEditorのせいのようです。キリル文字を追加し、Notepad++を使ってファイルを保存したところ、エンコーディングはUTF-8のままでした。

ロシア文字を追加してファイルを保存すると、エンコーディングがUTF-8からUTF-16 LEに変わることを確認しました。ロシア文字をすべて削除して保存しても、UTF-16 LE のままです。

 
Vladislav Boyko #:
MetaEditorのせいらしい。

UTF-8とキリル文字とGitを互換にできる証明はこちら：

https://forge.mql5.io/junk/utf8-cyrillic-test/commit/e87d37b02e88d44305dea0f7f6630c6173471aea

必要なのは、MetaEditorにファイルのエンコーディングを変更しないように頼むことだけです。

123
新しいコメント