ｿｰｽｺｰﾄﾞﾎｽﾃｨﾝｸﾞ総合【GitHub,GitLab,Bitbucket等】

**デフォルトの名無しさん** · 2018/07/17(火) 19:44:50.42

ソースコードホスティングサービスについて情報交換したり語り合ったりするスレ

ソースコードホスティングサービスの例
GitHub GitLab Bitbucket SourceForge Launchpad など

OSSホスティングサービスの比較 - Wikipedia
http://ja.wikipedia.org/wiki/OSS%E3%83%9B%E3%82%B9%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E6%AF%94%E8%BC%83

Comparison of open-source software hosting facilities - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Comparison_of_open-source_software_hosting_facilities

前スレ
OSSホスティング総合【SourceForge,GitHub,etc..】
https://mevius.5ch.net/test/read.cgi/tech/1384821518/

**デフォルトの名無しさん** · 2019/10/19(土) 17:45:04.72

いずれにせよソースコード表示させるには画面狭すぎる

**デフォルトの名無しさん** · 2019/10/19(土) 22:20:43.30

そうなりますよね
ありがとうございます！

**デフォルトの名無しさん** · 2019/11/03(日) 13:43:41.47

GitHubのPull requestでブランチ名の右に<アカウント名>:<ブランチ名>をコピーするためのボタンあるよね。あれって何のため？アカウント名とブランチ名をコロンで連結した文字列を取得して何か嬉しいことあるっけ？

**デフォルトの名無しさん** · 2019/11/14(木) 08:10:43.50

［速報］「GitHub for mobile」ベータ公開。iPhoneやAndroidからプルリクエストやマージなど操作。GitHub Universe 2019
https://www.publickey1.jp/blog/19/github_for_mobileiphoneandroidgithub_universe_2019.html

**デフォルトの名無しさん** · 2019/11/14(木) 14:32:13.07

GitHub Universe 2019: GitHub for mobile, GitHub Archive Programなどの新機能を発表
https://github.blog/jp/2019-11-14-universe-day-one/

GitHub for mobileで、どこにいても柔軟に仕事を進め、チームと連絡を取り合うことができます。
GitHub for mobileを使うことで設計に関するディスカッションについてフィードバックを共有する、数行のコードをレビューするなど、複雑な開発環境を必要としない多くの作業をどこからでも簡単に実行できるようにしました。
GitHub for mobileは美しいネイティブエクスペリエンスを実現しており、開発者はどこからでもコードをレビューし、変更をマージできるようになります。

GitHub for mobileは、ネイティブアプリケーションとしてあらゆる画面サイズに自動的に適応し、デバイスの設定に応じてダークモードにも対応します。

**デフォルトの名無しさん** · 2019/11/16(土) 12:02:05.19

ようやっとGitHubの機能がGitLabに追いついてきたか？
パイプライン導入までずいぶんかかったね

**デフォルトの名無しさん** · 2019/11/16(土) 20:22:15.12

>>234
マイクロソフトによる買収のおかげかな
VSTSにパイプラインあるもんね

**デフォルトの名無しさん** · 2019/12/06(金) 16:10:00.37

OSDNて全然話題に上がらんけど使ってる人おらんのけ？

**デフォルトの名無しさん** · 2019/12/06(金) 16:12:16.09

もうオワコンやろ

**デフォルトの名無しさん** · 2019/12/17(火) 09:42:20.56

ERROR: Repository not found.
fatal: Could not read from remote repository.
云々のエラーでてsshも設定、公開鍵も設定して
sshで接続確認したらsuccessfully出たんでイケたかと思ったらまた同じエラーがでる
考えられるのは、プロジェクト作成直後だから？
２４時間経たないとだめとかそんな制約あったっけ

**デフォルトの名無しさん** · 2019/12/17(火) 10:16:11.96

自己解決
repository作ってたと思ったらprojectを作ってただけだった
同名のrepository作ったらpushできた

**デフォルトの名無しさん** · 2020/01/03(金) 14:23:49.23

GutHug

**デフォルトの名無しさん** · 2020/01/05(日) 10:28:55.70

Your account has been flagged.くらってsupport.github.comの一番下のContact usから英文送ったけど
音沙汰無し
おそらく別のipからログインしたのが原因だと思うが腫れ物に触るようなログインしなきゃいけないのか

**デフォルトの名無しさん** · 2020/01/05(日) 11:38:14.33

一年くらい前からログインした後確認番号のメール送ってくるようになったけど
あのメールを別の端末で読んでてそのままそっちの方でブラウザ開いて番号入れて
って流れになることも多いよな

