I'm sure I looked at Prose some time ago, but must have decided something was lacking. But I just took a look at it again, and it's just what I need. In fact, I had started a similar project myself not long ago, and now I feel relieved that I can officially call it dead and stop fretting about having stalled out on it.Tweet
The most dangerous thought that you can have as a creative person is to think that you know what you're doing. Because once you think you know what you're doing, you stop looking around for other ways of doing things.
He's posted references and follow-up notes at http://worrydream.com/dbx/.Tweet
Every Git user, from novice to expert, gets this error message at some point, maybe even daily:
$ git push origin master To firstname.lastname@example.org:bgreenlee/myrepo.git ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to 'email@example.com:bgreenlee/myrepo.git' hint: Updates were rejected because a pushed branch tip is behind its remote hint: counterpart. Check out this branch and merge the remote changes hint: (e.g. 'git pull') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.
There are a couple ways this can happen, but it all boils down to this: the remote repository you're pushing to has one or more commits that you don't have in your local repository. Don't worry, though, the fix is easy, although how to go about it depends on what you're trying to do.
Refresher: Rebase vs. Merge
Before we dive in, a quick refresher on rebase vs. merge. These are two general strategies for combining two branches.
Consider the following case:
master: A -> B -> C my-fix: \-> D
Here, you created a branch named “my-fix” from master while it was at commit B. While you were working on your fix, someone else pushed commit C to master. You finish your fix and commit it to the my-fix branch. That's commit D above.
Now you're ready to merge your my-fix branch back into master. There are two ways to go about this.
You can do:
git checkout master git merge my-fix
This will resolve the differences between the two branches by doing a three-way merge using commits C and D and their common ancestor, B. It does this by creating an additional merge commit, which we’ll call M:
master: A -> B -> C -> M(B,C,D)
You can also do:
git checkout my-fix git rebase master git checkout master git merge my-fix
The first checkout is just to make sure you're starting on the right branch. You may already be on the my-fix branch, in which case you can skip it. What git rebase master does is “rewind” your branch to the point at which it diverged from master, B, then apply all the commits from master made after that point (C), then “replay” your commits to my-fix (D). What you get is:
my-fix: A -> B -> C -> D’
Note that I used D’ above. This is because while the content of the commit is the same as your original commit D, it's technically a different commit, with a different SHA. This will be important later.
The last two commands switch back to master and then merge my-fix with master. Since at this point my-fix has everything that master has, plus one extra commit, the merge is just a “fast-forward”, meaning that all git has to do is move the HEAD pointer to D’—no merge commit is required.
Now, merging vs. rebasing is somewhat of a religious issue, although in my experience, most organizations prefer rebasing, as it keeps the commit history from getting cluttered with merge commits. I am going to go on the assumption that rebasing is the preferred method.
Now, let's get back to fixing our problem.
Scenario 1: Pull, then Push
This is the most common scenario, and simplest fix. Say you've made some changes in the master branch of your local repository, then go to push them to the master branch of the remote repository. If your push is rejected, what has most likey happened is that someone else pushed some changes to the remote master while you were making your changes, and you need to pull them down to your repo before you can push your changes up. So do a 'git pull --rebase', then push again.
Scenario 2: Force Push
Let's say you've been working on your own branch, and suddenly git is rejecting you. Now you know that no one else has been pushing commits to that branch, so what happened?
Most likely, you updated your local branch by rebasing against master. Again, this “rewinds” the commits in your branch to the point where they diverged from master, then pulls in the commits from master that you don’t have, then “replays” the commits in your branch that weren’t in master as new commits. So when you go to push those to your remote branch, even though it may look like the commits are the same, the SHAs are different, so git will refuse to update the remote branch.
One way around this is to force push:
git push -f origin my-fix
This tells git that you don’t care about what’s on the remote branch, just update it with what you have locally. This can be dangerous. Don’t do it unless you know what you’re doing. You would only ever want to do this if you are sure that you are the only one working on that branch, and that you have all the commits locally that are on the remote branch (i.e. you didn’t push changes from another machine). If that’s not the case, and, say, a coworker had pushed some of her own changes to your branch, you will overwrite those changes. Now, chances are they will be recoverable (she probably still has them in her local repository), but digging yourself out will be painful.
If you are in a situation where you've rebased your branch and meanwhile your colleagues have pushed changes to the remote branch, one way to get back on track is to cherry-pick their commits into your branch, and then force-push your branch (after telling your colleagues to hold off on pushing):
git fetch # to make sure your repo knows about their commits git log origin/my-fix # to see what their commits are, and copy the shas git cherry-pick <sha1> git cherry-pick <sha2> git push -f origin my-fix
Your colleagues will then have to delete their local branch and pull it down again.
I’m sure I’ll get some hate mail for suggesting force push as a viable option, so I’ll reiterate: don’t do this unless you know what you’re doing. Even if you do know what you’re doing, you’re playing with fire, as a developer at my company learned when he accidentally force-pushed to
origin master, which brought most of the engineering team to a halt while we figured out what got blown away and reconstructed master. (To git's credit, it is hard to do real irreversible damage; between the reflog and commits stored in your colleagues' repos, you can almost always recover. It just may take some time to sort things out.)
I should also note that it is possible to disable force-pushing on a per-repository basis (unfortunately not per-branch, AFAIK, but there are hoops you can jump through).Tweet
Excellent explanations of some complex math & programming topics. My favorite: An Interactive Guide To The Fourier Transform.
Amazing multimedia (that word is so 90s, but nothing more appropriate comes to mind) story of a fatal avalanche at Stevens Pass. Just look.
John Hammond was responsible for discovering and promoting some of the greatest musical talent of the 20th century: Benny Goodman, Count Basie, Billie Holiday, Pete Seeger, Aretha Franklin, George Benson, Leonard Cohen, Bob Dylan, Stevie Ray Vaughn, and Bruce Springsteen, among others. He was also responsible for introducing the world to the music of the great blues man Robert Johnson, who was the focus of the Radiolab piece.
On top of that, he was a civil rights pioneer, playing a large role in integrating the music industry.Tweet
Nice summary of issues with running MongoDB at scale.
Software engineering tools from Microsoft Research.
"Research strongly suggests that people are more creative when they enjoy privacy and freedom from interruption."
I fairly quickly found a bunch of annoyances in python that I carped about frequently. Can't resolve circular references? Ruby has no problem with that. Class and static methods tacked on via decorators? Those should be first-class concepts in any modern programming language. Not to mention that the python style of programming (and the circular reference issue) encouraged having multiple classes in a single file, or even files with bare, classless functions (i.e. modules). And what kind of crap is "
if __name__ == '__main__':"? Yeah, I did a lot of grumbling.
But a funny thing happened. I kept working with it, learned to do things the "python way," and most of these things turned out to be not such a big deal. I found a lot to like about python. The lack of extraneous characters for defining blocks (a.k.a. significant whitespace) was refreshing, and made for more readable code. It has a deep and well-documented standard library, and the quality of external libraries I've come across has generally been extraordinarily high. I had come to enjoy writing python.
When learning something new, the natural reaction is to compare it to what we already know. That's how the brain works, by making associations. The easy trap to fall into, however, is jumping to the conclusion that because it doesn't quite fit the patterns that you've learned–because it is different–it is inferior or broken. This is often compounded by the normal frustrations any beginner encounters, especially when you're in an environment where you're expected to hit the ground running.
I believe this is related to what Sigmund Freud termed the narcissism of small differences, the idea that people with relatively minor differences in viewpoint tend to be more combative than those with major differences.
Over time, as you learn and start to see more of the whole picture, those annoying differences become smaller and smaller, often disappearing entirely. In fact, you'll likely come to appreciate some of those differences.
It takes effort to fight those initial narcissistic tendencies. The next time you're thrown into a foreign environment, make a conscious effort to keep an open mind, and bite your tongue until you've given it some time. After you've mastered the subject, then you're entitled to bitch about it.Tweet
"To be the father of growing daughters is to understand something of what Yeats evokes with his imperishable phrase 'terrible beauty.' Nothing can make one so happily exhilarated or so frightened: it's a solid lesson in the limitations of self to realize that your heart is running around inside someone else's body. It also makes me quite astonishingly calm at the thought of death: I know whom I would die to protect and I also understand that nobody but a lugubrious serf can possibly wish for a father who never goes away."
– Christopher Hitchens, "Hitch-22"Tweet
A recent article by Mikeal Rogers about the Apache Software Foundation's outmoded idea of open source contributions struck a chord with me.
Some time ago I submitted a pull request to Flume, making a very minor change to get something to compile again after code reorganization had broken it. About a week later, I got a comment from one of Cloudera's engineers saying that the patch looked good, but that since they were in the process of moving to Apache Incubator, could I follow some extra steps. The extra steps (create an account on Cloudera's JIRA issue tracker, create an issue for the bug, generate a patch for my change and attach it to the issue) weren't terribly onerous, but considering I had already moved on (and in fact had decided not to use Flume for my project), and had real work to get done, I put it on the back burner and eventually forgot all about it.
The genius of git and GitHub is how easy it is to contribute to projects. Fork, fix, submit. I submit patches to projects all the damn time because barrier to contribution is so low. Like most developers, I've got a job that keeps me busy, and any roadblocks big enough to take me out of my flow are usually going to stop me.
Someone more patient than I submitted a "proper" patch for my Flume issue about a month later, so my conscience is clear. I hope, however, that the ASF eventually embraces the new open source reality. Their software will be better for it.Tweet
Interesting post from Andy Baio about tracking down an anonymous blogger via Google Analytics, and the trickiness of remaining anonymous in general.
In about 30 minutes of searching, using only Google and eWhois, I was able to discover the identities of seven of the anonymous or pseudonymous bloggers, and in two cases, their employers. One blog about Anonymous' hacking operations could easily be tracked to the founder's consulting firm, while another tracking Mexican cartels was tied to a second domain with the name and address of a San Diego man.
Reverse-engineering Siri's wire protocol.
Interesting approach, showcasing the power of open source machine learning and computer vision libraries.
Someday I'll write my own take on parenthood, and I hope it's half as good as Jeff Atwood's.
As an aside, as the parent of twins, that pie chart is still pretty accurate—only it's twice as big.
Proof-of-concept out of Georgia Tech using the iPhone 4's accelerometer as a keylogger.
This is a special collection of problems that were given to select applicants during oral entrance exams to the math department of Moscow State University. These problems were designed to prevent Jews and other undesirables from getting a passing grade. Among problems that were used by the department to blackball unwanted candidate students, these problems are distinguished by having a simple solution that is difficult to find. Using problems with a simple solution protected the administration from extra complaints and appeals. This collection therefore has mathematical as well as historical value.
Dart is a new web programming language from Google. See also the blog post introducing Dart.
“Market research is what you do when your product isn’t any good.”