Showing posts with label p4merge. Show all posts
Showing posts with label p4merge. 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

This Week I Learned - 2016 Week 47

Last week post or the whole series.

What an excruciating stressfull week. So many things to follow up and so many things broken, including my own body till I have lost 3kg. On a positive side, when you're down with sickness, your perspective towards your environment changed, in a slightly turn off way.

On Git. I just realized, unintentionally, my git-fu just increased by 0.5% since last two weeks. When checking for merge through rebasing and merging, it seems the LOCAL and REMOTE branch have been interpreted differently in all merging tools. P4Merge interprets it differently? To summarize it, LOCAL is the originals, REMOTE is the changes you want to add regardless it's a rebasing or merging process.

Now, after you've resolved all the conflict either through rebasing or merging, to visualize and compare your changes (just to be sure), we can use `git diff` command to compare between two ranges.
$ git diff branchX..branchY

Note the double-dot to specific range there. It seems that you can specific either double-dot or triple-dot to specific ranges but indicates different types of output. The Venn diagrams and commit trees below shows the differences.




There is one practive that I do follow when using Git in feature branch, which is to commit early and commit often. However, one of the issue is that the feature branch history is cluttered with many tiny commits. While this is useful when working with others on the same branch (we're aware of what's going on), it's best to squash these commits before merging into `master` branch. There are two ways (with different behaviours) to squash all the commits.

First, is to squash these commits when merging to `master` branch. The source branch, in this case, `branchX` will be throw away.
$ git checkout master
$ git merge --squash branchX
$ git commit

Second, is to sqush these commits when rebasing. This is my prefer method where we still keep the source branch. However, if you have a lot of commits, it's quite slow as you have to assign the rebasing method (either squash or fixup) for each commit. Some Git client tools support this feature to squash commit but I never really explore this.
$ git checkout branchX
$ git rebase -i `git merge-base branchX master`

That about it for this week, more stuff to come in coming weeks as we're approaching the end of they year.