途中からIP変わるとハイジャック観たいに扱われるのは困る

**デフォルトの名無しさん** · 2020/01/05(日) 22:19:46.89

会社・自宅・ときどき出先って感じの3箇所くらいの別IPなら普通にやってるけどな。
別の理由じゃね？

**デフォルトの名無しさん** · 2020/01/07(火) 21:14:34.13

proxyとvpn通してログインできるかどうか試したときに
今までの通常環境でログアウトした直後にvpn環境で即ログイン（２往復くらい）
その直後に薄赤色のbarが出てきてフラグ立ったから
ほぼ間違いなくそれが原因だと思う
ただ運営からは一切返信ないからわからん
永久BANかどうかくらいは教えて欲しいものだが

**デフォルトの名無しさん** · 2020/01/08(水) 14:26:20.06

publicで使ってるなら別アカウント造ってforkしまくるしかないかな

**デフォルトの名無しさん** · 2020/01/09(木) 19:55:57.20

無料アカウントは１人１つまでです。それ以上はBAN

**デフォルトの名無しさん** · 2020/01/12(日) 13:11:48.53

ホンマか？w

**デフォルトの名無しさん** · 2020/01/12(日) 13:32:17.96

>>247
建前は >>246 の言う通りでBANされた人もかつて存在したようだから事実では?

**デフォルトの名無しさん** · 2020/01/12(日) 14:59:13.44

よほど目に余る行為をしてなければお目こぼしされてると思うけど。
家庭用と仕事用でアカウント分けてる人はいっぱいいるよね。
俺は一つだけどw

**デフォルトの名無しさん** · 2020/01/16(木) 15:00:15.16

https://help.github.com/ja/github/getting-started-with-github/types-of-github-accounts

＞個人での使用や仕事での使用など、1 つのアカウントを複数の目的で使用できます。複数のアカウントを作成することはおすすめしません。

**デフォルトの名無しさん** · 2020/01/17(金) 08:44:09.33

アカウント1つだと会社バレしたくない人は困るじゃん。

**デフォルトの名無しさん** · 2020/01/17(金) 09:15:51.46

https://help.github.com/en/github/site-policy/github-terms-of-service#b-account-terms

> you may not have more than one free Account.

ok?

**デフォルトの名無しさん** · 2020/01/17(金) 09:20:04.97

無料アカウントは１つまでだが、課金アカウントには制限がないって話でしょが

**デフォルトの名無しさん** · 2020/01/17(金) 11:13:31.20

おまいらセンター受験日だから置換やり放題だって馬鹿ツイートしてる香具師らと一緒だな

**デフォルトの名無しさん** · 2020/01/17(金) 18:10:12.82

GitHub Actions使ってる人いる？
複数のOSに対応する都合上、複数のCIサービスと連携してるんだけど
全てのCIが成功した後に処理を実行することってできる？

**デフォルトの名無しさん** · 2020/01/27(月) 13:02:17.38

githubでフォークしたレポジトリが更新されたときに、
ブラウザ操作で自分のレポジトリに更新を同期する方法有る？

**デフォルトの名無しさん** · 2020/01/27(月) 17:01:39.72

forkしただけのものなら
削除して再forkならブラウザで可能

**デフォルトの名無しさん** · 2020/01/27(月) 19:31:49.60

プルリクでFFとかでfork追えんのか？

**デフォルトの名無しさん** · 2020/02/20(木) 07:35:40.17

初歩的質問で悪いんだけど
githubで最新のgitをダウンロードしたい場合ってどこにあるの？
アカウントないとDLできないの？

**デフォルトの名無しさん** · 2020/02/20(木) 09:34:55.69

せやで

**デフォルトの名無しさん** · 2020/02/20(木) 09:43:50.69

>>260
嘘はイカン

>>259
そういう知識レベルなら
ttps://tortoisegit.org/
がいいと思う。

一般には
ttps://git-scm.com/downloads

**デフォルトの名無しさん** · 2020/02/20(木) 14:05:26.57

>>259
[clone or download] - [download zip]ならアカウントなしで取得できるよ

**デフォルトの名無しさん** · 2020/02/20(木) 14:09:05.23

マジレスすると >>262 でも良いけど

どっちかというと本来の使い方で言えば
まず >>261 のところから自分の OS 用の git をダウンロード
それから自分のリポジトリ造りたいディレクトリ上で
git clone https://hogehoge.github.com/fugfuga.git

