miscellaneous

Git related

Create a branch from unstaged/uncommitted changes on master

Context: I'm working on master adding a simple feature. After a few minutes I realize it was not so simple and it should have been better to work into a new branch.

This always happens to me and I have no idea how to switch to another branch and take all these uncommited changes with me leaving the master branch clean.

See https://stackoverflow.com/q/2569459/3235496 (if the changes are already staged you have to unstage them via git restore --staged filename or git restore --staged . for all files at once).

The usual sequence is:

• git switch -c new-feature (create a new development branch)
• [do what you have to do]
• git switch master
• git merge --no-ff new-feature (merge the new feature)
• git push origin master
• git branch -d new-feature (delete the local development branch)
• git push origin --delete new-feature (possibly delete the development branch from the central repository)

How to find the changeset that introduced a bug

It often happens that you realize that something is broken and that it has been broken for a while. With git bisect, you can figure out exactly when it became broken. When you know that, it is often much easier to fix the problem.

It works like this. You start by marking the current revision as bad since it contains the bug:

$ git bisect bad
You need to start by "git bisect start"
Do you want me to do it for you [Y/n]? y

You then jump back in history to a point where you hope the bug is not present:

$ git checkout HEAD~100
Note: checking out 'HEAD~100'.

You have to test your software at this revision and if the bug is not present, then you can mark it as good:

$ make tests
...
$ git bisect good
Bisecting: 675 revisions left to test after this (roughly 10 steps)

If HEAD~100 is known to be good you can directly issue the command git bisect good HEAD~100.

When you marked it as good, Git updated your working copy to a place roughly in the middle between the good and bad changesets. You now have to test this changeset and mark it good/bad.

$ make tests
...
$ git bisect good
Bisecting: 337 revisions left to test after this (roughly 9 steps)

Continue like this until Git has narrowed the search down to a single changeset.

You still have to do the debugging yourself, but using git bisect saves you from keeping track of which changesets you have already tested and which you still need to test.

When you're finished using the git bisect command in a repository, you can use the git bisect reset command to drop the information it was using to drive your search.

(as a reference the same procedure is described by Martin Geisler on Stackoverflow for hg)

View the change history of a file

Use

gitk filename

or, to follow filename past renames:

gitk --follow filename

Since gitk isn't part of the basic git package, you can also consider:

git log -p filename

The -p option let git generate the patches for each log entry.

Emacs related

Using ediff as git mergetool

Add the following sections to the .gitconfig file (code from https://stackoverflow.com/a/1818855/3235496):

[merge]
    tool = ediff
[mergetool.ediff]
    cmd = emacs --eval \"\
(progn\
  (defun ediff-write-merge-buffer ()\
    (let ((file ediff-merge-store-file))\
      (set-buffer ediff-buffer-C)\
      (write-region (point-min) (point-max) file)\
      (message \\\"Merge buffer saved in: %s\\\" file)\
      (set-buffer-modified-p nil)\
      (sit-for 1)))\
  (setq ediff-quit-hook 'kill-emacs\
        ediff-quit-merge-hook 'ediff-write-merge-buffer)\
  (ediff-merge-files-with-ancestor \\\"$LOCAL\\\" \\\"$REMOTE\\\"\
                                   \\\"$BASE\\\" nil \\\"$MERGED\\\"))\"

Now using the git mergetool command Emacs will be used (just edit the conflicting merge, save and exit to proceed to the next one).

Convert Dos to Unix line terminator via Emacs

Since many Vita-developers use Emacs and we prefer the Unix line terminator (\n), a useful command to remember is:

M-x set-buffer-file-coding-system RET iso-8859-15-unix

(undecided-unix is another valid option)

and now save the file with its new buffer coding system:

C-x C-s

Code completion via Irony-Server

• To generate the required compile_commands.json file use $ cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -B build/ src/
• After CLang / Irony-package upgrades re-run M-x irony-install-server RET
• Insights: http://cachestocaches.com/2015/8/c-completion-emacs/ and https://github.com/CachesToCaches/emacs_cpp_completion

Other areas

Debug vs Release in CMAKE

It's generally best to do an out of source build. From the vita/src directory:

Unix

$ cmake -DCMAKE_BUILD_TYPE=Release -B build/ src/
$ cmake --build build/

and for Debug:

$ cmake -DCMAKE_BUILD_TYPE=Debug -B build/ src/
$ cmake --build build/

Visual Studio

For multi-configuration generators CMAKE_BUILD_TYPE doesn't work, build type must be specified at build time:

$ cmake -B build/ src/
$ cmake --build build/ --config Release

and for Debug:

$ cmake -B build/ src/
$ cmake --build build/ --config Debug