clmemo@aka: github

ラベル github の投稿を表示しています。すべての投稿を表示

2017-02-11

Github で ignore space change 相当の diff を見る方法

過去に Github の Files Changed (diff) で -b (--ignore-space-change) フラグ相当の差分を見る方法を紹介した。

git diff -b と同じような出力をどうやって見るか。

方法は簡単。アドレスバーの URL 末尾に「?w=」というクエリー文字を追加してページを開く (Return キーを押すとページが開く)。これだけ

clmemo@aka: Github の「Files changed」(diff) で空白を無視するより引用

で、最近この方法を使おうとしたら使えなくなっていた。「?w=」だけではダメになっていて、必ず「?w=1」と指定しないといけなくなっていた。

URL のクエリーとしてはこっちの方が正しいので納得は出来る。Github 側が仕様を変えたのかな? それとも Chrome に変更があったのかな?

2015-08-11

Github の「Files changed」(diff) で空白を無視する

先日、git コマンドで diff をとった時に「空白の変更」を無視する方法を紹介した。

clmemo@aka: git diff で空白を無視する

今回は Github で同じことをやる方法。

Github で diff を見るのは、Pull-Request を作って master ブランチにマージする時じゃないかと思う。この時、「Files changed」タブを選択すると、ブランチ間の diff を見ることができる。

上のスクリーンショットでは、2 つの diff の hunk (固まり) が見える。このうち、最初の diff は行末の空白を消しただけの変更。メインの変更じゃない。こういった変更を見えなくするのはどうするか。git diff -b と同じような出力をどうやって見るか。

方法は簡単。アドレスバーの URL 末尾に「?w=」というクエリー文字を追加してページを開く (Return キーを押すとページが開く)。これだけ。

すると、次のように空白の変更を無視した diff が表示される!

Pull-Request のようにブランチ間の diff を見る時に、このオプションは便利。コード・レビューで Github の Pull-Request を使っているなら、この Tips を覚えておいて損はない。

ちなみに、クエリー文字は ?w=1 でも OK。

2015-07-31

Gist のコード貼り付けと noscript

プログラムのソースコードを貼り付けるのに Gist のコード埋め込みを使い始めた。メリットは 2 つ。

コードハイライトが行なわれる
行番号を表示できる

Blogger はコードハイライトをするのが一手間二手間かかる。その面倒臭さに、clmemo@aka でもコードハイライトは見送っていた。Gist を使うとその手間がなくなるのでありがたい。

Gist を使うデメリットもある。

Gist を一度経由する手間
Feedly などのフィードリーダーに Gist コードが表示されない
コードが検索の対象にならない

1. の手間については、何らか手段を構じたいところ。

2. と 3. のコードが表示されない・検索されない件については、<noscript> を使うと解決しそう。このタグは JavaScript が ON にならない環境 (フィードリーダーとか検索とか) でのみ、その中身を表示する。

まとめると、こんな感じのコードを書けば良さそう。

<script src="https://gist.github.com/ataka/aa8feb023c1dcc5183e3.js"></script>
<noscript>
<pre><code>func application(application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: NSData) {
   // (snip)
}</code></pre>
</noscript>

このやり方、少し続けてみよう。

2015-03-13

GitHub Flavored Markdown でリストの中に code block を入れるその二

過去記事の続き。リストの中に code block をハイライト付きで表示する方法について。

ref. clmemo@aka: GitHub Flavored Markdown でリストの中に code block を入れる

GFM の code block

前記事のおさらい。