**デフォルトの名無しさん** · 2020/02/20(木) 15:43:16.71

>>262
できたさんくす

というかパッケージを管理するアカウントが別れてて
正式版とベータテストでわかれてた

**デフォルトの名無しさん** · 2020/03/03(火) 09:40:22.98

コーディングのド素人で今まで一度もこういうものに触れた事のないのだけれども
とあるゲームのMODの翻訳の編集のためにGitHubに参加させてもらってる状況です
もちろんGitHubの使い方なんてほとんどさっぱりで、ギリギリなんとか
リポリトジ、プッシュ、コミット、プルリクエスト、マージ、という流れで複数人が編集を共有しているのだというのはなんとなく把握できたレベル

で質問したいのですが
相手方のファイルが久々に更新されたので早速ファイルを翻訳しリポリトジを更新していざプルリクエストを送ってみた所
自分が触っていないファイルもそのコミットにひとまとめに更新された事になってしまい、リクエストの更新個所も膨大な数になってしまいました
こういう場合、相手(マスター？)にはどう映っているんでしょう？
やっぱりそのフォルダに入ってた一切合切もプルリクエストに含まれてしまってるんだろうか
それとも、中身が同一なファイルは自動的に除外されたりはしないんでしょうか。それだったら助かるのだけど…

**デフォルトの名無しさん** · 2020/03/03(火) 09:42:59.96

あ、訂正
プルリクエストはまだ送ってない。送ろうとした直前の確認画面までで止めました

例えばもう一回クローンやり直しとかすれば、相手側のブランチ？を汚したりせずに済むとかそんな事あります？

**デフォルトの名無しさん** · 2020/03/03(火) 09:44:43.61

ちなみに、両者のファイルの(翻訳した箇所以外の)内容はどれも同一である事は比較ソフトで確認しました

**デフォルトの名無しさん** · 2020/03/03(火) 13:51:42.17

ホントにまったく変更されてないのであれば更新箇所として表示されないので
実際には
・改行コードが変わった
・文字コードが変わった
・空白が増えたor減った
といった違いがあるはず。

こういうのがあるとそのままマージできないし
該当ファイルの変更作業をしている別の人の邪魔になるしで
嫌がられる。

pullreqを実際に出す前に原因調べて直すべき

調べても分かんないなら自分のリポジトリのURLをここに張ればたぶんすぐ判明するぞ

**デフォルトの名無しさん** · 2020/03/03(火) 15:21:46.58

・改行コードが変わった
・文字コードが変わった
・空白が増えたor減った
どれもぶん殴られるパターン

**デフォルトの名無しさん** · 2020/03/03(火) 16:10:37.59

＞更新箇所として表示されないので
ですよね。
自分も以前までは自分トコに上書きしても、自分が弄った部分だけがコミット？に上がってたので
今回も気にせずその今まで通りやったつもりだったんスよ。で今回はいつもと違って
突然ぶわっとすごい数の一覧が挙がったので、さすがにド素人の自分でもおかしいとは気づきました
なのでクローンを落としてそれと自分のとを比較ソフトで相違を確認したりもしました
自分が触ったトコ以外は寸分違わぬ状態だったのを確認しとります

例えば、自分がリクエスト上げたタイミングがまさにあっち側が作業中だった。って事も有り得ますよね？
ちょっとまだブランチの仕組みが今一把握できていない…ぱられるわーるど的な？ｗ

**デフォルトの名無しさん** · 2020/03/03(火) 16:12:17.35

あと、アレです
日本語翻訳以外にも、ロシア語だの中国語だのイタリーだのドイツ語だの、複数の言語が飛び交ってるんですよ
色んな方から翻訳文のプルリクエストが飛んでるみたい。自分はその隙間を縫ってコソっと送るカンジでやってるんですけど

**デフォルトの名無しさん** · 2020/03/03(火) 16:40:24.45

｢比較ソフトで比較｣ってのがまずダメでは?
その手のソフトが余計なお節介で改行コードとか文字コードとか空白の違いを無視してるのかもしれん。

git diff
で比較すべき

**デフォルトの名無しさん** · 2020/03/03(火) 17:08:40.61

>>272
「Win Merge」ってヤツなんだけど、どうでしょう
https://winmerge.org/?lang=ja

