Paul Stadig

Granted. I was thinking more of the questions lik...

2011-03-21T06:58:34.274-04:00

Granted. I was thinking more of the questions like, "what is intelligence?" and "what is mind?" but you are correct, "what is common sense?" is also a sticky problem.

I also didn't quite say "all" AI researchers have punted, but that "most" do, which is not incompatible with your assertion. :)

Not all AI researchers have punted on the big ques...

2011-03-20T01:32:30.271-04:00

Not all AI researchers have punted on the big questions. The project I have in mind is Cyc, which attempts to tackle the common sense problem.

Thanks for sharing your thoughts. I appreciate yo...

2011-02-17T09:31:01.848-05:00

Thanks for sharing your thoughts. I appreciate you sharing Linus' opinion on the subject, but his opinion is not binding.

I work daily on a project with 9 other developers where we have lots of topic branches and merges, and they don't "pollute" the repo, or if the do its an issue of personal taste. Preserving the history of particular lines of code is important.

There are different opinions on the topic of one large commit vs. lots of small commits. Personally I find it easier to digest commits when the are complete ideas, instead of half-thoughts, so I tend to fall on the side of largeish feature commits (as you do).

By the way, it is totally unnecessary to have a single commit per feature if you are doing it only to have an easy way to revert that work. You can do `git rebase -i -p -s subtree SHA` and it will allow you to remove a no fast-forward merge all at once, in other words, you don't have to remove every commit individually.

This is one of the benefits of doing merges vs rebasing. If you rebase your work into mine and we've moved on to other changes *then* it is impossibly messy to revert your work later. However, if you do a no fast-forward merge, I can easily come back later and remove your whole branch from the history in one fell swoop, if you're into that sort of thing.

This sounds to me as more of a Rant than anything....

2011-02-16T12:27:49.341-05:00

This sounds to me as more of a Rant than anything. Take it from Linus Torvalds himself. he told me to tell you that you are doing it wrong. http://lwn.net/Articles/328438/

I think when people rant about rebasing being bad it's because they've never been in a situation of more than 2-3 developers where erroneous merge commits and endless feature branches pollute the repo. I for one (along with Linus) am for the single commit per feature. It's EXTREMELY EASY to revert a single commit. A feature doesn't do what is expected in production? Great yank it out (git revert) keep moving along. Try unwinding a merge. Things get ugly.

My $0.02

Snuggs

Innovative-Studios.com

@chnicola It certainly seems uncontroversial to sa...

2010-12-08T05:37:16.340-05:00

@chnicola It certainly seems uncontroversial to say "don't rewrite public history", since even my critics agree with that. I did say this in the Epilogue.

However, there are things which even when done in private can make things harder for you, and others once you make it public.

For instance, rebasing a topic branch on a newer version of master. If there are lots of changes and conflicts, then it is certainly easier on yourself to just merge master in, instead of rebasing. That way you save yourself from the conflict flogging that git gives you for each commit that you are rebasing. Technically you could rebase because its not public, but the argument for merging the new master in is entirely practical and the argument for rebasing on the new master is entirely cosmetic.

Second, the last form of lying (retroactive commits), if done without verifying that those commits compile and/or pass tests can cause problems with `git bisect` and conflict resolution when those commits are made public later.