non-fenced code blocks: コードの前に 4 つのスペースを置いてインデントする
fenced code blocks: コードを ``` で囲む方式。開始部分に言語名を指定すると、コードハイライトしてくれる

前記事では、リストの中でコード・ブロックを置くには

non-fenced code blocks しか使えない
インデントは 4 ではなく 8 を使う

と紹介した。fenced code blocks ではないので、コード・ハイライトは効かない。

リストの中でコードハイライト

non-fenced code blocks と fenced code blocks を組み合わせることで、リスト中でも (更に入れ子のリスト内でも) コード・ハイライトが出来る。

以下、ataka/emacs-wget の README.md で実際に使っているコードを写す。

1.  make && make install

    ```
    $ tar xzvf emacs-wget-X.YY.tar.gz
    $ cd emacs-wget-X.YY
    $ make
    # make install
    ```

  1. If make fails, put all *.el files into your load-path directory.
2. Put following expressions into your .emacs file.

    ```elisp
    (autoload 'wget "wget" "wget interface for Emacs." t)
    (autoload 'wget-web-page "wget" "wget interface to download whole web page." t)
    ```

3. Setting for Web browser on Emacs:
  1. With emacs-w3m, put the following code into your .emacs:

    ```elisp
    (load "w3m-wget")
    ```

  2. With Emacs/W3, put the following code into your .emacs:

    ```elisp
    (autoload 'w3-wget "w3-wget" "wget interface for Emacs/W3." t)
    ```

4. If wget version is 1.7 or less, put the following code into your .emacs:

    ```elisp
    (setq wget-basic-options '("-v"))
    ```

5. When you write your `.wgetrc`:
  1. `quiet = on`

     Emacs-wget will fail to download.  Put the following into your .emacs:

     ```elisp
     (setq wget-basic-options (cons "-equiet=off" wget-basic-options))
     ```

Brilliant!

あとがき

この書き方は @ClimbAppDev さんに教わった。README が読みやすくなった。ありがとうございます。

2015-02-05

Github で fork したリポジトリーをオリジナル・リポジトリーに同期させる

Github で milkypostman/melpa を fork して ataka/melpa を作った。

Pull Request を作って、本家にマージしてもらった。それから数か月経った。また Pull Request を作ろうと思った。ところが、ローカル・リポジトリーは最新じゃない。リモート・リポジトリーを pull しても意味がない。何故なら、リモート先はオリジナルのリポジトリーじゃなくて、ぼくが Fork したリポジトリーだから。Fork したリポジトリーをオリジナルに同期させなきゃいけない。

サイトを探したら、英語の説明があった。自分用メモとして訳しておく。

How to update GitHub forked repository? - Stack Overflow

$ git remote add upstream [email protected]:milkypostman/melpa.git
$ git fetch upstream
$ git checkout master
$ git rebase upstream/master
$ git push origin master

upstream リモートを作って fetch。master ブランチで upstream/master を rebase。最後に push で Github に反映させる。以上。

2015-02-03

GitHub Flavored Markdown でリストの中に code block を入れる

Github では Markdown (SM: Standard Markdown) を拡張した GFM (GitHub Flavored Markdown) が使われる。

リストの中でソースコードを書くのに手こずったので、メモしておく。

HTML で書くとこんなコードを書いて:

<ul>
  <li>This is test C code:
  <pre><code>int main(void) {
    printf("Hello World!\n");
    return 0;
}</code></pre></li>
  <li>secod item</li>
</ul>

次のような出力を得ることを期待している。

This is test C code:

int main(void) {
    printf("Hello World!\n");
    return 0;
}

secod item

GFM の code block

GFM には二種類の code block 書式がある。

一つはコードの前に 4 つのスペースを置く方式。GFM では non-fenced code blocks と呼んでいる。

    int main(void) {
        printf("Hello World!\n");
        return 0;
    }

もう一つはコードを ``` で囲む方式。GFM では fenced code blocks と呼んでいる。この方式はインデントしなくて済むのがメリット。

```
int main(void) {
    printf("Hello World!\n");
    return 0;
}
```

更に fenced code blocks では ```言語という書式を使って言語のコードハイライトができる。

```c
int main(void) {
    printf("Hello World!\n");
    return 0;
}
```

リストの中にコード・ブロック

GFM ではリストの中にコード・ブロックを入れるのに 2 つの制限がある

non-fenced code blocks しか使えない
インデントは 4 ではなく 8

よって、本ページ冒頭に示した HTML コードを GFM で書くなら、こうなる。

- This is test C Code:

        int main(void) {
            printf("Hello World!\n");
            return 0;
        }

- second item

リストの入れ子とコード・ブロック

応用編。リストの入れ子にコード・ブロックを入れる場合、non-fenced code blocks のインデントは 16 になる!!

- This is test C Code:

        int main(void) {
            printf("Hello World!\n");
            return 0;
        }

  - C Header is required

                #include <stdio.h>

- second item

あとがき

当然のことだけど、non-fenced code blocks はコード・ハイライトに対応していない。口惜しいけど仕方ない。

Github のマニュアルはサラリとしか、この事を説明していないので、読み逃してしまう。おかげで README.md を 17 回も書き直してしまった。次回、同じコードを書くことになったら、また困りそうなのでメモとして残しておく。

ref. GitHub Flavored Markdown - User Documentation

2014-12-19

Github に人間の証明を求められたら...

先月 (11/27 の夜中だったと思う)、Github にログインして驚いた。なんと Github に、ぼくが「人間ではない」とみなされてしまった!! その時のスクリーンショットはこちら。

One of our mostly harmless robots seems to think you are not a human.

Because of that, it's hidden your profile from the public. If you really are human, please contact support to have your profile reinstated. We promise we won't require DNA proof of your humanity.

(訳: 安宅による) 我々のロボットが、貴方を人間ではないとみなしています。

そのため、貴方の (Github の) プロフィールは非公開となりました。もし、貴方が人間であるなら、どうぞサポートへコンタクトを取ってください。貴方のプロフィールは元に戻るでしょう。DNA 判定を要求なぞしません。お約束します。

DNA proof を要求しない件は、Github 流のジョークかな。悪くないジョークだけど、真夜中に Guthub アカウントが (事実上) 停止してしまうのは、下手なジョークより心が凍る。

このメッセージが出たあと Google Chrome をシークレット・モードにして https://github.com/ataka/ を覗いてみたところ、404 Not Found が表示されてた。ぼくが公開してるプログラム全てが非公開になっていた。

ヤバイ!

人間の証明

「人間の証明」をするために、ぼくがやったことは一つ。メールを書いたこと。それもかなり拙い英文だった。

メッセージの中の「contact support」という文字がサポートへのリンクになっている。これをクリックすると、メール・フォームが開く。タイトルに「Hi, I'm human」と入れ、本文には「あなたのロボットが私を人間ではないというので、このメールを書いた。私は人間です。プロフィール・ページを元に戻してください。」という内容の英文を書いて送信した。

今思うと、かなりひどい文章 (日本語としてもね) だけど通じたらしい。2 日後、ぼくの Github ページは元に戻った (4/29 2:10 AM に元に戻したとのメールが届いてた)。

言い訳をさせてもらうと、その時、本当に眠くて文章を推敲することが出来なかった。ただ、Github に何かテキストを送らねば、と思っていた次第。翌日、改めて「Github のロボットがぼくのアカウントを停止してしまったけど、アカウント停止を解除して欲しい。私が人間であることを証明して欲しいということで、メールを昨日送った。具体的にどうすれば良いのか教えて欲しい。こちらにはすぐに対応する準備がある」旨、追加で英文を送った。でも、そのメールはスルーされたらしく、「Hi, I'm human」のメールに対して返信があった。

実際、「証明」とは人間らしいテキストをフォームから送信できれば十分らしい。あとは、担当者が Github ページを見て、ロボットが作成したものかどうかを「人間の目」で確認し、OK なら解除となる模様。

人間の証明など、どうすればいいのか? 英文でどう書けばいいのか? および腰になって、頭をひねる必要はない。十全を期そうとして時間を費やす必要もない。ただ、Github にアクションすること。これが Github への「人間の証明」になる。

同じように Github から人間の証明を求められて、困るようなことになったら、この記事を思い出してもらえれば幸い。