Marnen Laibow-Koser

@onlynone The latter approach is mostly the way I use Git. Although I do very occasionally rebase topic branches, I'd normally much rather have an extra merge commit than a false history.

In a Node environment, why would you use make instead of grunt?

There's no reason to do this. If you don't want field_with_errors styled specially, just ignore it. If the extra <div> elements break your layout, just put something like the following in your CSS: .field_with_errors { display: inline }.

I'd be very skeptical about this recommendation. Among other things, there's no guarantee that every browser implements its CSS parser in the same way, despite what the quotation implies. I wouldn't put any faith in this rule unless I saw some good benchmarks across browsers.

This is a terrible, horrible, awful idea, because it flies straight in the face of semantic HTML. In the HTML/CSS/JS ecosystem, behavior and appearance are both part of the nature of an object. It is perfectly reasonable to say "this DOM object represents a book title. Display it with italic text and a gray background, and when it is hovered over, pop up an image of the book cover". There is no reason to divide this information between classes book and js-book; rather, both the CSS and the JS should refer to class book. That way, the markup can just have the one book class and not have to know anything about whether it's dispatching to CSS, JS or neither.

A worse side effect of the js- prefix is that it prevents "happy collisions", where a class name meant for one domain becomes useful in another. Let's continue the previous example. Suppose that, differently from what I stated above, <div class='book'> only displayed the italics on the gray background (that is, it was only used for CSS). Along comes the JS developer, and knows that he wants to add the cover popup to every item of class book. He should just be able to write something like $('.book').on('mouseover', addPopup), thus making what was previously a CSS-only class useful for behavior. However, the practice of putting js- on classes meant for JS would mean that an extra -- and completely redundant -- class would have to be added to all book items. This benefits nothing, and should be avoided.

If you think you need js- on your classes, you're probably not testing enough.

The problem isn't pull, it's rebase. Just don't use rebase (or git pull --rebase) and you'll be fine. Rebasing changes history, and the point of a VCS is to maintain history. If you use rebase, you'll need version control for your VCS—that is, Git won't maintain an unaltered record of what came before, which means it's no longer a proper VCS. Rebase looks like it works, but is an accident waiting to happen. Banish it from your Git vocabulary.

Note that this is occasionally necessary, but rarely a good idea. It's important in most cases for your VCS to track your file permissions correctly, so that your repository can function properly.