Actual IM conversation:

[me]: ever use git?
[them]: Why would I do such a thing?
[me]: peer pressure, because all of your co-devs 
      told you it was the cool thing to do

I thought that developing the software that drives FATE would serve as a good opportunity to learn the Git source control software. Foolish.

Git terrifies me. Thing is, I make mistakes. Lots of mistakes. I need a source control management system (SCM) that is sympathetic to my incompetence. As it stands, when I make a mistake, I have to dig through 140 git-* commands on my system to try to guess which one just might offer a shimmering hope of redemption. If I choose poorly, I will only exacerbate the situation as well as pollute the official history log. Such was the case when I tried to revert one particular commit. I can’t remember how that worked out exactly. I guess I got the correct code back eventually, but the log file tells a sordid tale.

More recently, I edited a file but decided I didn’t want the changes; I wanted the previous committed version back. Perhaps use git-revert, like most other SCMs? Goodness, no. Maybe git-reset? Guess again. Turns out git-checkout is what I was looking for (thanks, Mans). Now, I have made the mistake of using git-commit in such a way that actually committed more files than I thought it would (serves me right for following examples and not reading the pedantic documentation first). Now I find myself wanting to undo the commit for one particular file but not actually lose the changes.

Here’s a solution that can’t fail: ‘rm -rf .git/’, followed by a re-reading of how to initialize a local Subversion repository. And whose idea was it to tag revisions with random 160-bit hex codes like 488dfe6a946bbbbb4e095a5d758ad9808f7336b1? (Yeah, I know, they’re SHA-1 codes or some such. I don’t care; it’s still not human-friendly). I hope FFmpeg never gets around to making the switch.

Someone asked me a question in email today that I thought I would pass on to the broader group. Are there any general methods for attaching general metadata — e.g., EXIF data — to individual video frames?

At first thought, this strikes me as a container-level matter. However, there could be a video codec that embedded metadata in each frame and could be stored in any generalized container format.

Personally, I have always been more aware of issues surrounding content playback vs. content creation which I admit is somewhat of a weakness in my overall multimedia knowledge. The submitter had in mind data along the lines of absolute timestamps and GPS coordinate information to be included with every frame. This may seem a tad excessive but you can never underestimate other peoples’ requirements.

Google announced their Highly Open Participation Contest today. I really hope that the name is not a backronym inspired by the common acronym for International House of Pancakes. GHOP is an effort to bring pre-university students into the open source fold through a Summer of Code-like program. Whereas GSoC projects were required to center around code, these GHOP efforts can be related to documentation, QA, R&D, translation, and assorted other areas, as specified by participating project’s issue trackers.

10 open source projects were selected for this initial run. FFmpeg was not one of them. According to the FAQ page, “each project has a fairly low barrier to entry”. I admit, that would eliminate FFmpeg from consideration right away.