5 ms·
Does anyone know why git broke the long standing convention of "--" early on? Kind of a nightmare for humans to use. Remembering app-specific one-offs is kind
by metadat 2mo ago
Does anyone know why git broke the long standing convention of "--" early on? Kind of a nightmare for humans to use.
Remembering app-specific one-offs is kind of the worst!
- doctoboggan 2mo agogit's data model is incredibly powerful and flexible, but its UX is famously... interesting: https://stevelosh.com/blog/2013/04/git-koans/ https://stevelosh.com/blog/2013/04/git-koans/
- peheje 2mo agoThese are great
- andy99 2mo agoI don’t understand any of them. Normally even when I’m not really familiar with a tool, I have enough background knowledge to understand why it’s funny e.g. Scheme and Haskell jokes or something. I do use basic git regularly and all of this is over my head. I don’t know if that speaks to how complicated and unintuitive some of the advanced stuff is?
- jibal 2mo agoThe context here is the statement that "its UX is famously... interesting". You don't have to understand anything other than how wildly inconsistent the git CLI is.
- xigoi 2mo agoThe second one is about how Git uses the word “checkout” for three unrelated operations, violating the Unix philosophy.
- ffsm8 2mo agoIt's always such a good experience to read well written articles like this from the early 2010s when our industry was a lot less self-important Especially because the text is actually written by a human, and it's clear from every sentence
- Bugg4 2mo agoThe hobgoblin one sent me
- pydry 2mo agoiirc Linus actually conceded this very early on and said that he thought it would be better if it were used as infrastructure to build tools on rather than the tool itself. no idea where I saw that though and it was many many years ago.
- edelbitter 2mo agoIn any case, the refined version of that admission - the deliberate porcelain/plumbing distinction - is still best explained in the git docs and I wish more tools would copy it. apt(-get) has cautiously started that process, while GnuPG sadly remains a box shock full of surprises in both API and CLI.
- inigyou 2mo agoI think at that point he only had the plumbing commands. Commands like "git commit" are the tools he meant.
- mhh__ 2mo agoThis is actually kind of happening! (In a way) There are, at this point, quite a few git-successors that either basically or literally use gits object model - git-butler, jujutsu, sapling (iirc). It's at worst good-enough.
- ulrikrasmussen 2mo agoI use git every day and can do quite advanced stuff with it, but I do all of my work using magit in emacs. I don't even use emacs for writing code anymore, I only use it for git. I just can't be bothered with using the CLI, it is too painfully inconsistent. The only downside to this is that it is hard for me to help people with git problems since I can only tell them what conceptually has to be done, not how to accomplish it using the CLI.
- IshKebab 2mo agoWhen beginners need help with Git and they're using the CLI the first and best advice I give them is to stop using the CLI.
- sigseg1v 2mo agoThis is interesting to me because when beginners come to me for help with git and they're using a GUI, the first thing I do is tell them to ditch it and learn the CLI.
- IshKebab 2mo agoHasn't been my experience at all, but also why would you do that? The CLI has an awful confusing UX and also doesn't easily show you the state of things. If you're trying to teach a child how filesystems work, do you open a terminal and teach them `ls` and `cd`? No of course not. You use some kind of GUI file manager with a tree view.
- dns_snek 2mo agogit CLI and various GUIs are awful in different ways. CLI is awfully inconsistent and hard to learn, but GUIs obfuscate what's happening behind the scenes and make it harder to recover from mistakes.
- IshKebab 2mo ago> but GUIs obfuscate what's happening behind the scenes and make it harder to recover from mistakes. I disagree. "What's happening behind the scenes" is not the corresponding CLI command - it's the actual modification to the commit graph, and GUIs are much better at exposing what is happening. Think about something like a rebase. Find any article explaining Git rebase. It will have diagrams showing what happens to the commits and those diagrams are exactly what a Git GUI displays! To follow my filesystem analogy, when you move a file, the thing that's happening behind the scenes is that the file is moved, not `mv A B`. > make it harder to recover from mistakes. Also disagree. I'm not sure what you're talking about exactly but assuming reflog, then most GUIs don't support that and you're going to have to use the CLI in either case. But "GUIs don't cover this rare feature" isn't a reason to ditch them completely. I agree there are a lot of awful GUIs though. It doesn't help that the Git website lists dozens of them and only 2 or 3 are any good. My recommendation: if you use VSCode, the Git Graph extension. If you want a standalone tools, SourceGit or maybe GitX if you're on Mac.
- inigyou 2mo agoTortoiseGit was very cool, and nothing stops us making more alternative UXes. I miss the extensibility of Windows, back when programs still fought for the users (Tron reference). Shell extensions, COM/OLE, ActiveX controls. Sure they were annoying but they actually did stuff that we just can't do any more. Even start menu folders with more than one entry. It was like each thing you installed could be a plugin for your whole computer, not just an isolated space where you visit sometimes (the iOS model).
- inigyou 2mo ago[flagged]
- freehorse 2mo agoI puzzled over the "The Long and Short of It" as for me (git version 2.54.0) git -h branch gives the same output as git branch --help so I could not understand why master git jumped and died. But it seems that in older versions it threw an argument error according to the old discussion [0]. I see that `git -h branch`, `git branch --help` and `git --help branch` give the long output but `git branch -h` gives the short. I suspect that `git [-h | --help] branch` is converted to `git help branch` which runs `help` with argument `branch`. But `git branch -h` runs `branch` with argument `-h`. Also as `git -h alias` prints the alias definition while `git alias -h` gives the short help for the aliased command. [0] https://news.ycombinator.com/item?id=5512103 https://news.ycombinator.com/item?id=5512103
- p-e-w 2mo agoWhen something appears to be poorly designed, then the deeper explanation is often that it’s indeed poorly designed.
- epistasis 2mo agoSince it separates out the pathspec, doesn't that match the long standing convention?
- jibal 2mo agoThe convention is that a leading `-` isn't recognized as a flag after `--`.
- epistasis 2mo agoYes, doesn't that match git's behavior? Or are you saying that's not the case?
- jibal 2mo agoWhy would `--end-of-options` be needed if `--` always signals the end of options? Please read the article.
- epistasis 2mo agoPlease do not rudely assume I have not read the article. Let me show you what the article says: > But that doesn’t work for the revision parser, because -- is already meaningful there: it separates revisions from pathspecs. So we need some other marker to separate options from revisions. In git, `--` specifies where the options end and the files begin, just as it does for `rm` and other unix conventions. Just exactly as you said, `-` is not recognized as an option after `--`. So git is following the Unix convention, both as you have described the convention, and as I understand the convention.
- jibal 2mo agoIt wasn't rude to think that this person might not have read the article, when what they write doesn't account for what the article says. What's rude is to not answer the question: "Why would --end-of-options be needed if -- always signals the end of options?" and to instead just repeat the claim that git is following the UNIX convention when it clearly does not, as their own quotes says: "that doesn’t work for the revision parser, because -- is already meaningful there: it separates revisions from pathspecs. So we need some other marker to separate options from revisions." i.e., `--` is used as a separator, not as a signal that no further leading `-` is significant.
- TZubiri 2mo agoOne of the undeniable benefits of LLMs is that the end of guessing and remembering commands is now optional. Now we can all run important CLI programs like Zork without a 'command doesn't exist' to command ratio of 1:4
- userbinator 2mo agoThe Single UNIX Specification mentions the "--" convention in 1997 (at which point it was already in widespread use): https://pubs.opengroup.org/onlinepubs/7908799/xbd/utilconv.html#tag_009_002 https://pubs.opengroup.org/onlinepubs/7908799/xbd/utilconv.h... The first release of git was in 2005, and Torvalds' Linux was clearly UNIX-inspired, so it's not like this was due to considerations for some other OS like DOS/Windows.
- vips7L 2mo agoFlags for Unix tools have never been friendly.
- VBprogrammer 2mo agoFind is a great example. It's such a useful and powerful tool but it's arguments get me on a regular basis.
- dmurray 2mo agoIt sounds like they didn't need (at the time) to separate arguments from options, but they did need to separate revisions from pathspecs. So they repurposed "--" as the most familiar separator. Probably they were trying to use familiar conventions, but when they later needed to separate arguments from options, that was a closer match for what other people were using "--" for, but it was too late.
- stingraycharles 2mo agoSo basically don’t break conventions by repurposing existing operators for something else. It’s silly as git is otherwise a very elegantly designed application, and you’d expect it to be developed by people who are very accustomed to these conventions.
- zoky 2mo agoAs a primarily FreeBSD user who feels like I have to relearn the idiosyncrasies of practically the entire system every I install a new Linux distro, the mess of configuration options somehow actually seems entirely on-brand to me.
- xorcist 2mo agoIt's a bit of a mystery, especially since the one of the lowest surprise character they could have chosen was a colon, and indeed colon is already used to separate branch and path -- but only where they are one option and not two. For example: git log mybranch myfile.txt but: git show mybranch:myfile.txt That's indeed one of the things that trip up people when I try to introduce them to the git model. I wish it had been different. The double dash is normally not needed when it is self evident if a branch or file is referred to. It is only needed when a file no longer exists or a file and a branch exists with the same name. One could easily have imagined the one-argument syntax to be dominant. It would have been a bit awkward in a few situations, but a lot less confusing in others.