This is all reasonable, although I dislike the bit about hard-wrapping at 72 columns. The author is 100% dead wrong about the command line interface, however – git’s is terrible, requiring IDE support for even the most trivial of tasks. I’m an old UNIX greybeard (albeit a self-hating one) and every time I have to use the git cli I weep angry tears of blood. Of course, there’s always magit to ease the burden.
I use SourceTree, although I’ve heard good things about Tower. One of the main reasons I use it is for staging selected lines and hunks. You can technically do the same with the cli, but it’d take a prohibitive number of commands instead of one click, and even more commands to know if you did it right. Plus, I sometimes start to write a commit message, and then realize that there are files I should add or remove from that commit. That is easy with an IDE, very difficult with the CLI.
Also, always being able to see a visual display of the branches is helpful, and I know when others have pushed to other branches without having to manually check.
For starters, being able to selectively stage changes in a file. Unless you count git add -p as equivalent.
Hard-wrapping at 72 columns is nice for command-line interfaces like
tig. There’s also some code review tools
that mail git diffs; they are much easier to read with hard-wrapping.
I can see that. But everybody should just be using magit in emacs, which makes the problem go away.
requiring IDE support for even the most trivial of tasks
I don’t think git has any more difficult of a cli for trivial tasks than most other cli tools (where “trivial tasks” are push, pull, merge, rebase, add, commit, etc).
What specific things do you find IDE support necessary / extra helpful for?
Interactive rebasing. Generating patches. Visualizing the commit history, particularly with branches. Shit, even switching to local copies of remote branches is weirdly magic. Perhaps I simply don’t understand it well enough, but it certainly doesn’t seem to have a consistent, orthogonal set of functions that can be usefully composed; it just feels like somebody else’s mental model expressed without intermediation.
I still find it super useful, of course, but that doesn’t mean I think it’s good.
Oh, yeah, I use gitk for visualizing the commit history. I’m reasonably comfortable with interactive rebasing but I’m always afraid I’ll merge a commit with the wrong thing.
What do you mean by “generating patches”? git diff?
The naming is a nod to the BBC Micro series of personal computers: https://en.wikipedia.org/wiki/BBC_Micro#Description
I think B+ was the right choice since it is a minor improvement on the Model B rather than a model that is differentiated by new features and updated technology.
I would agree, except that the major difference between the A and B was the amount of RAM and the addition of an Ethernet port.
Agreed. Cables, cases, and memory sticks are not compatible, which covers most of what relates to compatibility. RAM is pretty much the only upgrade that I’d think warrants just a ‘+’ modifier, and that was the difference between A and B.
“13% of the total, had at least one serious, easily exploitable vulnerability. That’s every 10th project, guys.”
Or, more accurately, every 8th project.
This article is from an alternate universe where the concept of MVC doesn’t exist.
It does reference model-view-data.