4 ms·
Jesus christ Git's interface design is horrible. Master Coder: Hmm. We refer to changes by a long, totally non-human-parseable string of characters that nobo
by peterwwillis 10y ago
Jesus christ Git's interface design is horrible.
Master Coder: Hmm. We refer to changes by a long, totally non-human-parseable string of characters that nobody can memorize,
and when we abbreviate it, it doesn't work 100% of the time. What can we do about it?
Novice Apprentice: Well... how about we stop using a long totally non-human-parseable string of characters that no
human can can memorize just to briefly refer to specific changes in human-readable output?
MC: What?! HERESY. Making a human use a cryptographic hash to reference a single random logical reference point in a mass of
logical binary objects among millions of others is clearly the best way to go. We just need some quick fixes.
NA: But... you can't reference it via speech, it doesn't work reliably via text when abbreviated, and it gives absolutely no
context whatsoever as to what it is. What's the point of using a cumbersome, inhuman reference for something you
only need to talk about briefly through a computer interface?
MC: SILENCE FOOL! ME DESIGN GOOD. YOU MAKE CODE MASTER ANGRY.
NA: Err... but what if we just let the program rename the references temporarily to human-parseable short strings, and resolve
what they are in between logs and commits?
MC: I SAID SILENCE!! Just for that, i'm going to make you explain to a new user why we force people to regularly clean
our their repositories after doing complicated things with them, like merging.
- nickez 10y agoI disagree with you, I think the hash is a very good auto-generated unique identifier to every commit. What do you suggest to use instead? You do have the option to tag commits with human friendly names.
- exDM69 10y ago> Git is full of some of the worst design decisions in modern software history. It's also full of some of the best software design decisions. The internals of Git are simple and elegant and they work like a charm. There have been very little changes to the internal workings since the first commit of Git. I agree that the user interface is inconsistent, ugly and hard to grasp. But if you have a solid understanding of the internals, with the help of the git manpages it's pretty easy to achieve what you want. There's software that's intended to work like a black box, just poke around the user interface and you can get stuff done. Git is not one of those. You need to understand the internal model, accept that the UI sucks, embrace the manpages, quit whining and get shit done.
- peterwwillis 10y ago> I agree that the user interface is inconsistent, ugly and hard to grasp. But if you have a solid understanding of the internals, You should not have to understand the design of the modern combustion engine to operate a car. You shouldn't even have to understand bicycle geometry to ride a bike. It's a friggin tool! Why on earth would you want to have to become a master of the design of a tool to use it? The whole point of making a complicated tool is to make your life easier! No other revision control system is this complicated and annoying. And i'm not going to quit whining, it sucks and it's stupid and it doesn't have to be, and people keep worshipping it like it's this amazing invention like nobody's heard of a merkle tree before. It treats chunks of changed text like blobs, wow, nobody's done that before. Oh a collection of packed objects, how novel. By the way, the internals aren't that great either. You have to constantly "clean" your repository as it collects useless crap, merges become such a headache you're asked to destroy your merges to make it somewhat sane to maintain, handling "large" objects is a mystery to us, and the entire design is intended to interface with others and yet it's designed as if your personal repo were the only repo in the universe. You have to use a dozen filters and options and processes to do what a single script could do if it asked you what you wanted to get done, but we have to literally sacrifice a goat on the mountain of Unix Philosophy in order to get something done and go back to doing real work. Why does it force us to send these anonymous patches and not allow merges to happen intelligently among a group using locks? Why does it force a maintainer to do all the work of managing patches? Why does it waste local storage when we don't need 99% of the repository most of the time? Why can't log messages and status be rendered in a quasi-usable way, or, heaven forbid, we have a Curses frontend for the myriad of random chunks of text and commands we have to memorize to accomplish one small simple operation? Why does the repository fall apart into a completely unusable mess if you don't weed it once a day? Why do we have to shuffle around a bunch of commands to perform a single simple task that any reasonable program 15 years ago would have done for you? Answer: Because the design is crap. If people would at least just admit the design is crap, I would stop whining. But at this point I feel like i'm the only sane human in a world full of people doing the work for the robots and smiling about how much easier their lives are now.