Comment by mark_undoio | Hacker News Reader

Comment by mark_undoio | Hacker News Reader

Parent Full thread

This also reminds me there are different dimensions to taste.

A developer can have both excellent taste and skill in code and lack one or both in its user interface. For instance, I'd personally say git seems to be amazingly successful and robust but that the UX could be much more consistent without sacrificing any power.

I fully expect there are other dimensions to this too for other overlapping domains in software engineering. Something like E.g:

- testing - does the test code work? (skill), is it making the most of opportunities for coverage and self-documentation (taste? Or a different kind of skill?) - API design - can it do what's required? (skill), is it a sensible ABI too? (skill), can others understand it? (taste), is boilerplate minimal? (taste) - documentation - is it correct and complete (skill) and understandable? (taste) - code review - can you spot bugs and inconsistencies? (skill), are you giving feedback that allows incremental improvements without overwhelming? (taste)

I fully believe both skill and taste can be learned in all these areas but different thought processes will help in each.

git is very consistent! For example during rebase, cherry-pick or merge you solve conflicts the same way.

It has a single switch to force unchanging non-formatted output, to use in scripts, not one different per subcommand.

It was carefully designed, not just adding random flags.

At the same time it's a fractal of leaky abstractions.

Coming from the world of SVN I gotta say: git does a really good job of doing the right pieces well.

I don't know what will replace git. However I know they'll have a mountain to climb on to create something better.

I’m really happy with source control at Google (perforce on a huge monorepo?). My experience with GIT has always been trying to find dummy guides on how to do simple things.

Sometimes a good abstraction should leak. I hated Subversion and Perforce because both seemed like mystery boxes; I could use them but I never felt like I understood them. With git I've never had that feeling, if anything it's the opposite. Git is easier to understand than it is to use; the data model is simple enough to figure out in a few minutes, but learning the nuances of the various commands and flags takes a lot longer.

Leaky abstraction is not git's problem. Git's problem is shit like "checkout -b". Why does git-checkout have a flag to do what git-branch is for? Convenience of course, but this kind of shortcut makes git harder to learn initially.

> Git's problem is shit like "checkout -b".

That's why the added `git-switch` lately.

For the rest, I would agree. Git is at its core technically "simple". But the CLI UX is quite, let's call it, involved.

I think there are two primary reasons for that: Git is a very interactive tool. That just doesn't go well with a UI which is fundamentally a line printer.

OTOH Git is very powerful. Most GUIs (or TUIs) can't "handle" this well, imho.

Git is "feature overkill". On the command line this doesn't matter much as you never see all features and options at once—besides of course that nobody can remember all those switches. ;-)

But when creating GUIs, which are better in the interactivity dimension, this becomes a real hurdle. Basically you have only the options to hide things and dumb-down your tool or end up with a overloaded and therefore quite complex GUI. Really hard to strike a balance.

The best I've seen so far regarding Git GUIs was Sublime Merge. It also hides much things at first sight but manages to not lock away Git's power by doing so. A lot of features are contextual. Also you have an "intelligent" command palette at your disposal. This matches nicely with the interactivity of Git! Also the GUI is strongly inspired by the look & feel of Git's command line output.

Sublime Merge feels for those reasons in large parts like if the command line tool would be "projected" into a GUI (which is convenient as the CLI output is already quite optimized to see everything relevant quickly), but given the GUI one does not need to remember the awkward command line flags.

Git on the command line should be more like that I guess. At least a kind of build-in REPL would be good as Git is interactive not "batchy".

I know there is a "git-repl", but it's not really what I imagine. It's not really context sensitive or interactive.

"Magit" looks good from far away, or at least heading in the right direction, but it only runs under EMACS.

If there would be something like Sublime Merge for the command line (and maybe even available OOTB) this could solve quite some of Git's usability problems I think.

I agree, git made more sense to me after 6 months than svn did in the 5 years prior. The whole conflation of directories, branches and tags made svn an irredeemable monstrosity.

>For example during rebase, cherry-pick or merge you solve conflicts the same way.

.....with rm -rf /path/to/repository && git co https://repository, the same as you solve any other problems with git.

That, or spend 10 minutes learning how to solve conflicts instead of losing data…

Reply on news.ycombinator.com