Showing posts with label cygwin. Show all posts
Showing posts with label cygwin. Show all posts

Setting Git with P4merge in Babun

In previous post, we have discussed on setting up Babun in Windows, the next step was to setup a good merging tool to work with Git. Good and free merging tool is essential when resolving conflict during rebasing or merging. There are several good tools but the one we're comfortable with is P4Merge.

If the `p4merge.exe` binary is not found within the Babun shell, then you've to update the environment variable `$PATH` to append to the exact location of the binary. This can be done through Windows' environment path as well. Since we want our Git configuration file `gitconfig` to be portable with minimum tweaking, we can opt to set direct path.

This is where `cygpath` comes in which will convert path between Unix and Windows.

If we want to find the Windows path to our default Babun installation directory.
$ cygpath -w /
C:\Users\foobar\.babun\cygwin

How about the Unix path for `p4merge.exe` binary.
$ cygpath -u "C:\Program Files\Perforce\p4merge.exe"
/cygdrive/c/Program Files/Perforce/p4merge.exe

To make sure Git can find `p4merge.exe` binary from Babun.
$ cygpath -asm "/cygdrive/c/Program Files/Perforce/p4merge.exe"
C:/PROGRA~1/Perforce/p4merge.exe

Next, set `p4merge` our default merge tool and the direct path to its binary.
$ git config --global merge.tool p4merge
$ git config --global mergetool.p4merge.path C:/PROGRA~1/Perforce/p4merge.exe

If you don't like the tab ordering of the merging windows, customize to your liking.
$ git config --global mergetool.p4merge.cmd \
    "C:/PROGRA~1/Perforce/p4merge.exe" $BASE $LOCAL $REMOTE $MERGED

Additionally, `cygpath` also have built-ins options to access default system paths in Windows.
$ cygpath
......
System information:

  -A, --allusers        use `All Users' instead of current user for -D, -O, -P
  -D, --desktop         output `Desktop' directory and exit
  -H, --homeroot        output `Profiles' directory (home root) and exit
  -O, --mydocs          output `My Documents' directory and exit
  -P, --smprograms      output Start Menu `Programs' directory and exit
  -S, --sysdir          output system directory and exit
  -W, --windir          output `Windows' directory and exit
  -F, --folder ID       output special folder with numeric ID and exit

You can access these path directly with Windows Explorer using `cygstart`.
$ cygstart `cygpath -D`

`cygstart` is a tool is used open almost anything. For example, web URL but you must prepend it with `http`.
$ cygstart http://google.com

Development with Docker Toolbox and Babun

For those stuck with or prefer Windows environment, Docker Toolbox is the painless and simplest way to have a consistent development environment using Docker. While we can duplicate the same environment through actual virtualization or Window Subsystem For Linux (WSL), the time taken to configure and setup the environment does not worth the effort. Furthermore, Docker still not quite works for WSL yet.

While the Git Bash for Windows works well for its basic features, a Bash prompt with some *nix utilities, there are still several console apps solely missed like rsync and wget, which will not be bundled together unless you install these separately. Furthermore, you have to waste time to customize the console prompt to your liking (optional).

This is where Babun, a Windows shell over Cygwin, comes in. The sensible default settings provided by  oh-my-zsh with wide range of extensible plugins is good enough without much tweaking.

Babun Docker
Since we're using Docker Toolbox, we also need to make sure it works with Docker Toolbox through Babun Docker.

Go to the Docker QuickStart Terminal and stop the Docker Machine.
$ docker-machine stop default

Open Babun shell and install Babun Docker.
$ curl -s https://raw.githubusercontent.com/tiangolo/babun-docker/master/setup.sh | source /dev/stdin
$ babun-docker-update
$ docker-machine start default

Always load the Docker Machine settings on new opened terminal session.
$ echo "# Docker Machine stuff\n eval \$(docker-machine env default --shell zsh)" >> ~/.zshrc

Zsh and tmux
Next, which is quite crucial for me was to auto load tmux every time Babun or Zsh start.
$ pact install tmux

In your `.zshrc`, enable the tmux plugin and set it to autoload.
# Enable this before the plugin
ZSH_TMUX_AUTOSTART=true

plugins = (git tmux)

The next step is to download my own tmux configuration file and reload the Zsh shell to reflect the changes. You can also close and re-open the Babun shell. There was an issue where the Babun shell cannot start properly due to unknown error. Update your Babun installation (which actually is Cygwin) should fix the issue.
$ wget https://raw.githubusercontent.com/kianmeng/dotfiles/master/.tmux.conf
$ source $HOME/.zshrc

Slowness
Depending on the number of plugins enabled and theme selected, Babun shell can be quite slow. Keep your enabled plugins to a minimum, pick less resource intensive theme, use a Zsh framework to manage these plugins, or optimize Cygwin instead. Nevertheless, one way to check if your shell prompt is slow, run this command.
$ babun check

This Week I Learned - 2016 Week 14

Last week post or the whole series.

#1 Replace Git Bash with MinTTY. Even though you can run Bash on Ubuntu in Windows right now, the most acceptable way (without using the dreadful Windows Command line) before this is through Cygwin and MinTTY. Don't like MinTTY? Well you've Babun and MSYS2, both are based on Cygwin. But still, nothing beat a Vagrant emulated environment.

#2 12 years, 12 lessons working at ThoughtWorks. (HN thread, Reddit thread) Some beg to differ. His retrospective team approach, especially the four key questions, should be applied by any software team. Note that ThoughtWorks is both a software house and a consulting firm.

#3 BPF Compiler Collection. Efficient Linux kernel tracing and performance analysis. You can read the docs and try it out. Only for Linux kernel 4.1 and above though. Compliment to the Brendan Gregg's Linux performance material but at different approach.

#4 Brett Victor's bookshelf. Some people are just prolific book reader. I always love his idea of reactive documents, an implementation of his concept of Explorable Explanations.

#5 Startups in MontrĂ©al. E14N is the only one I'm aware of. Anyway, the discussion at HN is far more interesting regarding the place. Language racism is true and alive there, culturally and systematically forced upon you.

#6 Effective code review or faults finding and blames? Why do you need code review in the first place if trivial matter such as coding convention still cannot be properly enforced? Note that there are tools exists to fix most of these issues and is a no-brainer to rectify this (is just a command away). Root cause is still there is lack of healthy culture that values quality but instead more towards faster delivery.  Or maybe because the software industry itself does not promote integrity (Lobsters thread)?  Or maybe we applied the wrong approach?

#7 perlootut - Object-Oriented Programming in Perl Tutorial. Holy Macaroni! I've never realized that Perl's built-in Object-Oriented feature is so limited. In other words, object in Perl is a glorified hashes. Yes, you have to write your own classes from scratch!

#8 How to start gnome-terminal in fullscreen. Nobody bother to add or enable this feature as sensible default and you have to resort to multiple ways to get it to work. While I can understand of reducing the UI clutters (or dumbing down)in GNOME, but nobody actually use the gnome-terminal in fullscreen mode? It seems that GKH also have issue with gnome-terminal itself.