タグ別アーカイブ: git

gitのローカルリポジトリをローカルで共有したい

gitでワークスペースを複数作って違う作業をしたい場合に、
リモートのサーバを用意して、リポジトリを共有していた。

バックアップも兼ねているので、それはそれで良いのだけど
もっとご気楽にローカルのリポジトリを共有する方法があった。

[[http://d.hatena.ne.jp/bi_na/20120206/1328502980][gitのローカル用の共有リポジトリ(?)を作る方法Add Star]]

workspace/orginal/ に既にgitのローカルリポジトリがあるところから。

#+BEGIN_SRC sh
$ cd repo
$ git clone –bare workspace/orginal/ # ← 元のリポジトリから新しい共有用リポジトリを作る

$ cd workspace/new/
$ git clone repo/orginal.git # ← 新しいワークスペースを作る

$ cd workspace/orginal
$ git remote add origin repo/orginal.git # ← 元のリポジトリに origin を設定
#+END_SRC

ポイントは2つ。

まず、
元のリポジトリから新しい共有用リポジトリをcloneする際に –bare オプションをつけること。
これで、リポジトリとして必要なファイルだけがcloneされる。

もう一つが、
元のリポジトリに、今作った共有用リポジトリをoriginとして設定すること。
これで、元のリポジトリのフォルダも、引き続きワークスペースとして使用できる。

cygwinのファイルアクセスが遅い件:もっと解決編

magit を更新したら、表示が綺麗になった代わりに、反応がとても遅くなってしまった。

ファイルの更新情報を色々と表示してくれるのは助かるのだけど ファイルアクセスが遅い cygwin 上では、かなりストレスに感じる。

もちろん macやlinuxでは問題なくて、快適そのもの。

そこでもう少し、Cygwinのファイルアクセスの速度を改善してみる。

;; vc無効化は出きないけど、無力化が出来る
(setq vc-handled-backends ())
(eval-after-load ""vc""
  '(remove-hook 'find-file-hooks 'vc-find-file-hook))

まだ動作がモッサリした感じだけど、大分快適にはなった。

cygwinのファイルアクセスが遅い件:解決編

もうmagit無しではemacsでコーディングできない体になってしまった。 さらに便利を求めて git-gutter-fringe+ をインストールしたところ、 Macではもう最高の使い心地。

だけども。 これをCygwinとntemacsで使うと、しょっちゅうプチフリーズしてしまう。 Cygwinのファイルアクセスが異常に遅いせいなのだけれど、 仕事上Cygwin環境は必須だし、git-gutterは手放したくないし。

いくら便利でも、作業中に30秒も固まられると、さすがに我慢できない。 いい加減、ちゃんとCygwinに対策をしなければ…

と言う訳で。

Cygwinの起動やファイルアクセスが遅くて怪しい場合に

CygwinのFAQサイト を検索してみた。

以下、Cygwinのページから引用。

4.2. Starting a new terminal window is slow. What’s going on?

There are many possible causes for this.

~snip~

For almost all its lifetime, Cygwin has used Unix-like /etc/passwd and /etc/group files to mirror the contents of the Windows SAM and AD databases. Although these files can still be used, since Cygwin 1.7.34, new installations now use the SAM/AD databases directly.

To switch to the new method, move these two files out of the way and restart the Cygwin terminal. That runs Cygwin in its new default mode.

~snip~

For the AD case, it can be slower than the old method, since it is trading a local file read for a network request. Version 1.7.35 will reduce the number of AD server requests the DLL makes relative to 1.7.34, with the consequence that you will now have to alter /etc/nsswitch.conf in order to change your Cygwin home directory, instead of being able to change it from the AD configuration.

If you are still experiencing very slow shell startups, there are a number of other things you can look into:

One common cause of slow Cygwin Terminal starts is a bad DNS setup. This particularly affects AD clients, but there may be other things in your Cygwin startup that depend on getting fast answers back from a network server.

~snip~

Another cause for AD client system is slow DC replies, commonly observed in configurations with remote DC access. The Cygwin DLL queries information about every group you’re in to populate the local cache on startup. You may speed up this process a little by caching your own information in local files. Run these commands in a Cygwin terminal with write access to /etc:

getent passwd $(id -u) > /etc/passwd getent group $(id -G) > /etc/group Also, set /etc/nsswitch.conf as follows:

passwd: files db group: files db

~snip~

Either in addition to the previous item or instead of it, you can run cygserver as a local caching service to speed up DC requests.

~snip~

A less preferable option is to create a static read-only cache of the authentication data. This is the old-fashioned method of making Cygwin integrate with AD, the only method available in releases before 1.7.34. To do this, run mkpasswd and mkgroup, then put the following into /etc/nsswitch.conf to make Cygwin treat these files as the only sources of user and group information:

passwd: files group: files

~snip~

If none of the above helps, the best troubleshooting method is to run your startup scripts in debug mode. Right-click your Cygwin Terminal

~snip~

4.3. Why is Cygwin suddenly so slow?

If suddenly every command takes a very long time, then something is probably attempting to access a network share. You may have the obsolete //c notation in your PATH or startup files. Using //c means to contact the network server c, which will slow things down tremendously if it does not exist.

要するに、ドメインで使っている会社のPCで遅くなる原因は。。。

  1. cygwinを 1.7.35 以降の最近のバージョンにする (古いのは遅い)
  2. DNSのIPアドレスが間違っていると、長い待ちがおこる
  3. ドメインじゃないなら、 /etc/passwd と /etc/group を消すと良いかも(知れない)
  4. ドメインなら、ドメインコントローラの返事が遅いのかも
    • その場合、passwd/group をキャッシュして高速化できる
    • cygserverでドメンインキャッシュサーバをたててみても良いぞ
    • そもそもドメインにアクセスするの辞めちゃえば? (ADが更新しても知らんけど)
  5. それでもダメならデバッグモードで起動してみな
  6. ひょっとして ‘//c’ とか書いてない?

DNSが関係しているのは分かっていたけど、 会社のドメインコントローラが遅いとは疑っていなかった。 Windowsでは困ったことないし。

でもやってみよう。

まずはバージョン確認

以下のどちらかで確認できる。

uname -a
cygcheck -c cygwin

2.2.0 だったので、問題なし。

/etc/passwd と /etc/group の削除

cygwinでドメインに関係するような事はしないし、 むしろ悪さしそうなので、まず削除して様子をみてみた。

数時間使ってみて、酷いフリーズは経験しなかったけれど、 プチフリーズが解決したかと言うと、ちょっと分からない。

AD情報のキャッシュ化

ドメインの情報を削除するのも危険な気がしたので、 一応キャッシュしておいて、様子をみてみた。

ドメイン情報のキャッシュは、こうしてとれる。

getent passwd $(id -u) > /etc/passwd
getent group $(id -G) > /etc/group

その後、 /etc/nsswitch.conf を編集して、 ADにアクセスするより先にキャッシュ(files)を見るように変更する。

passwd: files db
group:  files db

正直、これも良くなったのか悪くなったのか分からない。

そもそもドメイン情報を使わないようにする

いくつか試してみた結果、 /etc/passwd と /etc/group を削除してしまうことにした。

実はこの状態でも、ドメインでアクセス管理しているネットワークサーバの ファイルにアクセスできたのだった。しかも今迄よりもサクサクと。(汗)

まだ、たまにフリーズはするものの (キャッシュはあった方が良いのかも知れない)、 全体的にファイルアクセスが軽快になった。

無くて良いものは、無い方が良い。 この状態で、またしばらく使ってみようと思う。

Bitbucketとローカルのgitを連携する

[Bitbucket](https://bitbucket.org/plans)とローカルのJenkinsを連携させる。

このJenkinsは個人作業用なので、gitとJenkinsの関係が通常とは逆。

1. ローカルのgitリポジトリで作業&コミットする
2. Jenkinsで、ビルド&テストを行なう
3. 成功した場合にBitbucketにpushする

# Bitbucketにリポジトリを作成する
Bitbucketのウィザードに従って作成。
(Webで検索したのとは結構変わってるみたい)

出来たリポジトリは [org2html](https://bitbucket.org/somof/org2html.git)

今作ったリポジトリのページで、
Setting > デプロイ鍵 > 鍵を追加 から
さっき作ったJenkinsユーザの公開鍵をコピペしておく。

# ローカルのgitリポジトリにBitbucketを登録
まず、ローカルのgitリポジトリに、さっき作ったリモートリポジトリを追加。

$
$ git remote add origin https://bitbucket.org/somof/org2html.git
$ git config branch.master.remote origin
$ git config branch.master.merge refs/heads/master

Bitbucketの方で、最初から README.* や画像ファイルが入れられていたので

$
$ git pull
$ git rm README.*
などして削除
$ git push

Macの人は、以下のようにパスワードを覚えさせておくと、少し便利。

$
$ git config –global credential.helper osxkeychain

ここまでやってみて気がついたけど。(汗)

Bitbucketって、置いてあるhtmlファイルのプレビュー出来ないんだな…
作業には困らないけど、地味に不便。

てか、今回のワークフローだと、 Bitbucketに転送する意味無くなっちゃったな。

仕事で使っているgitlabだとプレビューできるので、
HTMLドキュメント化した資料を公開するのにも使えて、
GitHubやBitbucketも同じなんだと思ってた。