といっても、基本的にコードを弄ったりしてるのではなく、ただテキストを加筆してるだけなので多分大丈夫だとは…
とやきもきしてたら勢い余ってプルリクエスト送信してしまいました…(ﾃﾍﾍﾟﾛ)
どうも即座に反映してくれたみたいなので、大丈夫だったっぽい？
Github上での一覧のコメント見るに、自分が弄ったファイルだけが反映されてる様なので結果的に良かった

いや、素人がこういうのに手出しちゃダメっすね…

**デフォルトの名無しさん** · 2020/03/03(火) 17:28:37.35

むしろwinmergeが悪さして破壊してるんじゃね

**デフォルトの名無しさん** · 2020/03/04(水) 11:26:42.25

WinMergeはそんな悪さしないけどなあ
VSで改行コード混在してるけど統一していいか？とか聞かれなかった？

**デフォルトの名無しさん** · 2020/03/04(水) 12:47:20.02

autoclfじゃねぇのか

**デフォルトの名無しさん** · 2020/03/04(水) 23:08:18.78

WinMergeは改行ズレを自動的に補正してくれる優秀な子だよ

**デフォルトの名無しさん** · 2020/03/06(金) 10:24:47.58

>末尾の空白が消える

**デフォルトの名無しさん** · 2020/03/19(木) 14:35:07.73

GitHub for mobile の正式版をリリース
https://github.blog/jp/2020-03-19-github-for-mobile-is-now-available/

**デフォルトの名無しさん** · 2020/03/26(木) 05:25:41.46

GitHubにIssueのvote機能ないかね？
いつの間にか、親指立ててあったりしても気づかんのよね。
票が多ければそれを優先対応したいんだが

**デフォルトの名無しさん** · 2020/04/15(水) 02:09:17.32

GitHubきたな
https://github.blog/2020-04-14-github-is-now-free-for-teams/

**デフォルトの名無しさん** · 2020/04/15(水) 02:46:01.60

ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!

**デフォルトの名無しさん** · 2020/04/15(水) 06:03:02.83

500GBまでならfreeでも使えるってイイね

**デフォルトの名無しさん** · 2020/04/15(水) 10:22:23.10

>>283
MBじゃなくて？

**デフォルトの名無しさん** · 2020/04/15(水) 14:38:36.26

>>281 日本語訳

GitHubのコア機能を無料で利用できるようになりました
https://github.blog/jp/2020-04-15-github-is-now-free-for-teams/

**デフォルトの名無しさん** · 2020/04/15(水) 16:32:17.35

マジか！とうとうコボラデータが使えるように！

**デフォルトの名無しさん** · 2020/04/15(水) 16:59:23.71

ProプランはTeamプランに変わった？

**デフォルトの名無しさん** · 2020/04/15(水) 17:40:14.43

変わったというかそのへんの体系が全部見直された

**デフォルトの名無しさん** · 2020/04/15(水) 17:58:40.56

一人で使うプライベートリポジトリでWiki使えるようにしてほしかった

**デフォルトの名無しさん** · 2020/04/15(水) 17:59:48.88

プライベートならどっかに書いとけよ

**デフォルトの名無しさん** · 2020/04/15(水) 20:56:02.82

Proは無くなったわけじゃないけど一覧からは消えたのか
Freeとの差別化が難しいからかな

**デフォルトの名無しさん** · 2020/04/16(木) 02:26:41.91

>>284
MBでした…

**デフォルトの名無しさん** · 2020/04/16(木) 11:11:19.96

>>289
使えるやろ

**デフォルトの名無しさん** · 2020/04/22(水) 08:38:04.96

18 GitLab features are moving to open source
We're open sourcing rich functionality across Plan, Create, Verify, Package, Release, Configure, and Defend.
https://about.gitlab.com/blog/2020/03/30/new-features-to-core/

**デフォルトの名無しさん** · 2020/05/03(日) 21:17:29.85

githubで送ったプルリクが取り込まれたんですけど、
その後に不具合がありました
この場合って新規でプルリクを作成して送ればいいんでしょうか？
それとも最初に送ったプルリクのスレッドにプルリクを送るのでしょうか？

**デフォルトの名無しさん** · 2020/05/03(日) 23:21:59.66

>>295
そのプロジェクトの方針に従うのが一番。いきなりプルリクエストってのはNGなとこもあるし。
プルリクエストがもうmergeされたなんなら、ひとまずissueたてて、リグレッション起こしたそのプルリクエストへのリンクを貼っとくってのが無難。

**デフォルトの名無しさん** · 2020/05/04(月) 02:07:07.23

> いきなりプルリクエストってのはNGなとこもあるし。
ほんとにあるの？
アホな日本のプロジェクトならありそうだがｗ

