1. 0

    This article is from an alternate universe where the concept of MVC doesn’t exist.

    1. 2

      It does reference model-view-data.

    1. 4

      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.

      1. 8

        I’ve never used an IDE to interface with git. What am I missing?

        1. 5

          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.

          1. 5

            for me, diff looks better. Nothing else.

            1. 1

              For starters, being able to selectively stage changes in a file. Unless you count git add -p as equivalent.

            2. 4

              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.

              1. 4

                I can see that. But everybody should just be using magit in emacs, which makes the problem go away.

                1. 6

                  you do realize not everyone is using emacs, right/

                  1. 5

                    Ah, but they should be.

              2. 2

                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?

                1. 5

                  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.

                  1. 1

                    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?

                    1. 1

                      Probably git format-patch.

              1. 4

                As cool as this is, “Model B+” is a poor name. It should be “Model C”.

                1. 5

                  The naming is a nod to the BBC Micro series of personal computers: https://en.wikipedia.org/wiki/BBC_Micro#Description

                  1. 2

                    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.

                    1. 2

                      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.

                    2. 2

                      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.

                    1. 1

                      “13% of the total, had at least one serious, easily exploitable vulnerability. That’s every 10th project, guys.”

                      Or, more accurately, every 8th project.

                      1. 2

                        Or, more accurately, every 8th project.

                        Or, more precisely, more precisely.

                        ;)