mini-post about using tags in git commits.
In git a commit message is structured in a first
subject line, an empty newline and more text making the
body of the message.
The subject can be split in two components
tags and the actual
The tags can be used to pin the general area the patch is impacting, e.g:
ui: Change widget foo
When you are looking at the history using
git log having tags helps a lot digging out old commits, for example: you remember some commit added some timeout system in something related to the component
git log --oneline | grep foo:
Would help figuring out the commit.
This usage is the best when working with not well structured codebase, since alternatively you can do
git log --oneline module/component
If you use separate directories for each module and component within the module.
PS: This is one of the reasons plaid focuses a lot on tags and I complain a lot when tags are not used.
You might be subtle like this or just work on your stuff like that but then nobody will know that you are the one that did something (and praise somebody else completely unrelated for your stuff, e.g. Anton not being praised much for the HEVC threaded decoding, the huge work on ref-counted AVFrame and many other things).
Blogging is boring
Once you wrote something in code talking about it gets sort of boring, the code is there, it works and maybe you spent enough time on the mailing list and irc discussing about it that once it is done you wouldn’t want to think about it for at least a week.
The people at xiph got it right and they wrote awesome articles about what they are doing.
Blogging is important
JB got it right by writing posts about what happened every week. Now journalist can pick from there what’s cool and coming from VLC and not have to try to extract useful information from
git log, scattered mailing lists and conversations on irc.
I’m not sure I’ll have the time to do the same, but surely I’ll prod at least Alexandra and the others to write more.
You wrote your code, you wrote the tests and everything seems working.
Then you got somebody running your code on a big-endian machine and reports that EVERYTHING is broken.
Usually most of the data is serialized to disk or wire as big-endian, most of cpu usually do the computation in little-endian (with MIPS and PowerPC as rare exception). If you assume the relationship between the data on-wire and data in the cpu registers is always the same you are bound to have problems (and it gets even worse if you decide to write the data down as little-endian to disk because swapping from cpu to disk feels slow, you are doing it wrong).
The problem is mainly while reading or writing:
- Sometimes feels simpler to copy over some packed structure using the equivalent of
read(fd, &my_struct, sizeof(struct)). if the struct contains anything different from byte-sized variables it won’t work, so is safe to say it won’t work at all. Gets even worse if you forgot to mark the structure as packed.
- Writing has the same issue, never try to directly write a structure or even 16bit integers w/out making sure you get the expected endianess right.
Mini-post written to recall what not to do (more examples later).