プルリクは送っていい。駄目なら駄目って指摘があるやろ？
くだらないIssue立てて怒るやつはいても、プルリクを送って怒るやつはいない。
それよりかIssue管理する手間のほうが面倒
一番時間がかからないのはどれか？無駄な手続きで手間増やすよりも手間が少ない方を選べ

**デフォルトの名無しさん** · 2020/05/04(月) 02:09:02.33

>>295
そもそもマージされてクローズされたものに追加でプルリク送れんやろ？

さっさと新しくプルリクだせ。
コード（とテスト）に問題なければ、すぐマージして終わりやろ

**デフォルトの名無しさん** · 2020/05/04(月) 02:12:29.19

>>297
え…普通にあるやろ。まず方針をディスカッションしてからってのはごくごく一般的。
publicなAPIに変更がある場合なんかは特にね。リリースノートを自動作成する際にissueをもとにしてるプロジェクトもあるし。

**デフォルトの名無しさん** · 2020/05/04(月) 02:24:57.53

>>297
https://github.com/dotnet/runtime/blob/master/CONTRIBUTING.md#dos-and-donts

>DON'T add API additions without filing an issue and discussing with us first. See API Review Process.

まあ不具合を把握しているのであれば、修正に取り組む前にとりあえずissueたてて共有すべきだとは思うけどね。

**デフォルトの名無しさん** · 2020/05/04(月) 02:46:34.20

オープンソースなのにいきなりプルリクNGはガイジ
機能を理解できてない

いきなり何らかのリクエストされても、それをマージするまでにクッションを置いて、考慮する為の「リクエスト」なのに、それすらだダメならソース公開するのやめて身内で細々と開発すりゃいいｗ

**デフォルトの名無しさん** · 2020/05/04(月) 02:53:33.57

>>300
それのどこにいきなりプルリク禁止って書いてあるんですか？ｗ

英語読めないなら翻訳してあげましょうか？ｗ

>問題を提出して最初に私たちと話し合うことなくAPIの追加を追加しないでください。 APIレビュープロセスを参照してください。

**デフォルトの名無しさん** · 2020/05/04(月) 02:55:04.97

>>302
いや英語読めてないのお前やんw

**デフォルトの名無しさん** · 2020/05/04(月) 02:55:50.20

>>301
issueでディスカッションしてから実装ってのは一般的だよ

**デフォルトの名無しさん** · 2020/05/04(月) 02:56:42.00

>>302
これは恥ずかしい

**デフォルトの名無しさん** · 2020/05/04(月) 03:00:56.79

こっちもそうだね。現実が見えない人なのかしら。
https://github.com.cnpmjs.org/dotnet/wpf/blob/master/Documentation/contributing.md

>Please open issues for changes that affect the IL or might require additional validation, and work with the project maintainers to determine whether a PR would be appropriate.

**デフォルトの名無しさん** · 2020/05/04(月) 03:01:05.65

>>304
一般的とは？
10個ぐらい見つけてこれる？

**デフォルトの名無しさん** · 2020/05/04(月) 03:01:58.87

またdotnet（笑）
そういうものしか見つけられないんだろうね
dotnetとか普通のオープンソースとは違うやろ

**デフォルトの名無しさん** · 2020/05/04(月) 03:04:10.14

教えて君か…一人でここで吠えてるといいよ
現実は変わらないけどね

**デフォルトの名無しさん** · 2020/05/04(月) 03:04:51.25

>>308
普通のオープンソースとは？

**デフォルトの名無しさん** · 2020/05/04(月) 03:08:18.03

>>297
>ほんとにあるの？
あったやろw

**デフォルトの名無しさん** · 2020/05/04(月) 06:39:00.60

ちゃんと上長に電話で許可取ってからプルリクしろよ

**デフォルトの名無しさん** · 2020/05/04(月) 07:00:08.78

ハンコ下さい

**デフォルトの名無しさん** · 2020/05/04(月) 12:24:50.51

電話じゃだめ
書類にはんこじゃないと

**デフォルトの名無しさん** · 2020/05/04(月) 12:30:45.25

>>303
API追加についてはレビュー必須って書いてあるだけだぞ。
バグフィックスならいきなりpullreqでもOKだろう。

例に挙げるならバグフィックスでもissue必須なプロジェクトを挙げなくてはいかんな。

**デフォルトの名無しさん** · 2020/05/04(月) 12:32:47.20

