Gitのコミットemailを書き換える

Git

環境をいくつも使っていると設定を間違ってコミットしてしまうことがありますよね。
特に1台のPCに仕事とプライベートのリポジトリが混在してるとメール設定が間違っていたり・・・
こういうのは大抵だいぶ後に見つけてしまうのですが、Gitは過去のコミットログを修正できます。
まあ push -f するのは危険なので最初から気をつけるに越したことはないですけどね。

ここを参考にやってみました。

qiita.com

確認方法

1個目は正常。2個目間違ってる。。。

$ git log --pretty=fuller
commit xxxxxxxxxxd61e214a190a042f3416c5d85f4046 (HEAD -> master, origin/master, origin/HEAD)
Author:     GOZU Kenichiro <gozuk16@gmail.com>
AuthorDate: Sat Oct 31 13:13:20 2020 +0900
Commit:     GOZU Kenichiro <gozuk16@gmail.com>
CommitDate: Sat Oct 31 13:13:20 2020 +0900
 
commit xxxxxxxxxxd66b9169746acada7f8355e59d6d1c
Author:     GOZU Kenichiro <k.gozu@example.com>
AuthorDate: Fri Oct 30 13:13:21 2020 +0900
Commit:     GOZU Kenichiro <k.gozu@example.com>
CommitDate: Fri Oct 30 13:13:21 2020 +0900

emailを書き換え

指定するメールアドレスは変更後のものです。
履歴全部を書き換える場合、最後に HEAD を指定します。
ユーザ名も GIT_AUTHOR_NAME と GIT_COMMITTER_NAME で書き換えできますが、今回はメールアドレスだけ間違ってました。

$ git filter-branch -f --env-filter "GIT_AUTHOR_EMAIL='gozuk16@gmail.com'; GIT_COMMITTER_EMAIL='gozuk16@gmail.com';" HEAD
Proceeding with filter-branch...

Rewrite xxxxxxxxxxd61e214a190a042f3416c5d85f4046 (20/20) (0 seconds passed, remaining 0 predicted)
Ref 'refs/heads/master' was rewritten

書き換えを確認

$ git log --pretty=fuller
commit xxxxxxxxxxd1218c7b6d2a96c57e0ca6f8776547 (HEAD -> master)
Author:     GOZU Kenichiro <gozuk16@gmail.com>
AuthorDate: Sat Oct 31 13:13:20 2020 +0900
Commit:     GOZU Kenichiro <gozuk16@gmail.com>
CommitDate: Sat Oct 31 13:13:20 2020 +0900
 
commit xxxxxxxxxx72d5d3b83a8df9c645508e3531787d
Author:     GOZU Kenichiro <gozuk16@gmail.com>
AuthorDate: Fri Oct 30 13:13:21 2020 +0900
Commit:     GOZU Kenichiro <gozuk16@gmail.com>
CommitDate: Fri Oct 30 13:13:21 2020 +0900

リモートリポジトリへpush

過去を改変した場合、 -f じゃないとpush出来ないのでチームで使ってるリポジトリはメンバーに確認してやりましょう。

$ git push -f
Enumerating objects: 83, done.
Counting objects: 100% (83/83), done.
Delta compression using up to 12 threads
Compressing objects: 100% (82/82), done.
Writing objects: 100% (83/83), 25.66 KiB | 3.67 MiB/s, done.
Total 83 (delta 46), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (46/46), done.
To https://github.com/gozuk16/testrepo
 + xxxx200...xxxxd73 master -> master (forced update)

git submoduleを別のリポジトリに切り替える

Git

以前、git submoduleを別のブランチに切り替えるというのを書いたのですが、

gozuk16.hatenablog.com

今度はオンプレのBitbucketからクラウドのBitbucketへ移行したのでリポジトリを切り替えました。
ググると .gitmodules を書き換えるというのが引っかかりますが、コマンドで出来るんじゃないかなと思って調べたらできました。

$ git submodule set-url <path> <newurl>

でした。

実際にはこんな感じ。(${workspace}はクラウドのworkspace名です)

$ cat .gitmodules
[submodule "test_sm"]
    path = test_sm
    url = https://git.example.com/scm/test/test_sm.git
    branch = master

$  git submodule set-url test_sm https://bitbucket.org/${workspace}/test_sm.git
Synchronizing submodule url for 'test_sm'

$ cat .gitmodules
[submodule "test_sm"]
    path = test_sm
    url = https://bitbucket.org/${workspace}/test_sm.git
    branch = master

