1. 41
  1.  

  2. 31

    This post has everything

    1. Opinionated UX decisions
    2. Publicly trashing a main project maintainer for something happened 10+ years ago
    3. PS we’re hiring
    4. yet another git wrapper that pretends to be easier to use based on 1.
    1. 19

      I don’t think he’s trashing him. He says, “I would have done the same thing”. He’s just trying to figure out what happened. More git annotate than git blame (hey, by the way, why does git not have that alias? svn also has svn praise as another alias in this family.)

      Furthermore, the proliferation of git wrappers says something. Mercurial has a lot of users too (Facebook), and guess what, they don’t write wrappers for it. They do write aliases and extensions, using hg’s established customisation mechanisms, but they don’t feel like the entire UI is so terrible that it has to be completely replaced by a different UI. There’s a reason for this – we spend a lot of time thinking in hg about how to make things consistent with itself (in our defense, a lot of the modifications that Facebook does is to make hg more consistent with git). Every time a new feature comes in a lot of time is spent naming that feature, seeing what options it should take, seeing what other similar or related features already exist and what options they use. It’s not a perfect process, and there are some small historical mistakes, but at least we have a process.

      1. 1

        And those of us who use Hg thank you greatly for that process.

      2. 3

        Has anyone made a Git equivalent of https://craphound.com/spamsolutions.txt ?

        1. -5

          I stopped taking the author seriously after they mentioned git’s “user experience”. Git is a tool. It is not there to be pretty or give you a good experience - it’s there to get the job done.

          1. 20

            Why does being “a tool” give it carte blanche to have bad UX? In fields outside of software tool ergonomics is a serious topic.

            1. 9

              In the tools I maintain at least, user experience is pretty far up there with one of the most important things to optimize for. (Among other things, like ease of maintenance.)

              1. 6

                tools are where i most want a good user experience! that extends to the physical realm too; the experience of using a tool that is well-made, sturdy and fits well into your hand is an order of magnitude better than using a shoddy one, even if the latter gets the job done too.

                1. 3

                  This effect is greatly magnified if you use the tool for a long time.

                  Using a weirdly shaped hammer for 5 minutes is annoying. Using it for 8 hours is unbearable.

                  Same with digital tools.

                2. 5

                  This is a pretty lame response. Certainly things that get jobs done can have a decent UX. Or at least not a ridiculously confusing one.

                  1. 2

                    Bad UX gets in the way of using the tool effectively, it is directly related to getting the job done.

                    With that said, git gets a lot of bad-rap for having a learning curve, but having a learning curve is not bad UX. Git is the damn good DVCS.

                3. 9

                  There are always two perspectives on a system….

                  …the implementers and the users.

                  Often they coincide in the sense if the user has closely related concepts X and X’, the implementation of X and X’ overlap.

                  Sadly, what is happening in these cases, the user has strongly differing concepts X and Z… but the implementation detail is such that the implementation for X shares a lot with the implementation for Z.

                  Thus the implementation perspective is X and Z are (almost) the same thing, make them the same command.

                  The user’s perspective the choice is, WTF!?

                  Equally it can happen that the users concepts of Y and Y’ appear closely related….and would expect Y’ just to be a switch on Y….. but find under the hood the implementations are wildly different.

                  Thus the implementer may have chosen to given them completely different commands and names. Again, the user goes WTF!?

                  As an implementer I understand this view… but try to be conscious of it and present the users view only.

                  An excellent way of gaining “A Users View” is write the documentation first.

                  Not Test First, but Document First.

                  If a concept is hard to explain…. your users is going to find it hard to understand and use. So documenting first forces your to pare it down, simplify it to it’s basics.

                  So now you have the core concepts from the users perspective…. Start thinking in terms of inverses. ie. Do and Undo, forward and back, ….

                  ie. If the user of your system knows how to do X, she never needs to look at the doc or help to know how to undo X.. it’s consistent across the system for all X.

                  When ever I work with a DB, the first thing I create is a data dictionary.

                  A list of field names and types and meanings.

                  Every use of a field name in my sql has the same type and meaning across my code.

                  Same with options… create a table of options for all commands….

                  Every option must have the same abbreviation, long form and meaning across all commands. NEVER overload them.

                  1. 2

                    Excellent distinction. Like many things, I think being able to use git effectively relies on having a good conceptual framework for the tool. Unfortunately for git, that means you kind of need to know all about how it works internally (i.e. be able to put yourself in the implementer mindset) while “better” tools allow you to have a simpler or more easily-explained mental model (i.e. maintain a user mindset).

                  2. 7

                    At least this better explains my visceral hatred of git and using it. 3 commands into it in my new job and I had nearly everyone totally befuddled. Blech. Just what the hell is a “detached head” anyway?

                    1. 29

                      You may enjoy these: http://stevelosh.com/blog/2013/04/git-koans/

                      A novice was learning at the feet of Master Git. At the end of the lesson he looked through his notes and said, “Master, I have a few questions. May I ask them?”

                      Master Git nodded.

                      “How can I view a list of all tags?”

                      “git tag”, replied Master Git.

                      “How can I view a list of all remotes?”

                      “git remote -v”, replied Master Git.

                      “How can I view a list of all branches?”

                      “git branch -a”, replied Master Git.

                      “And how can I view the current branch?”

                      “git rev-parse –abbrev-ref HEAD”, replied Master Git.

                      “How can I delete a remote?”

                      “git remote rm”, replied Master Git.

                      “And how can I delete a branch?”

                      “git branch -d”, replied Master Git.

                      The novice thought for a few moments, then asked: “Surely some of these could be made more consistent, so as to be easier to remember in the heat of coding?”

                      Master Git snapped his fingers. A hobgoblin entered the room and ate the novice alive. In the afterlife, the novice was enlightened.

                      1. 0

                        This was very enlightening indeed.

                        1. 0

                          Why did they even make it like this…

                        2. 3

                          In git changes need to have a ref pointing at them. A ref is a just a pointer to a commit. Branches, in git, are just a pointer to the tipmost commit in the chain of commits going back to to the main line of development. If you create a commit and there isn’t a ref pointing at that commit, that might be bad because git has a garbage collector that will delete these commits after a while.

                          So, being in “detached head state” just means you have a commit checked out that doesn’t have a ref pointing at. If you really want to start a new line of development there, you should create a new branch.

                          1. 2

                            I’m with you - after years of using Git I still find it absurdly complex and counter-intuitive. Very few engineers I’ve worked with (and I’ve worked with some really good ones) haven’t publicly struggled with it at some point. The worst part is that you really can’t just learn it as you go; if you don’t truly understand the fundamentals they eventually you’re going to do things that cause your colleagues (or just yourself) a lot of confusion and frustration. For something so common to modern development it’s unbelievably unfriendly.