15/07/01 11:32:57.36 5x1pwjnr.net
>>126
なるほどにゃぁ
128:デフォルトの名無しさん
15/07/01 12:47:28.53 osw3K43k.net
>>126
それはコミット同士の依存関係であってコンパイル可能かどうかとは関係ない。
A>B>Cという歴史があってBで実装された関数をCで使っているのなら
コンパイル不能なコミットを許可したとしても問題は解決できない。
コンパイル可能なコミットにする事というのは
A
A>B
A>B>C
各歴史のHEADでコンパイルできる状態になっていますという事だよ。
129:デフォルトの名無しさん
15/07/01 13:50:55.44 E0yPgYN2.net
ごめん、何を言いたいかわからない。
各コミットをコンパイル可能にしておくのも、結構難しいって問題を出したつもりだけど、そっちが問題と考えてるのは何？
130:デフォルトの名無しさん
15/07/01 15:32:42.97 ok9JQHnv.net
コンパイルが通らないバージョンがコミットされてるなんて、気持ち悪くて嫌だ。
131:デフォルトの名無しさん
15/07/01 16:33:20.96 WrSpGcQO.net
気持ち悪いのは主観
作業用ブランチなら好きにしなはれ
132:デフォルトの名無しさん
15/07/01 18:11:07.44 ok9JQHnv.net
そっか、ビルド可能（あるいはテストパス）を区切りにしない人もいるんだ。
133:デフォルトの名無しさん
15/07/01 18:15:48.22 ok9JQHnv.net
というか、前回コンパイル可能から再びコンパイル可能までに書くコード量が違うのかな？
あるいは、ビルドにめっちゃ時間がかかるから、頻繁にビルドできないとかなのかな。
134:デフォルトの名無しさん
15/07/01 20:55:57.02 osw3K43k.net
>>129
コンパイル、実行可能にしておくのは当たり前で、そういうのは理由にならないって事
全てのコミットがコンパイル可能になっていなければgit bisectが使えない
実際gitのソースコードでもv2.4.5からHEAD~1500くらいまで
全部コンパイルしてもコンパイルエラーになることはない。
git bisectみたいにgitの機能として実装されているのだから
gitを使う人にとっては全てのコミットをコンパイル、実行可能にしておくのは
当たり前で、難しいことではないという認識なんだよ。
135:デフォルトの名無しさん
15/07/01 21:01:43.98 uCElgjag.net
developmentブランチ的な共有品に、ビルドすらコケるようなのを上げるのは
人の仕事を止めるから考えるまでもなく当然ダメだろう
136:デフォルトの名無しさん
15/07/01 22:49:22.90 E0yPgYN2.net
>>134
だから、何の理由にならないかって所を聞いてるんだけど？
共有ブランチ上のどのコミットに着目してもコンパイル可能であるべきで、それは分かりやすいコミット分割に優先するって話かな？
つまり、コンパイル不能な途中経過をコミットするぐらいならsquashした方がマシ、と。
137:デフォルトの名無しさん
15/07/01 23:06:27.57 E0yPgYN2.net
>>135
例えば、mater→A→B→Cというコミットのあるブランチをpull request受けた場合、マージする側はA,Bのそれぞれでコンパイル確認をしてからマージするべきだと思うかい？
それともCまでか？または、マージコミットに対してだけで良いと思うか？
自動実行テストがある場合はどうだ、それぞれで実施すべきか？
138:デフォルトの名無しさん
15/07/02 00:32:21.77 BOecX6fF.net
>>136
だから履歴を遡っての問題分析を難しくしてしまうのと
git bisectが使えなくなるのが問題。
コンパイル実行可能なのもコミットのわかり易さもどっちも必須条件
コンパイル出来ないけど分かりやすいって具体的にどんな例？
オープンソースのリポジトリにそんな例ある？
139:デフォルトの名無しさん
15/07/02 03:31:37.55 hbh5BBnI.net
SVNかなんかと勘違いしてないか
140:デフォルトの名無しさん
15/07/02 06:44:16.55 H40fLBlj.net
日時ビルドでコケましたってのが事故としてはありえても
それを理由に、開き直って機能しないってわかってるブランチpull requestしていいことにはならんだろ
発覚した時点で最優先でに修正することになるだろうし
141:デフォルトの名無しさん
15/07/02 18:30:32.56 eJl3FSc8.net
revertでもresetでもなんでもいいんだけど、変更を破棄したくなったときに、どのcommitが
コンパイル可能なものなのかわからんという状況は困らないのかな。
142:デフォルトの名無しさん
15/07/02 19:13:17.37 bMzAU0w9.net
commitにコンパイル禁止と書いて桶
143:デフォルトの名無しさん
15/07/02 20:35:15.89 E2OQ2sTs.net
>>138
オープンソースの例ではないが、業務上でありそうなものとしてはモジュール毎に担当者が決まっていて
1) 共通APIに機能を追加するために引数追加
2) それを使用している他のモジュールで引数追加に対応
で、1と2で担当者が違うから別々のコミットにしたい場合とか。
144:デフォルトの名無しさん
15/07/02 20:48:20.71 E2OQ2sTs.net
merge --no-ff必須にしておけば、mergeコミットは必ずコンパイルもテストも通る、って運用は可能だと思う。
pushする前にはコンパイル確認必須、とした場合も、masterブランチにコンパイル不可なコミットが混ざる可能性があるが、動作保証を自動テストで担保している場合はそれほど困らないんじゃないかな？
テストの方は全コミットで動作保証できることを期待してないだろうし、コンパイルに通らない事はテストに失敗したとみなせば同じ事だし。
145:デフォルトの名無しさん
15/07/02 21:08:43.42 BOecX6fF.net
>>143
ないな。新しいAPIを追加して前のものは残す。
新しいAPIに乗り換えるよう通達して、参照がなくなったところで削除する。
そんなガチガチの縦割り組織ならリポジトリも別にするべきだ。
>>144
そんな事してもcherry-pickで拾ったら不完全なものを取り込んでしまう。
過去バージョンのアップデートリリースが作りにくくなる。
146:デフォルトの名無しさん
15/07/02 21:57:29.71 E2OQ2sTs.net
>>145
>>>143
>ないな。新しいAPIを追加して前のものは残す。
>新しいAPIに乗り換えるよう通達して、参照がなくなったところで削除する。
各コミットのコンパイル可能を保証するために、その手順を踏むことが望ましいという主張だね。
俺だったら引数追加するたびにAPI名を変更するぐらいなら、squashでまとめるか、常にコンパイル可能を諦める方を選ぶな。
147:デフォルトの名無しさん
15/07/02 22:01:33.42 E2OQ2sTs.net
>>144
>そんな事してもcherry-pickで拾ったら不完全なものを取り込んでしまう。
cherry-pickが完全に取り込めるかは、そのときのHEADがコンパイル可能かどうかとは関係ないよね。
新APIを追加するコミット無しに、新APIを使うコミットは適用しても、コンパイル出来ないよ。
148:デフォルトの名無しさん
15/07/03 00:27:07.02 9/hHKZ1h.net
>>147
cherry-pickの結果コンパイルは出来なくても意味のない単位で分割するよりは
必要な修正がまとまっている分、不完全なものになる可能性はずっと低くなる
例えば、Aに前処理とBに本処理がコミットが分かれていて
Bのみを拾った場合、理解不能な挙動をを起こすことになる。
コンパイルエラーになるならまだ良いほうで、
偶然コンパイルが通った場合は余計なデバッグに時間を費やすことになる。
149:デフォルトの名無しさん
15/07/03 08:59:41.32 DfE7bDzR.net
いやだから、cherry-pickの結果、コンパイル通らなくても構わないのであれば、そのコミットが元々のブランチ上でHEADだったときにコンパイルが通ってなかったとしても、意味のある単位で分割されてれば阻害要因にならないよね。
>>143の例のようなモジュール単位でコミットを分ける、というのも意味のある分かりやすい単位だけど、複数のコミットの一部しか適用していない状態だと全体のコンパイルが通らないという弊害がある。
ガイドラインとして、それを許容するか否か、ということが論点のつもりだけど。
また、それを許容しない場合は、rebaseしたときに、手を入れた各コミットの段階ごとにコンパイル確認が必要になる。
全コミットでコンパイル保証をするというのは、その手間を払う価値があるか否か、というのも論点になる。
150:デフォルトの名無しさん
15/07/03 09:11:49.14 OZHQEleK.net
>>146
+1
151:デフォルトの名無しさん
15/07/03 09:33:38.89 AYyF2a3j.net
Gitではコミットって、見せる前にちぎってくっつけて書き換えるもんだから
粒度小さければ後はどうでもいいよな
SVN時代のコミットの話は、動かないブランチをメインにマージしていいか？のほうが近そう
152:デフォルトの名無しさん
15/07/03 10:45:33.74 DfE7bDzR.net
>>149
>そのコミットが元々のブランチ上でHEADだったときにコンパイルが通ってなかったとしても
誤解を招く表現な気がしたので訂正。
>そのコミットを指定してcheckoutしたときにコンパイルが通らないとしても
153:デフォルトの名無しさん
15/07/03 10:55:08.66 9/hHKZ1h.net
>>149
意味のある単位で分割されててもコンパイル出来なかったらbisectできないだろう。
これは阻害要因じゃないのか？
rebaseの各コミットをコンパイル確認したいのならその範囲をbisectすればいい。
そんなに手間だろうか？
154:デフォルトの名無しさん
15/07/03 11:57:45.03 bMlB0lVi.net
>>153
多分、bisectは使ったことないから実感ないんだと思うよ。
逆の視点で言えば、全てのcommitが意味ある単位でビルド可能で、望ましくはテストOKなら、
gitの恩恵の全てを受けることができると言える。
155:デフォルトの名無しさん
15/07/03 12:43:03.22 DfE7bDzR.net
>>153
>意味のある単位で分割されててもコンパイル出来なかったらbisectできないだろう。
>これは阻害要因じゃないのか？
確かにbisect使ったことないけど、コンパイル出来ないと何が困るの？
そのコミットをskipするなり、無視するスクリプトにするなり出来そうだけど。
git bisectのマニュアルにはその例が載ってるよね。
URLﾘﾝｸ(www8.atwiki.jp)
>rebaseの各コミットをコンパイル確認したいのならその範囲をbisectすればいい。
>そんなに手間だろうか？
ごめん、こっちは全然分からない。
bisectは二分探索だと思ってたけど、ある範囲のコミットを全チェックすることも出来るの？
そして実際にそうすることをガイドラインに組み込むべきだと思う？
156:デフォルトの名無しさん
15/07/03 13:15:10.09 bMlB0lVi.net
gitのpost-commit hookは使ってないのかな？
各コミットが、少なくともビルド可能であることを条件にしとくと、post-commit hookも
利用価値が出てくるのでは。
157:デフォルトの名無しさん
15/07/03 14:34:13.11 DfE7bDzR.net
>>154
post-commit hookで何をしたいのかな？
コンパイル確認じゃないよね？
158:デフォルトの名無しさん
15/07/03 15:13:32.77 Z21jSVmf.net
コンパイルできなかったものはスルーすれば良いだけだよね
どうみても
159:デフォルトの名無しさん
15/07/03 15:33:27.81 bMlB0lVi.net
>>157
> post-commit hookで何をしたいのかな？
それは、post commit hookなんか、誰にとっても不要だって言いたいのかな？
160:デフォルトの名無しさん
15/07/03 15:35:16.28 bMlB0lVi.net
>>158
> コンパイルできなかったものはスルーすれば良いだけだよね
> どうみても
意図しないエラーと、そうでないものを区別できないよね。
自動的に何かをするときは、意図しないものを検知したいときがほとんど。
クリーンビルドしても問題がないかとか、全テストを実行するとか、静的解析をするとか。
161:デフォルトの名無しさん
15/07/03 15:46:36.46 DfE7bDzR.net
>>159
いや、あるコミットがビルド可能なこととpost-commit hookに何の関係があると思っているのかを聞いてるんだけど？
まさか、post-commit hookでコンパイル確認させるつもりじゃないよね？
162:デフォルトの名無しさん
15/07/03 15:54:21.39 bMlB0lVi.net
>>161
> いや、あるコミットがビルド可能なこととpost-commit hookに何の関係があると思っているのかを聞いてるんだけど？
post-commit hookの前提が、
・ビルド可能かどうかもわからないもの
・ビルド可能なのが前提
・ビルド可能だし、テストもパスしているのが前提
それぞれで、できることが違うよね。
163:デフォルトの名無しさん
15/07/03 15:57:46.77 bMlB0lVi.net
それと、コミットが、
・ビルド可能なのが前提
・ビルド可能だし、テストもパスしているのが前提
にすると、pre-commit hookでやれることもでてくる。
164:デフォルトの名無しさん
15/07/03 16:21:58.51 9/hHKZ1h.net
>>155
スキップは例外的にコンパイルエラーが出てしまう場合にも
bisectを継続できるようにするための機能であって、常時使うような方法じゃないよ。
コンパイルエラーでスキップしたコミットがあると、当然中身はテストされないので
正確なエラー発生位置がわからなくなってしまう。
結局スキップされたコミットをエラーの範囲にあるかどうかを確認し、
コンパイルエラーを直しながら手動で確認する羽目になる。それはbisectの本筋じゃない。
bisectで各コミットをコンパイルするならmakeした上でコミットを全部スキップ
した事にすればいい。結果的に全部のコミットがコンパイルされる。
git bisect run sh -c ‘make; exit 125’
勢いで簡単にできるように書いてしまったが、本来の使い方じゃないね。
165:デフォルトの名無しさん
15/07/03 16:28:38.11 DfE7bDzR.net
>>162
だから、何をやらせようとしてるんだよ。
commit hookに相当重い作業をやらせる想定に思えて、役に立つイメージが全く湧いてこないんだけど。
そもそも、hook側にどんなコミットされるかの前提を持たしたらダメだろ。前提を満たすかどうかのチェックをさせるならまだ分かるけど、それにしたって0.1秒以内に終わる程度の処理しかさせたくないな。
166:デフォルトの名無しさん
15/07/03 16:44:04.07 bMlB0lVi.net
>>165
> だから、何をやらせようとしてるんだよ。
別に何をやってもいいと思うけど。
ローカルな開発環境で、マニュアルで実行していることや、各種タスクランナーにやらせてるようなことを、
commitをhookして自動実行させるのが目的。
> commit hookに相当重い作業をやらせる想定に思えて、役に立つイメージが全く湧いてこないんだけど。
ひょっとして、数分に一回くらいの頻度でコミットしてるのかな？
1日数回のcommitで、それぞれ数秒程度で終わるなら俺は気にならないけど。
> そもそも、hook側にどんなコミットされるかの前提を持たしたらダメだろ。
前提があるからやる意味がある。
「ビルド可能」なことが前提だとしたら、ビルドをやらせて本当にビルド可能なことをチェックするのも良い。
ローカルな開発環境ではビルドできたけど、リポジトリから取得してビルドするとビルドできないなんて
間抜けなことがなくなる（そして、これはたまに発生する）。
「テストをパスすること」が前提なら、テストを実行させるのも良い。
これも、ローカルな開発環境だとパスするが、そうでないとエラーになるとかありがち。
167:デフォルトの名無しさん
15/07/03 16:44:05.36 DfE7bDzR.net
>>164
>結局スキップされたコミットをエラーの範囲にあるかどうかを確認し、
>コンパイルエラーを直しながら手動で確認する羽目になる。それはbisectの本筋じゃない。
そこが、bisectの経験が無くて分からないんだけど、bisectの結果、最後にコンパイル出来てテストも通るコミットと、その次のコンパイル出来てテストに通らないコミット位置が分かるんじゃないの？
その間にあるコミットはコンパイルは出来ないかもしれないけど、分かりやすい単位で分割されているから、バグを特定しやすい気がするんだけど。
>bisectで各コミットをコンパイルするならmakeした上でコミットを全部スキップ
>した事にすればいい。結果的に全部のコミットがコンパイルされる。
なるほど、こちらはためになった。
全スキップさせれば、全探索になるのか。
168:デフォルトの名無しさん
15/07/03 16:51:48.49 DfE7bDzR.net
>>166
>> commit hookに相当重い作業をやらせる想定に思えて、役に立つイメージが全く湧いてこないんだけど。
>ひょっとして、数分に一回くらいの頻度でコミットしてるのかな？
作業中は数分間隔でコミットするね。
1日に均しても数回だろうけど。
>1日数回のcommitで、それぞれ数秒程度で終わるなら俺は気にならないけど。
1日数回なら、commit hookに任せずに、自分でコマンド叩くよ。
commitの度に自動ビルド、自動テストなんて、こっちの環境じゃとても耐えられない。
ガイドラインの前提には出来ないな。
169:デフォルトの名無しさん
15/07/06 10:16:17.26 XRnm36kK.net
hoge-commmit hookが自分にとって役に立たないものかどうかと、commitはビルド可能な
ものにしたほうがいいかどうかは別問題。
170:デフォルトの名無しさん
15/07/06 12:16:46.31 xERthjiE.net
>別問題
の後の続きを書かないと主張が分からん
171:デフォルトの名無しさん
15/07/06 13:19:51.86 XRnm36kK.net
普通に開発してると、ビルドOKかテストOKが作業の区切りになって、そのときコミットするから、
ビルド不可なものをコミットする人の気持ちもわからないし、デメリットもわからない。
ただ一つ言えるのは、俺はローカルリポジトリのcommit hookは使ってないが、それでも
ビルドが通らないものをコミットしようとは思わない。
普通に考えると、ローカルであれこれやりたいときに、どれがちょうど区切りがいいのかわからん
状態だと、作業に支障がありそうだと思う。
172:デフォルトの名無しさん
15/07/06 16:14:45.97 xERthjiE.net
commit hookと関係なくビルド不可なコミットを行うケースが想定できないって主張ね。
元々全てのコミットをビルド可能にするかどうかは、最終的に共有ブランチ上に残るコミットについての話だから、個々人が一時的にビルド不可なコミットを行おうがどうでも良かったんだよね。
ただし、commit hookにてビルド可能かどうかを確認することになると、個々人の作業ブランチが影響を受けるから、ガイドラインにするには適当じゃないと考えてる。
作業ブランチ上でビルド不可かも知れないコミットを作る例として、
・作業途中でブランチを切り替えたい場合のstash替わりにしてるケース
・ビルド出来ない環境で編集して、ビルド出来る環境へpushするケース
・ビルドに時間がかかりビルド出来るマシンが限られてるので占有させたくないケース
・家に帰るので、念のためコミットしておくケース
とかが、あった。
上にも書いたように、この状況は最終的にrebaseで解消されるから、
・分かりやすいコミット分割とコミット毎のコンパイル保障/試験動作保障が両立できない場合にどうするべきか？
という、当初の議題とは関係無いんだ。
173:デフォルトの名無しさん
15/07/06 16:58:12.27 XRnm36kK.net
>>172
俺の感覚だと、
> ・作業途中でブランチを切り替えたい場合のstash替わりにしてるケース
いや、stashしろよ
> ・ビルド出来ない環境で編集して、ビルド出来る環境へpushするケース
特殊ケースだね
> ・ビルドに時間がかかりビルド出来るマシンが限られてるので占有させたくないケース
差分ビルドできない言語は特殊ケース
> ・家に帰るので、念のためコミットしておくケース
意味がわからない
IDEがgitと統合されてるか、コマンドラインで開発するけど、ビルド・実行可というのが、俺の考える普通。
174:デフォルトの名無しさん
15/07/06 17:00:43.60 XRnm36kK.net
TDDは確信を得ながら開発を進めていく手法なんだけど、ローカルのcommitが全てビルド可能
（またはテストOK）にしながら開発を進めるのも、同じようなメンタリティな気がする。
俺がローカルであろうと「壊れたcommit」をしたくないのは、そういうことかもしれない。
175:デフォルトの名無しさん
15/07/06 17:16:13.76 xERthjiE.net
>>174
別にそのメンタリティを否定するわけじゃ無いけど、gitの運用ガイドラインに入れるわけにはいかんよね。
gitはビルドに時間が掛かる言語では使うな、ってわけにはいかんでしょ。
176:デフォルトの名無しさん
15/07/06 17:18:07.15 xERthjiE.net
>>174
ちなみに、TDDで通らないテストの時点ではまだコミットしない？
177:デフォルトの名無しさん
15/07/06 17:31:46.58 XRnm36kK.net
>>176
> ちなみに、TDDで通らないテストの時点ではまだコミットしない？
俺がやってるのはTDD的なものなんだけど、コードと前後してテストを書く場合は、テストが通らないと
commitはしないよ。
というか、テストが通らないコードのcommitに、なんの意味があるのかわからない・・・。
178:デフォルトの名無しさん
15/07/06 18:26:20.10 xERthjiE.net
いや、まだ実装してないから、通らないテストコードだけのコミットをしないのかな、と。
つまり、コミットするときは、すべてのテストが通ってからなのかな？
俺とはコミット頻度がだいぶちがうね。
179:デフォルトの名無しさん
15/07/06 21:31:12.57 mHUPaf2c.net
>>177
便乗して俺も訊きたいんだが、そのコミット前のテストというのは、
単体テストのレベルのこと？
つまり、関数一つ作って、その関数の単体テストだけをして、
テストに通ってからコミットという話？
（当然、テストを作るのは関数を作る前だが）
それとも、今実装している機能に関係した部分の自動機能テストも通ってからコミットするの？
前者なら分かる、俺も同じだから。
180:デフォルトの名無しさん
15/07/07 01:02:07.10 7aEyySce.net
公開するものはmake test相当のものをするだろう
URLﾘﾝｸ(docs.docker.com)
URLﾘﾝｸ(nodejs.org)
フルテストとリベース、dockerの方はコミットをまとめろとまで書いてある
181:デフォルトの名無しさん
15/07/07 04:28:18.56 FHtVzgus.net
>>178
+1
182:デフォルトの名無しさん
15/07/07 10:11:12.92 K0epweTJ.net
>>178
> いや、まだ実装してないから、通らないテストコードだけのコミットをしないのかな、と。
テストもその後リファクタリングするかもしれないから、テストだけ書いてcommitするというのはしない。
・テストを書く（コードが先の場合もある）
・コードをテストがパスするまで実装
・テストに改良点があれば改良する
・commit
という流れ。
百歩譲ってテストコードをcommitするとしても、TDDで言うRed->Greenの状態でcommitすると思う。
Redの状態でcommitする意義がわからない。
>> 179
> 便乗して俺も訊きたいんだが、そのコミット前のテストというのは、
> 単体テストのレベルのこと？
単体テストレベルというのがTDDのためのUnitTestという意味なら、それ以上のテスト（品質保証の
ためのテスト）もだいたい同時期に書くよ（網羅はしないけど）。
183:デフォルトの名無しさん
15/07/07 12:43:10.48 bvFHzGSt.net
>>182
>Redの状態でcommitする意義がわからない
commitをまとめるのは容易いけど、分割するのは大変だから、ちょこちょこcommitするようにしてる。
切りが良い時に、rebaseで整理する。
だから、コミットするタイミングでいちいち意義なんか求めないなぁ。
184:デフォルトの名無しさん
15/07/07 13:12:55.04 K0epweTJ.net
>>183
それ、逆に言うと、「テスト＋プロダクトコード」のひとかたまりのcommitを分割したいことがあるということ？
185:デフォルトの名無しさん
15/07/07 13:20:27.64 K0epweTJ.net
例えば、URLﾘﾝｸ(blog.developwithpassion.com) の最初のコードで、
これは二つのケースが入ってるから最初に書くテストコードが
[TestFixture]
public class MoneyTest
{
[Test]
public void ShouldBeAbleToCreateMoney()
{
Money money = new Money(20.00);
Assert.AreEqual(20.00,money.Amount);
Assert.AreEqual(2000,money.Cents);
}
}
だったとする。
もちろん、これだとビルドできないけど、これをcommitしたくなるってこと？
186:デフォルトの名無しさん
15/07/07 15:16:24.29 bvFHzGSt.net
>>184
いまいち伝わってない気がするけど、コミットをどの粒度で整理するかを後から(公開するまでに)考えるようにしたいから、細かくコミットするってこと。
>>185
うん。面倒でサボるときもあるだろうけど、この段階でコミットしてはいけない、ってルールは許容出来ない。
作業ブランチのコミット履歴は作業履歴も兼ねさせてるから。
187:デフォルトの名無しさん
15/07/07 15:28:22.05 lQxKZL5c.net
正直いろいろ考えずに、トピックブランチをちゃんと細分化して
コミットはマージの時に--squashで叩き込めばそれでいい気がしてきた。
188:デフォルトの名無しさん
15/07/07 15:35:27.18 K0epweTJ.net
>>186
> いまいち伝わってない気がするけど、コミットをどの粒度で整理するかを後から(公開するまでに)考えるようにしたいから、細かくコミットするってこと。
俺の疑問もいまいち伝わってない気がする。
細かくcommitするのが疑問なんじゃなくて、TDDでいるRed状態でcommitしたいのが何故なのかということ。
> うん。面倒でサボるときもあるだろうけど、この段階でコミットしてはいけない、ってルールは許容出来ない。
いけないとは言ってないよ。
なんでせめてRed -> Greenにまでもっていってからcommitしないんだろうかというのがわからない。
どっちにしろ、あとでrebaseするのは確定なんだし。
189:デフォルトの名無しさん
15/07/07 15:55:20.52 K0epweTJ.net
知らない人がいると思うのでTDDの説明をしておくと、Red -> Greenというのは
実装完了じゃなくて、テストがパスするためだけの仮実装完了状態。
>>185の例だと、
public class Money
{
public int Cents;
public double Amount
public Money(double amount)
{
Amount = 20.0;
Cents = 2000;
}
}
でGreen。
190:デフォルトの名無しさん
15/07/07 17:10:54.61 bvFHzGSt.net
>>188
>なんでせめてRed -> Greenにまでもっていってからcommitしないんだろうかというのがわからない。
Redになる試験を定義出来たってことは切りがいいでしょ。この例だとクラス名を決定したわけだ。
そもそもcommitするのを待った方がいい理由が分からない。
特にgit初心者に対してはbranchやcommitの概念に慣れさせる意味も込めて、頻繁なcommitとrebaseでも整理をさせた方が良いと思う。
191:デフォルトの名無しさん
15/07/07 18:10:53.70 K0epweTJ.net
>>190
> Redになる試験を定義出来たってことは切りがいいでしょ。この例だとクラス名を決定したわけだ。
なんか繰り返しになるのでこのレスでこの流れを終わるけど、本当に定義できたかどうかは、
ビルドして実行するまでわからない。typoとかあるかもしれないし。
だから、俺的には、区切りがいいとは思えない。
> そもそもcommitするのを待った方がいい理由が分からない。
これもうざいだろうけど、ビルドできるかどうかもわからないコードをcommitするのに意味を見いだせないから。
まぁ、いつまで会話してもお互い理解できない感じなので、俺からはこのスレで終わるね。
192:デフォルトの名無しさん
15/07/07 22:07:51.77 bvFHzGSt.net
>>191
>> そもそもcommitするのを待った方がいい理由が分からない。
>これもうざいだろうけど、ビルドできるかどうかもわからないコードをcommitするのに意味を見いだせないから。
commitするのに意味が必要かどうか、って所が相違点な気がするから平行線だろうね。
>まぁ、いつまで会話してもお互い理解できない感じなので、俺からはこのスレで終わるね。
commitしちゃいけない、って意見では無くて、commitする意味が分からないって意見のようなんで、ガイドライン的には関係無さそうなんで、これで終わりでいいだろうね。
とにかく、元々の話はcommit hookで強制するかどうかの話なんだから、強制する気が無いなら、好きにすれば良いで終わる話だしね。
193:デフォルトの名無しさん
15/07/08 14:37:57.96 5jcTfYer.net
読んでて思ったんだが、TDDやってない人は>>185のコードで一区切り付くと思うだろうけど、TDDやってると、
185のコードを書き始めてから数分以内に、テストコード編集・コンパイル・テスト実行・コード編集を頻繁に
繰り返すから、>>185じゃ全然区切りじゃないんだ。
まあ、ローカルcommitの粒度は、個々人がひとまとまりだと思う単位でってことにつきると思う。
開発スタイルやスキルによって、なにがひとかたまりなのかは人それぞれだってことで。
194:デフォルトの名無しさん
15/07/08 21:27:06.35 9BfiFT/T.net
TDDって、仕様決めてテスト書く人とそれを実装する人が同じって前提あったっけ？
195:デフォルトの名無しさん
15/07/08 21:31:23.47 Y+kE74C9.net
人それぞれだってことで。
196:デフォルトの名無しさん
15/07/08 22:49:53.35 uBhtmoLk.net
作ってすぐ実行する前提だからペアプロでも人が変わる余地はあまりないな
197:デフォルトの名無しさん
15/07/09 10:37:39.93 SLWTmnwe.net
>>194
> TDDって、仕様決めてテスト書く人とそれを実装する人が同じって前提あったっけ？
TDDのテストコードは、プロダクトコードを書くための手段だから、同じ人がやるのが普通。
というか、違う人が書くなんて話を聞いたことがない。
198:デフォルトの名無しさん
15/07/09 12:43:45.27 Vp2Vvxuo.net
他人が書かないとかこの機能はどういう入出力あるかわかりましぇーんって言ってることと同意だぞ。
199:デフォルトの名無しさん
15/07/09 15:11:30.39 w4uEPqNZ.net
これも同じ人がテスト作っちゃってるし
URLﾘﾝｸ(github.com)
文句言ってきたほうがいいと思うよ
200:デフォルトの名無しさん
15/07/09 18:20:13.62 IBLBW75h.net
>>199
なんでそんな事が分かる？
ローカルではテスト担当の幼女がやってるかもよ。
201:デフォルトの名無しさん
15/07/09 19:26:07.25 w4uEPqNZ.net
>>200
Signed-off-by: Karsten Blees <blees@dcon.de>
これはこのコードを寄贈しますという意味。
複数の人が関わっている場合はContributions-byで追記したりする。
最後のはJunioさんがgit am -sした時のもの。
202:デフォルトの名無しさん
15/07/09 19:57:50.51 ymwHunw+.net
プログラムコードが文章で書いてるタイプの糞仕様書を作るくらいなら
Spec作ってくれてるほうが意味はありそうだな
203:デフォルトの名無しさん
15/07/09 20:59:25.15 IBLBW75h.net
>>201
幼女は名前を出したく無いのかもしれないし
204:デフォルトの名無しさん
15/07/09 23:10:56.06 w4uEPqNZ.net
このスレもうだめだな
205:デフォルトの名無しさん
15/07/10 00:05:50.44 J6ZPTH7V.net
さすがにOSSで「俺テスト書いたから誰か実装して」ってのはないだろう。
206:デフォルトの名無しさん
15/07/10 11:38:16.56 eTiXJwcJ.net
普通のプロダクトでもないから
207:デフォルトの名無しさん
15/07/10 12:14:06.28 0KQmgFVg.net
TDDでなければ良くあること
208:デフォルトの名無しさん
15/07/10 12:37:40.36 eTiXJwcJ.net
>>207
君の周りでは良くあることかもしれないが、普通はそうないよ
大抵は、開発者自身による開発者テストと、開発者自身による後付けのテスト
ところによっては、第三者による後付けのテスト
これくらい
209:デフォルトの名無しさん
15/07/10 12:58:03.35 rsWVLm23.net
君の周りではそうないことかもしれないが、普通は良くあること。
210:デフォルトの名無しさん
15/07/10 12:59:10.97 eTiXJwcJ.net
>>209
そういう手法でも、そうやってるというブログでもいいけど、いくつか引っ張ってみせろ
211:デフォルトの名無しさん
15/07/10 14:19:58.30 0KQmgFVg.net
>>210
そうは言っても、別に興味はないんでしょう？
誰かの周りで良くあることかもしれない、と認められるんなら、優劣を比べてるわけでもないんだから、それで十分でしょう。
gitはそういう使い方も許容するんだからさ。
212:デフォルトの名無しさん
15/07/10 14:38:11.38 eTiXJwcJ.net
>>211
> 誰かの周りで良くあることかもしれない、と認められるんなら、優劣を比べてるわけでもないんだから、それで十分でしょう。
俺の周り：その他多数
じゃなくて、
君の周り：その他多数
だって認めてくれればそれでいいよ
> gitはそういう使い方も許容するんだからさ。
ほう、じゃA氏がテストを書いてB氏がそれを実装するとき、どうやってgitを運用してるか書いてみな
213:デフォルトの名無しさん
15/07/10 17:43:45.37 0KQmgFVg.net
>>212
>君の周り：その他多数
>だって認めてくれればそれでいいよ
認めるよ。
>> gitはそういう使い方も許容するんだからさ。
>ほう、じゃA氏がテストを書いてB氏がそれを実装するとき、どうやってgitを運用してるか書いてみな
* B氏が実装を書いてブランチとして公開する
* ソースコードレビューする
* B氏が修正する
* A氏がテストを書き、テストを実施する
* B氏の修正を随時取り込む
運用ってほどじゃないな。
むしろ、なんでGITが特定の開発方法しか許容しないと思うのか？
214:デフォルトの名無しさん
15/07/10 17:54:37.91 eTiXJwcJ.net
>>213
それ、第三者による後付けのテストじゃん
それはよくある
俺が、それはないって言ってるのは>>205
> 俺テスト書いたから誰か実装して
上の方でも、TDDで第三者がテスト書く的なこと言ってる奴もいたし
215:デフォルトの名無しさん
15/07/10 18:39:16.09 0KQmgFVg.net
第三者？登場人物は二人しか出てないけど。
まあ、TDDでなければよくある、って書いてあるんだけど、それは見落としてたわけね。
216:デフォルトの名無しさん
15/07/10 18:41:21.19 eTiXJwcJ.net
>>215
自分以外の誰かは第三者じゃないんですか？
とかいうのはどうでもいいんだけど、
君が書いたのは「俺がコード書いたから誰かテスト書いて」ってことでしょ
俺がないって言ってるのは「俺がテスト書いたから誰かコード書いて」だ
違いわかんないの？
217:デフォルトの名無しさん
15/07/10 18:55:25.64 /TIw0VBH.net
>俺がテスト書いたから誰かコード書いて
あるよ
218:デフォルトの名無しさん
15/07/10 19:35:38.61 i0TWAaKD.net
コンパイルエラーくんのあたりから変な奴が増えたな、実際は一人かもしれないけど
事例を引用してこないのは無視した方がいいと思うぞ
219:デフォルトの名無しさん
15/07/10 19:50:33.80 n6HS4jkV.net
>>213
俺がテスト書くから君が実装してね
じゃダメかね？
220:デフォルトの名無しさん
15/07/13 10:31:31.19 sRi+Sfog.net
>>219
> 俺がテスト書くから君が実装してね
> じゃダメかね？
実装する俺がテスト書くのが効率的、というのが普通。
それ以外には、テストを書くのもままならない初心者が実装する場合か、自動受け入れテストを
事前に書く場合くらいしか思いつかない。
221:デフォルトの名無しさん
15/12/24 00:53:04.29 VDgCwlJn.net
>>220
ちょっと横道だが…
実装した人間がテストを書くのが効率的なのは間違いないと思うけど、勘違いによる確率を下げるためには、実装した人間とは別の人間によるテストも有効だぞ
222:デフォルトの名無しさん
15/12/24 10:27:35.59 +bsSlAyH.net
>>221
この話は>>194から始まる「TDDでも他人がテスト書くこともある」という話で、そうする人が
いるかもしれないが、普通はプロダクトコードを書いた人がTDDのテストを書く方が効率が
いいという話。
223:デフォルトの名無しさん
16/01/09 17:39:45.67 QRpimApV.net
sourcetreeでgitを使っているんだけど、pullしようとすると
if you trust this host, enter "y" to add the key to PuTTY's cache
というメッセージが出て止まってしまう
ここでyが押せればいいんだけど、SourceTreeはyを押してくれないので
どうしたらよいでしょうか！
224:デフォルトの名無しさん
16/01/11 17:00:06.48 I0GTrlSH.net
SSH の RSA Host key を自分で桶
225:デフォルトの名無しさん
16/01/25 20:57:49.79 WOTwLsqM.net
結局、GitってPull Requestをうまいこと実現するためのツールなんかな
226:デフォルトの名無しさん
16/01/26 10:29:52.37 mkuLwhRZ.net
GitとGithubを混同してないか？
227:デフォルトの名無しさん
16/01/26 19:15:50.35 14BXXOjm.net
>>226
コードについてのレビューは一切やらず、マージも各自が勝手にやるって前提でGit動かしてたんだけどさ
Pull Request的な承認フローを組み込まないなら、トピックブランチ切ったり、コミットを履歴いじって細かくまとめても、しんどいわりに対価がなんもないなあって
masterなりdeveloptなりに、チケット番号書いたコミットを直に叩き込んでいったほうが、変に分離されてないから横断的な変更もやりやすいし
228:デフォルトの名無しさん
16/05/01 14:36:36.34 tKi6j9CT.net
匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrentがオープンソースで開発されています
言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？
Covenantの作者（Lyrise）がそういう人と話したいそうなので、よろしければツイートお願いします
URLﾘﾝｸ(twitter.com)
ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーｗ
The Covenant Project
概要
Covenantは、純粋P2Pのファイル共有ソフトです
目的
インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します
特徴
Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)
接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
お
229:デフォルトの名無しさん
16/09/25 13:42:44.81 0J+83ZC2.net
ge
230:デフォルトの名無しさん
17/10/24 12:11:19.77 QsylRaIJ.net
SourceTreeで、実行属性やパーミッションを確認する方法を教えてください
231:デフォルトの名無しさん
17/10/24 17:59:49.42 c4pQ4iLG.net
右クリック
232:デフォルトの名無しさん
17/11/10 11:08:50.86 Au/LCYKx.net
プログラムの文字コードはEUC-JP
でもコミットログはUTF8で書きたい
というとき、どういう設定をすれば一番トラブルが少ない？
233:デフォルトの名無しさん
17/11/11 14:26:49.51 ZUnF3Lay.net
なにもしない
234:デフォルトの名無しさん
17/12/30 22:51:30.14 DzO+KqCk.net
コンフリクトっていつ起きるんですか？
・自分の作業ディレクトリに最新コミットをpullしてくる
・自分が作業して作業ディレクトリの内容が変わる
・誰かがリモートへその人のコミットをpushする。
・自分がコミットしたいので先にpullする
→誰かが進めたコミットがローカルブランチに反映される。
(このときにコンフリクト?)
・自分がpullしたのでaddする
(このときにコンフリクト?)
・自分がaddしたのでコミットする
(このときにコンフリクト?)
・自分がコミットしたのでプッシュする。
(このときにコンフリクト?)
・自分がプッシュ後念のため再度pullする
235:デフォルトの名無しさん
18/02/16 06:39:41.43 W1XJdyx1.net
☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆
236:デフォルトの名無しさん
18/05/23 20:54:44.80 Au5e7VGg.net
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
0DSS1
237:デフォルトの名無しさん
18/07/05 00:59:07.23 RfoszcD2.net
NNA
238:デフォルトの名無しさん
20/01/09 20:23:33.80 1uKbRjup.net
macbookのターミナルでgitにコマンド入力してるんだけど
これってセーブとかしなくて良いの？
良いとしたらどうしてですか？
239:238
20/01/09 21:10:43.63 1uKbRjup.net
日本語が変だからやり直し
macbookのターミナルにgitのコマンドを入力してますが、これってセーブとかしなくて大丈夫ですか？
大丈夫な場合はどうしてですか？
教えてください偉い人！
240:デフォルトの名無しさん
20/01/10 14:02:14.42 t5T0L8NN.net
>>239
何をセーブする話です？
(エディタなどの)アプリケーションでのメモリー内での変更を、ファイルに保存するセーブなら、必要です。
アプリケーション内からgitコマンドを操作できるものは、gitコマンドを実行する前に自動でセーブされるはずです。
変更したファイルをリポジトリにセーブしなくていいのか？という意味ならcommitがセーブに相当します。
241:デフォルトの名無しさん
20/12/29 01:12:42.70 qxevuYQ38
大学で学ぶ物理を板書１枚にまとめてみた
URLﾘﾝｸ(www.youtube.com)
物理の研究分野を板書１枚にまとめてみた
URLﾘﾝｸ(www.youtube.com)
理学部と工学部の違いとは？
URLﾘﾝｸ(www.youtube.com)
大学と大学院の違い
URLﾘﾝｸ(www.youtube.com)
高校と大学の積分は決定的に違う？微分積分学の基本定理は実はすごい！
URLﾘﾝｸ(www.youtube.com)
数学にはどんな研究分野がある？数学の世界地図を一枚に描いて紹介してみた！
URLﾘﾝｸ(www.youtube.com)
242:デフォルトの名無しさん
21/03/31 18:08:33.14 YXPC705mg
2年間で23億円を調達。22歳の社長が語る“スタートアップ起業”
URLﾘﾝｸ(superceo.jp)
誰もがオリジナルアプリを作れる時代へ。スタートアップ支援に尽力してきた起業家の原動力とは
URLﾘﾝｸ(fukuoka.startupnews.jp)
アプリの視聴率がわかる 高専卒起業家の独創力
URLﾘﾝｸ(www.nikkei.com)
１万人の若者を支援！インターンが日本を変えるかも！？ glowshipの若き創業者・足立卓也氏インタビュー
URLﾘﾝｸ(sogyotecho.jp)
起業で成功するキャリア形成の仕方とは？ 元プロサッカー選手で起業家の鈴木啓祐氏に聞いた
URLﾘﾝｸ(sogyotecho.jp)
年収3,000万超え!?個人開発で儲かっている海外コミュニティサイト5選！
URLﾘﾝｸ(note.com)
自分の視野は「世の中の0.001%」と自覚せよ。ビジネスチャンスを掴む4つの習慣
URLﾘﾝｸ(headlines.yahoo.co.jp)
人はこうすれば“ハマる”、源流はゲーマー視点の「幸せ」
URLﾘﾝｸ(project.nikkeibp.co.jp)
243:デフォルトの名無しさん
21/07/22 14:28:47.71 9Ov2SxzN.net
gitを良くするためにはMicrosoftの関与をシャットアウトしないとダメ
244:デフォルトの名無しさん
22/03/18 19:33:41.03 smNc+iFX.net
du -sh .git
どうして?
245:デフォルトの名無しさん
22/12/25 16:05:51.51 5e2c53xzU
しっかし世界最惡の腐敗利権組織自民党の覇権主義岸田文雄はよくもここまて゛白々しい寝言ほさ゛き続けられるよな
ウクライナか゛攻撃されたのは軍事費ＧＤΡ比４％超でΝΑｔＯにまて゛加盟しようとして脅威視されたのが原因だろ
北朝鮮の軍拡は曰本に原爆落とした世界最悪のならず者國家らか゛かつてない頻度て゛軍事演習た゛なんた゛と挑發してるのか゛原因だし
クソシナの台湾ヘの執着は元々同し゛国で自国民か゛大勢居住してるからだろ
ウクラヰナも口シア民か゛大勢居住してるわけで．こうした事情を無視して日本が侵略されるから軍拡するぞだの飛躍にも程があるわ
クソシナや口シアを非難する奴は．沖縄が独立宣言しても住民の意思だと賛成して自閉隊を送り込むとか当然反対するんだよな？
クソシナか゛どこぞの離れ小島て゛どうたらこうたらてめえらの生活に何の関係もねえだろ
そんな離れ小島のために年間云兆圓もの税金を投入する価値があるとて゛も思ってるなら、思ってるやつから年云兆円徴収してやっとけ力ス
創価学會員は、何百万人も殺傷して損害を与えて私腹を肥やし続けて逮捕者まて゛出てる世界最惡の殺人腐敗組織公明党を
池田センセ─か゛囗をきけて容認するとか本氣て゛思ってるとしたら侮辱にもほどか゛あるぞ！
ｈＴтρｓ：／／ｉ，ｉｍｇｕｒ，сｏｍ／hnli1ga.jpeg
246:デフォルトの名無しさん
23/07/15 18:23:09.55 bGpTfifD.net
.git-version が細かいトラブルの原因
うざい
247:デフォルトの名無しさん
23/11/06 17:57:30.14 j+54AM7Bx
第ニのエ儿ピーダ確定の価格下落しまくり半導体の次はAIに税金2000億とか天下り税金泥棒無能公務員には反吐が出るな
世界最惡の脱炭素拒否テ囗国家に送られる化石賞連続受賞して世界中から非難されなか゛ら憲法13条2５条29条と公然と無視して力による━方的な
現状変更によってクソ航空機倍増、閑静な住宅地から都心まで数珠つなぎで鉄道の３0倍以上もの莫大な温室効果ガスまき散らして騒音まみれ
静音か゛生命線の知的産業壊滅させて天下り賄賂癒着してるナマポ集団NTтだの不治痛だのと税金泥棒のネ夕にしてるだけなのがバレハ゛レ
ポンコツ技術後進国を脱却する気などサラサラないのはクソ航空機の陸域飛行禁止しないことからも明らかだろ
都心から離れすぎない地に飛行禁止区域を作るた゛けでも2000億以上の技術発展を確保できるだろうがクソ無能公務員の手作業による税金泥棒
ネタ維持のために気候まで変動させて土砂崩れ、洪水、暴風、熱中症にとマッチポンプ丸出しで住民殺して私腹を肥やす気満々だわな
某АIは高速テ゛ータ処理が飛躍的なだけで知能としてのブレヰクスル‐には至っていないがそれでもポンコツ腐敗後進国曰本には無縁の技術だわ
(羽田］URLﾘﾝｸ(www.)<)ｅbaownd.Ｃom/
(テロ組織〕Ttрs://i.imgur.com/hnli1ga.jρeg
248:デフォルトの名無しさん
24/03/14 08:10:01.82 wUPYjZa5w
女性カ゛─た゛のLGBTガ－だの障害者ガ一だの気持ち悪いか゛海に囲まれた曰本で高い所と騒音か゛大好きなハ゛カか゛日本中クソ航空機飛は゛しまくって
騷音に温室効果ガスにコ□ナにとまき散らして氣候変動させて海水温上昇させてかつてない量の水蒸氣を曰本列島に供給させて
日本中て゛土砂崩れに洪水、暴風、熱中症、森林火災，大雪にと災害連発させて住民の生命と財産を破壞しまくって静音が生命線の知的産業に
威カ業務妨害して他人の権利を強奪して私腹を肥やす強盜殺人を繰り返して石油需給逼迫させてヱネ価格に物価にと暴騰させて
經済も私権も人権もないテ゛シ゛夕ル後進國のポンコツ腐敗国家に陥れてる皆殺しにされるへ゛きJALだのANAだのクソアイヌト゛ゥだの
クサヰマ‐クた゛のゴキブリフラヰヤ一だのシ゛ェットクサ一た゛のJTBだのテ口リス├と天下り賄賂癒着してる世界最惡の強盜殺人組織公明党
國土破壊省による史上最悪のシ゛ェ丿サヰドをスル－しなか゛らその正義もクソもない自己中心的なタ゛ブスタっぷりに寝言は寝て言えって話た゛よな
(ref.) URLﾘﾝｸ(www.call4.jp)
URLﾘﾝｸ(haneda-project.jimdofree.com) , URLﾘﾝｸ(flight-route.com)
URLﾘﾝｸ(n-souonhigaisosyoudan.amebaownd.com)
249:デフォルトの名無しさん
24/12/03 22:21:01.57 T09kgZvsc
お前らから強奪した血税30億以上→アジア開發銀行氣候変動対策費→世界最惡の殺人組織公明党強盜殺人の首魁斉藤鉄夫ら國土破壞省と癒着
して力による－方的な現状変更によって都心まで数珠つなき゛て゛クソ航空機飛ばして莫大な温室効果ガスまき散らして気侯変動させて土砂崩れに
洪水．暴風，熱中症にと災害連發させて大勢殺害して住民の私権侵害して知的産業に威カ業務妨害して私腹を肥やす史上最惡の強盜殺人テ□を
繰り返す前代未聞の地球破壊テ□リス├クソ航空関係者ウハウ八→民主主義とはカによって勝ち取るものだという世界の常識すら知らない
お前らひたすら奪われ無駄に燃やされた石油で物価まで暴騰，コロナまき散らされて死亡，白々しくマッチポンプテロリス├か゛運んだ
ウイ儿スと称する毒物打って死亡．後遺症でも苦しみまくっていながらいまだに立ち上がらないとか北朝鮮人民までドン引きだそ゛
私利私欲のためだけに存在している税金泥棒クソ公務員は撲滅すへ゛き國民の敵だという正しい理解と行動をしよう!
(ref.) URLﾘﾝｸ(www.call4.jp)
URLﾘﾝｸ(haneda-project.jimdofree.com) , URLﾘﾝｸ(flight-route.com)
URLﾘﾝｸ(n-souonhigaisosyoudan.amebaownd.com)