$ git commit .gitmodules
[master xxxxxxx] migrate git.example.com to bitbucket.org/${workspace}.
 1 file changed, 1 insertion(+), 1 deletion(-)

簡単ですね。

JIRA CloudでTempo Timesheetsを使っているときに残余を調整する

JIRA Tempo

JIRAとBitbucketをオンプレからクラウドへ移行したのですが、色々勝手が違って戸惑ってます。(Confluenceは許容できない機能差が あっていったん断念しました)
クラウドのほうがアプリ間の連携はいいし、慣れれば今の在宅勤務中心な業務にあっていると思うんだけどね。
長期的にも自分がいなくなっ後も継続していけるようにマネージドなサービスにするほうがいいかなと思ってる。
つい先週50歳になってそういう事も考えないといけないなと思ったわけですよw

で、JIRA Software Serverではストーリーポイントではなく、Time Trackingで進捗管理を行っていて、時間入力が便利なTempo Timesheetsを使っていたのでCloudでも同じようにしたんですね。
ところが、初期見積りを入れたあとで修正したら残余が変えられないと言う。
たしかに、チケットの右のバーに残余が表示されてない。設定をいくら見ても出せない。。。
Tempo TimesheetsのLog Timeには残余を入れる欄があるんですが、Durationを入れないと残余見積を入力させてくれません。

f:id:gozuk16:20201015221254p:plain

困ったなーと思ってとりあえずぐぐってたら、本家のKnowledge Baseにありました。

Edit Remaining Estimate in new Jira issue view tempo-io.atlassian.net

旧バージョンの表示に戻して編集すれば出来るよと・・・

f:id:gozuk16:20201015221930p:plain

まじか。なんつー、workaround だw

f:id:gozuk16:20201015222017p:plain

まあ、できました。

asciidoctor-pdfで文字色を変える (2019年版)

AsciiDoc PDF asciidoctor-pdf 日本語

以前書いた

gozuk16.hatenablog.com

で、PDFでも文字色を変えるというやり方ですが、asciidoctor-pdfを最新化したらおかしくなってしまいました。

具体的には、色は変わるのに↓のような {zwsp} という文字が差し込まれるようになってしまいました。

{zwsp}日{zwsp}本{zwsp}語{zwsp}

ぐぐってみると、

backport.net

ここの説明を読むと zwsp というのは幅ゼロのスペースだそうで asciidoctor-pdf-cjk が入れているらしい。

なるほど。文字色をつけるのに、

pass:[<span style="color:#ff0000">日本語</span>]

としているわけだからCJKが差し込むzwspをpassが可視化しちゃうのね。
しばらく考えて回避策を考えました。

pass:[<span style="color:#ff0000">]
日本語
pass:[</span>]

この文字色をつけるやり方自体がworkaroundなのに、更にworkaroundを積み重ねるのも何だけど、まあとりあえず回避で・・・

WebDriver(ChromeDriver)でProxyのWeb認証を通す

Go proxy

この記事は、Infocom Advent Calendar 2019 2日目の記事です。

qiita.com

経緯

社内からインターネットの何かを使うときにはProxyを通さなければならないのですが、現在のProxyは認証を通す必要があります。
Windowsで社内のADに参加している場合は、ログオン時に自動的に認証を通してくれるので意識する必要はありません。
ADに入っていない場合は、以下の条件を満たす必要があります。

  • httpのサイトにアクセスする
  • リダイレクトされた認証ページを開く
  • ユーザIDとパスワードを入力し、認証が通ったら最初に開いたhttpにリダイレクトされる

GUIが使えないLinux系のサーバではcurlを使ってプロキシ認証を通しています。
ところが、最近エラーになることが多くなってきました。
w3mでやったら一発でうまくいくのですが・・・
しばらくはコマンドを何度も実行するようにしていましたが、ある時WebDriverならうまくいくかもと思って試してみました。

結論から言うとうまくいってます！

ブラウザなら失敗したこと無いのでまあ予想通りですが・・・。(なぜ今まで思いつかなかったのか)

実装

golangのagoutiというWebDriverクライアントを利用して実装してます。(実際にはChromeDriverを使いました)
開発はMacで行ってます。

サンプルソースを↓こちらに置いておきます。
※このソースをそのまま貼り付けても動きません。URLやパラメーターは調整する必要があります。

github.com

  • ChromeDriverを起動するためのoption
options := agouti.ChromeOptions(
        "args", []string{
                "--headless",
                "-disable-gpu", // 暫定的に必要とのこと
                "--ignore-certificate-errors",   // 認証関係のエラー無視
                "--no-sandbox",
                "--disable-xss-auditor",
        })

