Tim's Tips and Tricks

Git tips

 * Show when a commit was entered in the tree: "git describe "
 * Show the version of software where a change first appeared: "git describe --contains "
 * git log # narrow scope of log
 * git log
 * git lg []  # nice summary
 * alias.lg=log --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr %an)%Creset' --abbrev-commit --date=relative
 * how to do a git alias, with colors!


 * find the commit for a specific line in a file: "git annotate | grep "
 * Then do: "git show "
 * This is good to find out: why is it here? who did this?, when did it get changed to this?


 * git bisect


 * git proxy (finally!!)
 * See Using git with a proxy


 * git grep (grep only git-managed files) (credit to Thomas Petazzoni)

Note also that you can use 'git grep', that will only grep the source files that are under version control, skipping all object files and other generated files you may have in your tree, if you're not doing out of tree builds. I use 'git grep' routinely.


 * Reflog: Git reflog is great for finding commits that you have 'lost' but how do you see where they went? I use reflog piped into gitk....
 * git reflog | awk '{ print $1 }' | xargs gitk


 * several people said: "git rebase -i" as a replacement for quilt
 * git add -p
 * git commit --amend

For fixup commits, followed by - Automatically updates an existing patch
 * git commit --fixup 
 * git rebase origin/master --autosquash

More miscellaneous items
 * git add -i - add interactive (select individual hunks)
 * git log -G --all
 * show log entries for the entire git history (including deleted files) for the search string on any added or removed lines
 * git log -- file1
 * show log for deleted file 'file1'


 * git show :file1
 * show the version of file at the specified commit


 * git branch --contains 
 * Show the branches that contain a commit


 * git patch-id 
 * show the patch-id (a checksum for the patch, with


 * git log --graph --decorate --simplify-by-decoration
 * show a graph of the history of the tree, only showing 'notable' (named) commits. This is good for showing the branch structure, if you've been tagging your branches


 * git log --merges --date=short --format=format:"%cd %s %h" | grep "Merge.*to" | sed "s/Merge.*to //g" | sort -n | uniq
 * IF your merges include the phrase "Merger ... into ", then this command shows a list of dates when merge commits were done, and the branch name used for that merge commit. This is good for showing the name of a branch at a specified period of time (to help understand branch history)

patch management

 * quilt - patches as first class objects
 * git for development work, then convert to quilt patches
 * git rebase --interactive
 * precommit - quilt pop -a, basediff, quilt push -a, scripts/fix-filemodes.sh
 * diffinfo - my own tool for managing patches
 * splitting a patch: splitpatch - tool to break patches apart

source finding

 * cgrep, mgrep, confgrep, kgrep, armcgrep, jgrep - scan C code, Makefiles, .config, Kconfig, arm C files, and java code, respectively for a search pattern
 * thin wrappers on 'find . [some conditions] -exec egrep $1'
 * finds - find a string in a set of files (Credit to Todd Fischer of RidgeRun)

I use a tool, finds, I got from someone about 15 years ago. It simply does a recursive look for a string in all files of interest in a directory tree. When I get a big tarball of code that I don't intend to build, but want to grab some logic, I use finds. I have created a variety of variations of finds (which I usually later throw away) as my search needs change. Essentially finds is

find. -exec fgrep -H "$1" {} \;

but with lots and lots of other qualifiers. You can see a usable version at

https://www.ridgerun.com/developer/wiki/index.php/Tip_of_the_day#finds_-_find_a_string_in_common_text_files

kernel debugging

 * use of fs/sync.c:SYSCALL_DEFINE0(sync) for user-space triggered printks
 * use of qemu for kernel debugging

testing

 * tbtorture.sh - for stress testing

board handling

 * consistent board setup (including remote access)
 * connections: serial, network, power (web-based control) [images]
 * power port controller [image]
 * Usually use tftp boot kernel, with NFS rootfs
 * but can do other setups: feed kernel through serial line, put kernel on SD card using known-good kernel, etc.


 * Ttc - command line tool for board control
 * abstracts differences between boards
 * allows for board sharing (ttc reserve)
 * everything is scritable, and remotable
 * object-oriented: inheritance to quickly modify attributes of a board "class"
 * items abstracted:
 * kernel source, toolchain, architecture, defconfig, kernel image name, tool paths
 * kernel build, install
 * board console access, reboot, run arbitrary commands, reset
 * filesystem access (copy from/to)

Finding the ttyUSB* for a board connected to a multi-port hub: (Credit to Todd Fischer of RidgeRun): A recurring problem I had was finding the right /dev/ttyUSB? device. I have a nice USB to 4 serial port adaptor in a metal box I have screwed to my bench. I also use several USB serial dongles. For reasons I don't understand, they change association (at least under Ubuntu). I created two scripts lsuart and uart. The output of lsuart gives me information about the serial ports, like

Available USB UARTs --- a:/dev/ttyUSB0 FTDI USB Serial Device 0000:00:04.1-4.1 (4 port jack A) b:/dev/ttyUSB1 FTDI USB Serial Device 0000:00:04.1-4.2 (4 port jack B) c:/dev/ttyUSB2 FTDI USB Serial Device 0000:00:04.1-4.3 (4 port jack C) :/dev/ttyUSB3 pl2303 0000:00:02.1-4.2 d:/dev/ttyUSB4 FTDI USB Serial Device 0000:00:04.1-4.4 (4 port jack D)

In use -- /dev/ttyUSB4: 9705: picocom -b 115200 -r -l /dev/ttyUSB4

I gave names (a, b, c, d) to the 4 fixed uarts. Now I look at which port my serial cable is plugged into - say the 3rd one, which I call c, and I can fire up picocom with the standard setting using

uart c

Sometimes I can't find a terminal session (too many windows open), so I use the PID from the In use section of the lsuart output to kill it.

If others have the "where is my USB serial port" problem, I can love up my shell script (lsuart is a symbolic link to uart), which is around 200 lines of ugly sysfs parsing.


 * ser2net (Credit to Jean-Christophe PLAGNIOL-VILLARD)


 * ptxdist and barebox (Credit to Robert Schwebel)
 * can load kernel via nfs server (does not require root privileges on host)

--- How to copy data over serial line to Linux: (credit to Alan Carvalho de Assis) http://acassis.wordpress.com/2012/10/21/how-to-transfer-files-to-a-linux-embedded-system-over-serial/

personal productivity

 * my workflow:
 * different day for each topic area
 * today script
 * multiple todo's, NOTES all over the place (several in each work directory)
 * must do a context save in each directory, before moving on
 * git branch is essential - commit changes (even if flaky) before moving on


 * my favoriate mailing lists:
 * sorry, but linux-embedded seems to be dead
 * lkml, linux-arm, yocto-devel
 * celinux-dev


 * attend conferences, talk to smart people
 * conferences I attend:
 * ELC, ELCE, linuxcon US, Linuxcon Japan, Linuxcon Europe (by serendipity)
 * what about plumbers?? other regional events??