It is worth really stressing (which I missed in yo...

2010-12-08T01:50:35.890-05:00

It is worth really stressing (which I missed in your entire post) that lies only matter if you are sharing a repository. If you are working locally these are useful and sensible tools to use and work with.

>It does not undermine anything: you can do a p...

2010-12-07T22:04:40.038-05:00

>It does not undermine anything: you can do a partial commit (to the index), stash the rest of the changes while keeping the index.

>Then run the test suite to make sure that your (staged) commit is OK. Commit and repeat.

@sigi uhhhh...I think we agree. The behavior that I said undermined `git bisect` and the ability to verify conflict resolution by compiling and running tests is breaking things into commits *without* running the test suite for each commit.

If you are running tests on (or at least trying to compile) each commit, then cherry-pick and bisect are much more useful, and you can trust your conflict resolution a little more than not.

"I bemoaned choosing to commit individual fil...

2010-12-07T21:31:24.042-05:00

"I bemoaned choosing to commit individual files out of a bunch of changes because it undermines the ability to compile and test commits, which is useful (essential?)"

It does not undermine anything: you can do a partial commit (to the index), stash the rest of the changes while keeping the index.

Then run the test suite to make sure that your (staged) commit is OK. Commit and repeat.

The same goes when splitting commits after the fact ("lying"). One can always make sure that the test suite completes after every new commit made.

Of course this is impractical with a long running test suite, but then in this case so is committing frequently.

Some remarks on what eat-a-git said above: Hunk b...

2010-12-07T21:24:33.697-05:00

Some remarks on what eat-a-git said above:

Hunk based commits are supported by Git. I agree that they are useful for organizing your history. However, one must be disciplined about stashing before every commit ("git stash --keep-index") and running the test suite in order to make sure the partial commits are legit.

Otherwise one does break "git bisect", as the article correctly points out.

Fully agree on your second point.

Very nice article, worth thinking about.

@Mahmoud IMO, what one should do instead of rebasi...

2010-12-07T17:47:39.191-05:00

@Mahmoud IMO, what one should do instead of rebasing is just merge into your topic branch. You resolve all the conflicts at once, instead of having git repeatedly flog you with conflicts for each commit. And git can still easily tell you where commits came from and where they went.

@Jlouis I think this is kind what I was getting at with my talk about integration branches at the end.

@Douglas I agree, I think I did mention stashes as a way to set aside some changes to go make changes elsewhere.

@eat-a-git I don't think I ever said cherry-picking is a lie. Perhaps I implied it? Cherry-picking is useful, and having commits that compile and pass tests make cherry-picking much more pleasant.

I did not bemoan squashing because of their mud patch nature. I bemoaned them because they create new commits which destroys cool features of git. I bemoaned choosing to commit individual files out of a bunch of changes because it undermines the ability to compile and test commits, which is useful (essential?) in `git bisect` and in resolving conflicts.

And I guess I'm glad to know I have your seal-of-approval. Thanks, dude!

Point 1: Cherry-picking to produce commits is not...

2010-12-07T16:32:02.756-05:00

Point 1:

Cherry-picking to produce commits is not lying. It is organization. Darcs lets you do this for each hunk it encounters and it is an incredibly useful feature which allows to make very concise patches rather than balls of mud.

Previously you bemoaned balls of mud patches from squashing, but to have work uncommitted and then to choose which files you're committing at one time is not lying.

Point 2:

Really most of this lying could go away if there was better annotation and organization, allowing you to abstract what happened while still allowing users to dig down into the history.

The article is fine otherwise.

Re: retroactive commits: you can use git stash to ...

2010-12-07T14:45:49.765-05:00

Re: retroactive commits: you can use git stash to hide away bar while you prepare to commit foo. Much safer than committing blindly.

The trick is to have rules on certain branches whe...

2010-12-07T13:24:30.862-05:00

The trick is to have rules on certain branches where the contract is you wont lie.

On other branches, personal ones for instance, you can lie to yourself to a certain extent. Blindly rebasing your own branches to "keep them up to date" is bounds for trouble though.

Could you speak a little to what one _should_ do i...

2010-12-07T11:10:29.753-05:00

Could you speak a little to what one _should_ do if these options are to be avoided?

Have you tried to install vimclojure? Piss poor do...

2010-08-11T18:56:32.630-04:00

Have you tried to install vimclojure? Piss poor documentation, a wildly outdated "stable" version, and no indication of any kind from the developer that he's interested in future releases. I'd love to try clojure support in vim, but I'm not guru enough to get it to actually work in a reasonable and timely way.

Thank you for sharing!!! I was going crazy.

2010-07-26T13:38:26.837-04:00

Thank you for sharing!!! I was going crazy.

Hi -- I'm interested in any recent progress T...

2010-06-29T07:54:20.190-04:00

Hi --

I'm interested in any recent progress Terracotta + Clojure progress that you've made. Any news?

In your survey results post you said, "I thin...

2010-06-11T07:48:36.857-04:00

In your survey results post you said, "I think [Emacs] falls down badly on a number of counts related to usability, community/ecosystem, and interoperability. But, I'm not here to harsh on emacs (at the moment! :-))" and have also said we need an editor that "mere mortals can use," which seems to me to be a backhanded complement.

In response to those two point I'd just say that the only thing Emacs "falls down" on is doing things differently, and different isn't necessarily worse. Secondly, I'm certainly no ubergeek, which is an existence proof that "mere mortals" can use Emacs.

I did read the survey results, and I did not see the results saying that Emacs is "functionally" necessary for Clojure. I mentioned one of the themes I saw in the results in my post.

I did read your "ideal clojure environment" wiki page, and I saw that most of the things you mentioned Emacs already has.

I'm not trying to stand in your way. I think it is a worthwhile goal to try to improve the non-Emacs environments. I just don't see that it is necessary to always point out "flaws" in Emacs every time the topic is brought up. Though I think Emacs is the best editor available, if you get flack from Emacs users for trying to improve other editors, I will defend your right to do so.

Ouch. :-/ I'm quite certain I didn't bash...

2010-06-10T17:22:56.126-04:00

Ouch. :-/

I'm quite certain I didn't bash emacs in my survey results post. You're right that I said that existing non-emacs environments weren't sufficient, but I'd hope that, given my "ideal clojure environment" wiki page (http://muckandbrass.com/web/x/DoBZ), that the authors of those environments take my analysis of the survey results as constructive.

Second, did you look at the actual responses to the survey, and the comments made about development environments? Yes, people believe that emacs is *functionally* necessary to program in Clojure, and yes, they don't think that existing IDE plugins are cutting it.

Beyond that, there's not much to respond here. Check out that wiki page, where I say that (a) I've used emacs before, though not with happy results, and (b) I think the truly ideal environment may be something like dropping emacs' raw editing capabilities into a more approachable base such as Eclipse. I'm pretty sure I'm not suffering from the dreaded Flerb paradox -- just trying to help move the needle so that mere mortals can have their cake without experiencing the pain you describe in your adoption of emacs.

Perplexed,

- Chas

Alex, Thanks for the comment. Not sure I can do m...

2009-10-28T15:36:52.282-04:00

Alex,
Thanks for the comment. Not sure I can do much about the other posts, because this blog will always be a computer blog :)...it was the H1N1 post that is abnormal.

