Technically, I like this protip very much. However, in real business, I'm pretty sure that this is not the customers want 80% of the time. Anyway, manually writing a report is a useful way to force oneself to zoom out and re-think about the project.
I use ctags
to do the job. The richer information can also be leveraged by VIM to jump automatically
Why does the regex end with "[^.php]"? It avoids strings ending any of the four characters? Do you mean to avoid matching ".php" suffix?
This is awesome!
Solved my long lasting confusion. I know ctrl+r but seems I can not search forward if I accidentally missed the command line I'm searching for. The arrow keys are more friendly.
@arpohahau
it'll be marked as what you put in the brackets.
For the uuencode, is there any convenient way to format it as regular email attachment so that we do not need to run commands at the recipient side?
@mabraham @mavimo , yeah, I think using it as an intermediate step is reasonable. Treat it as a report that Git writes for you (to remind you of things happened last week) but not the report you write for the customer.
My observation is that the granularities of commits are very different. Some commits add new functions or important upgrades. Those will be meaningful if the messages are verbosely written. There are usually some small fixes, which are too detailed to present to the customer ( The post removes merge commits. I think it is for the same reason, :) ). Cumulating commits into natural function points is better for the communication.
I'm also developer. :)