>>306
こっちもIL追加についてはレビュー必須って書いてあるだけじゃん。
バグフィックスについてはいきなりpullreqでOKなプロジェクトの例になってるな。

**デフォルトの名無しさん** · 2020/05/04(月) 13:43:15.82

>>316
ILが何かわかってないことがバレバレ

**デフォルトの名無しさん** · 2020/05/04(月) 13:52:26.06

>>315
ソースまであげたのに読まずに批判とは恥ずかしい。
コントリビューションのフローは1がissue、プルリクは7な。issueをスキップできるのはtrivialな変更の場合で、具体例としてはtypoね。

https://github.com/dotnet/runtime/blob/master/CONTRIBUTING.md#suggested-workflow

**デフォルトの名無しさん** · 2020/05/04(月) 14:21:53.30

バグ見つけたんならとりあえずissue上げておかないと、修正したりテストやってる間に他の人がそのバグを踏む可能性があるからね。
まずはバグを報告させるってのはOSSに限らず別に珍しくはないと思うんだが…
長く使われているライブラリやフレームワークだと、バグであったとしてもそのバグがあることが前提で動いているコードが世の中に溢れている、なんてことはよくあるから単純に直せばいいって訳でもない。

**デフォルトの名無しさん** · 2020/05/04(月) 14:26:46.93

>>316
「please file issues to make bugs "known"」ってあるけど、どこに「
バグフィックスについてはいきなりpullreqでOK」と書いてあるんですか？

**デフォルトの名無しさん** · 2020/05/04(月) 14:35:27.86

>>318
typoは例として挙げられてるだけで
バグフィックスだって off by one みたいな trivial な奴ならいきなり pullreq でも OK だろう。
テストコードもつけとく必要はあるだろうけどね。

**デフォルトの名無しさん** · 2020/05/04(月) 14:38:16.94

>>321
ランタイムのバグ修正は本当にtrivialなものかどうか見分けるのが大変だから、フローに書いてあるとおりまずはissueが筋。
テストコード書く前にissue上げとけよ。自分一人の趣味プロジェクトなら別にいいんだけどね。

**デフォルトの名無しさん** · 2020/05/04(月) 14:40:33.84

>>321
え、off by oneならIL変わるやろｗｗｗ
どのリリースに含めるべきかどうかも検討しなくちゃいけないんで、まずはissueね。

**デフォルトの名無しさん** · 2020/05/04(月) 14:46:36.93

バグ見つけたのに報告せず自分で抱え込んじゃうやつとか、まじで害悪やろ。こんなバグ見つけたから修正するねーってissue上げることの何が難しいんだろう。フローにもわざわざ丁寧にissue書けって明示してあるんだし。

**デフォルトの名無しさん** · 2020/05/04(月) 14:51:05.39

バグ修正ならなおさらメンテ中のどのバージョンで修正するかって方針も決めなきゃいけないしね。最新の4.X系だけでいいのか、1.X～4.Xまで全部修正するのか、みたいな。それによってどのコードをベースにして修正方針を立てるのかが変わってくる。

**デフォルトの名無しさん** · 2020/05/04(月) 14:59:15.66

>>323
元URL読んでなくてCLRランタイム側のIL解釈の実装が変わる場合と勘違いしてた。
正直ｽﾏﾝｶｯﾀ
WPFのリポジトリだからそもそもそんなことありえないし
ここはコードの整形程度の話であっても生成されるILが変わるならダメって文脈なんだな。
これは厳しい。

まあでもこれは利用者の数がやたらと多い dot net の Microsoft 公式リポジトリだから厳しいって話であって
github のプロジェクトのなかではむしろ例外的だと思うよ。
ふつうの規模のプロジェクトだと issue と PR で二重に同じ話が出てくると手間が増えて嫌がると思うよ。

**デフォルトの名無しさん** · 2020/05/04(月) 15:13:17.00

>>319
だからなんなのかわからん

お前が言ってることへの対応なら、
とりあえずissueでも、とりあえずprでも、どっちでもいいだろ

**デフォルトの名無しさん** · 2020/05/04(月) 15:13:57.17

>>320
> バグフィックスについてはいきなりpullreqでOK」と書いてあるんですか？

アホ・・・書いてないなら禁止だ
天才・・・書いてないならOKだ

ｿｰｽｺｰﾄﾞ ﾎｽﾃｨﾝｸﾞ総合【GitHub,GitLab,Bitbucket等】

ｿｰｽｺｰﾄﾞﾎｽﾃｨﾝｸﾞ総合【GitHub,GitLab,Bitbucket等】