My intention isn't to dissuade people from getting the vaccine, and obviously my article wasn't a factor in your decision. Personally, I think we will get vaccinated, if we could ever get a hold of the vaccine, it's in such short supply.

Nor was I trying to say that it would be fun to get H1N1. My impression from the news media and elsewhere has confused me. I think the news had painted a more dire and deadly picture than is reality. They do love a sensational story!

I only wanted to clear things up for myself, and perhaps others.

Okay Paul, so I think this is the only post on her...

2009-10-28T15:22:22.750-04:00

Okay Paul, so I think this is the only post on here that I understood......too much computer talk!

I agree, there seems to be a lot of hype about the swine flu, but the families that I know that have had it have gotten pretty sick from it. They've all survived, and only one person has had to be hospitalized, but it's still not something we want to deal with. We opted to not get the regular and swine flu vaccines because we figure we're better off taking our chances with actually getting the viruses. Still not 100% certain if it was the right decision, but it was our decision nonetheless.

You saved my life..

2009-09-24T12:22:07.275-04:00

You saved my life..

Thank you for this post. It just saved my day.

2009-09-09T09:04:41.159-04:00

Thank you for this post. It just saved my day.

It's not as obvious as you might think -- I ma...

2009-07-10T21:34:08.119-04:00

It's not as obvious as you might think -- I made the same mistake. Back in the early days of of RSpec, all you had to require was 'spec' but now you need to require 'spec/autorun'. I kept wondering why when I ran metric_fu on itself the coverage was terrible (If you just require 'spec' the specs won't run automatically when you pass them to rcov) until I figured that out.

Omega, Thanks for your comment. I don't disag...

2009-07-05T07:55:53.305-04:00

Omega,
Thanks for your comment. I don't disagree. I would only suggest turning off accept headers when you are forced to support users with IE6 and every one of 6 different solutions have failed. BTW, if anyone has a better, more compatible solution, I'd be more than happy to hear it. (In my case, I'm developing an Intranet app with essentially a 100% IE6 user base. I'm a contractor and all of my clients are government users.)

I'll be glad when enough users upgrade that we can consider IE6 dead, but for now, it's not a perfect world, and we have to jump through all kinds of hoops to support every browser that we can.