optionをつけなければChromeブラウザが普通に上がります。
デバッグをするときはその方が便利です。

  • Web認証ページの指定
page.Navigate("https://xxx.xxx.xxx.xxx:99999/proxy?foo=bar&hogehoge=http://neverssl.com")

page.Navigate() の引数に認証ページを指定しています。
私の環境ではリダイレクト先のhttpsじゃないサイトをパラメーターで指定することになってます。(最近はhttpsが多いのでrebuild.fmで言ってたneverssl.comを指定してます)

  • ユーザID
page.FindByID("user").Fill("xxxxxxxx")
  • パスワード
page.FirstByName("passwd").Fill("xxxxxxxxxxxxxxx")

パスワードは暗号化したものを外部から渡されて、復号してセットするほうがいいと思いますけど、とりあえず・・・
パスワード変えたり、ユーザID変えたりすることも当然ありますからね。

  • ウェイト
time.Sleep(time.Second * 5)

最後にリダイレクトするのをちょっと待ちます。なくても動いたけど念の為に入れてます。

build

Macで作業してるのでクロスコンパイルでLinuxバイナリを作成します。

$ mkdir linux-amd64
$ GOOS=linux GOARCH=amd64 go build -o linux-amd64/proxyauth ./proxyauth.go

run

  • ChromeDriverを入れておく必要があります

Mac

$ brew cask install chromedriver

Linux

$ sudo apt install chromium-chromedriver

依存するパッケージがやたら多いですがしかたありません。入れてしまいましょう！

認証サイトに直接アクセスするようにしておきます。
何故か大文字のNO_PROXYは効きませんでした。
この辺はツールによっていろいろなので、両方指定しておけばいいのかも。

$ export http_proxy=proxy.example.com:9999
$ export HTTP_PROXY=$http_proxy
$ export no_proxy=xxx.xxx.xxx.xxx
$ export NO_PROXY=no_proxy

今の所、失敗せずに一発で認証が通るようになってます！

MacでGoのクロスコンパイルをする

Go Mac Homebrew

Mac OSはMojaveでGoは1.13.4です。

昔、

gozuk16.hatenablog.com

というのを書いたのですが、いまはbrewで --cross-compile-common も --with-cc-common も使えないようです。

github.com

これに書いてなければだめなんですよね？

どうやら

GOOS=linux GOARCH=amd64 go build ./hogehoge.go

ってやるだけでできるっぽい。素晴らしい！ このままだと区別つかないのでディレクトリごとに出すように。

GOOS=linux GOARCH=amd64 go build -o linux-amd64/hogehoge ./hogehoge.go

あとでmakefileでも書きますか。。。

追記(2019/12/24)
makefile 書きました。

linux:
  GOOS=linux GOARCH=amd64 go build -o linux-amd64/hogehoge ./hogehoge.go
win:
  GOOS=windows GOARCH=amd64 go build -o windows-amd64/hogehoge.exe ./hogehoge.go

ついでにWindowsも入れときました。

更にcgo使ってるときに

# runtime/cgo
gcc_libinit_windows.c:7:10: fatal error: 'windows.h' file not found

というエラーが出たので以下のようにビルドしました。

$ brew install mingw-w64
$ CC=x86_64-w64-mingw32-gcc CGO_ENABLED=1 GOOS=windows GOARCH=amd64 go build -o hogehoge.exe

MacVim(gVim)のインサートモードでShift+Spaceの全角スペース入力ができない

Mac Vim 日本語 Google日本語入力

前提条件は、

  • MacはMojave(後にCatalina)
  • 日本語入力はGoogle日本語入力
  • Karabiner-ElementsではShift Spaceに何も設定してない
  • VimはMacVim-KaoriYa
    • :map :imap で確認してもShift + Spaceの設定無し

github.com

この状態で、MacVim-KaoriYaのgVimにおいてGoogle日本語入力中にShift Spaceが半角スペースになってしまう。
ちなみにターミナル上のVimではShift Spaceで全角スペースが入力できている。

ググっても同様の症状は見当たらず。
どうにもわからなかったので、Vimの設定でShift + Spaceで全角スペースが入力できるようにしてしまった・・・。

~/.gvimrc に以下を設定

imap <S-Space> 　 (←ここに全角スペースが書いてある)

f:id:gozuk16:20191110162205p:plain

これで、gVimでもShift + Spaceで全角スペースが入力できるようになりました。
ちょっと副作用で英数モードでも入るようになっちゃったけど、それも意外と便利かもしれない・・・