Hacker News Reader

hyperboliston HN Argument: Main Reason Why Flash Will Remain The Preferred Online Video Tool

Bitrate is the primary determinant for bandwidth consumption, no?

hyperboliston Toto - Heroku blogging in 10 seconds & 230 LOC

Thanks for this, I'm enjoying it!

You probably want to add something like

  set :url,       "http://example.com"                      # site root URL

to your config.ru documentation.

hyperboliston On branching

Conventions are just conventions anyway. We've established that there's no technical barrier to your two objections. 1) You can clone different branches into different paths, which is exactly like a traditional svn workflow, and a pretty normal thing to do for continuous integrations and the like. 2) And if you never want to delete a branch, you can check on their merged status to determine if they're "done". More clever solutions have been supplied by others in this thread. You needn't convert to git, but it'd be polite to recognize that your objection to git is purely psychological.

hyperboliston Adobe: HTML5 Will Throw the Web 'Back to the Dark Ages of Video'

http://daringfireball.net/2010/02/winer_flash_open_standards

quote: But what if the source code to Flash Player is — as many would wager — a huge steaming pile of convoluted C++ horseshit? It’s sort of like what if Microsoft open-sourced the Internet Explorer rendering engine. It’s not like anyone who is now using WebKit or Gecko would switch to that just because it was opened — or that WebKit, Mozilla, and Opera would suddenly be obligated to or even interested in adopting IE-specific web features.

hyperboliston On branching

I'm not making that claim, and freely admit that I am utterly ignorant about mercurial. I'm merely demonstrating that, contrary to the author's assertion, it's possible to use git without deleting branches and still have a meaningful way to measure whether a branch is "done", and it's the common-sense measure of "has it merged?"

hyperboliston On branching

how do I see two different branches' versions of files?

You could clone the branches to different paths, I guess.

But nobody else will [know that a branch is "done".]

If you've instructed the team to care about merged status, they will. And there's nothing semantically strange about it either.

I get it, git isn't for you. I concede.

hyperboliston Adobe: HTML5 Will Throw the Web 'Back to the Dark Ages of Video'

Many sites deliver video by H.264 in the absence of Flash. It is seamless to the user, and there are no blue legos. The fact that Flash is missing from iPhones and iPod Touches, and that people with those devices are using the web, produced this situation. The "Dark Age" is already here, and it's not a dark age.

The link I submitted is indeed both an example of the "Dark Age problem" of HTML5 (that Firefox refuses to support H.264); and that video can be delivered quite satisfactorily via HTML5, without Flash.

hyperboliston Adobe: HTML5 Will Throw the Web 'Back to the Dark Ages of Video'

http://jilion.com/sublime/video -- a Video player for these approaching Dark Ages

hyperboliston On branching

How do I get both files side-by-side in Emacs so I can go through them thoroughly (some of us prefer that to reading diffs, you know)?

  git show branch:path/to/file > /tmp/file

I want the history of my codebase to be easy to get a feel for

So never delete branches. You'll know if they're "done" if they've been merged into your master branch.

hyperboliston On branching

Further:

To say "I'm done with this branch", merge it to master. This is natural; you already do this.

  git branch --merged master # list branches that are "done"
  git branch --no-merged master # list branches that are "not done"

Now you never need to delete any branches if you don't want to and you can eyeball their status without introducing any misbehaviors or gymnastics.

hyperboliston On branching

I read the article, I enjoyed it. It reminded me of why I like git so much.

git-diff doesn't require you to do gymnastics to compare files from different branches in the same working directory: "git diff branch1 [branch2] path" where omitting branch2 compares the working path instead of branch2's.

And I think your second problem with git, that big hairy branches should somehow be distinct from small simple branches, is also a non-issue. Especially since you already recognized the solution: let big hairy branches live, and small simple branches die.

Since you can reconstruct deleted branches, I don't see the problem with deleting them. Bugfix branches for specific releases can be created as needed by choosing the release commit in master as the starting point for the branch. If you really want to keep dormant branches around you can rename them to keep them distinct from "working" branches.

Sorry for not having specifically addressed these in the original comment, which was actually supposed to be a reply to fexl http://news.ycombinator.com/item?id=1095116

hyperboliston On branching

Coming from svn, I too felt initial discomfort about git's promiscuous branching, but then I learned to stop worrying and love the index. Working in svn repositories evokes "I wish this was a git repository" every time.

I wouldn't have initially trusted git if it weren't for Linus's Google Talk. And I'm glad I gave it the time it requires to change workflows.

The most unexpected side-effect of using git is a newfound willingness to follow experimental ideas in my projects as fast as I can think/type. I'll guess it comes from confidence in git's ability to safely partition branches in-situ; the relative speed and ease with which branches are created, merged and destroyed; and the existence of the index and stash. Git removes the version control inertia I didn't even know was there.