| ▲ | metadat 7 hours 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 6 hours ago | parent | next [-] |
| git's data model is incredibly powerful and flexible, but its UX is famously... interesting: https://stevelosh.com/blog/2013/04/git-koans/ |
| |
| ▲ | freehorse 6 minutes ago | parent | next [-] | | I 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 the former (eg `git -h branch`) are 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 | |
| ▲ | inigyou 7 minutes ago | parent | prev | next [-] | | I don't fully agree with the checkout one. We do speak of checking out a file and checking out a branch using the same word, and they are not the same thing. checkout -b however makes no sense. It should be the default behavior of git branch. It was probably put under checkout because it made for more straightforward code. | |
| ▲ | inigyou 12 minutes ago | parent | prev | next [-] | | TortoiseGit 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). | |
| ▲ | ffsm8 4 hours ago | parent | prev | next [-] | | It'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 | | |
| ▲ | dc3k 3 hours ago | parent [-] | | I also appreciated that the site didn’t give me a popup asking me to sign up to its newsletter. | | |
| ▲ | lukan 41 minutes ago | parent [-] | | I did not appreciate reading with a mobile, though. Text did not fit the screen, but FF reader mode fixed it. |
|
| |
| ▲ | ulrikrasmussen an hour ago | parent | prev | next [-] | | I 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. | |
| ▲ | Bugg4 3 hours ago | parent | prev | next [-] | | The hobgoblin one sent me | |
| ▲ | peheje 4 hours ago | parent | prev | next [-] | | These are great | | |
| ▲ | andy99 3 hours ago | parent [-] | | I 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? | | |
| ▲ | xigoi 7 minutes ago | parent | next [-] | | The second one is about how Git uses the word “checkout” for three unrelated operations, violating the Unix philosophy. | |
| ▲ | jibal 3 hours ago | parent | prev [-] | | The 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. |
|
| |
| ▲ | pydry 2 hours ago | parent | prev [-] | | iirc 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. | | |
| ▲ | inigyou 13 minutes ago | parent | next [-] | | I think at that point he only had the plumbing commands. Commands like "git commit" are the tools he meant. | |
| ▲ | edelbitter 2 hours ago | parent | prev [-] | | In 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. |
|
|
|
| ▲ | userbinator 5 hours ago | parent | prev | next [-] |
| The 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.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. |
| |
|
| ▲ | dmurray 4 hours ago | parent | prev | next [-] |
| It 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 3 hours ago | parent [-] | | So 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 32 minutes ago | parent [-] | | As 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. |
|
|
|
| ▲ | epistasis 6 hours ago | parent | prev | next [-] |
| Since it separates out the pathspec, doesn't that match the long standing convention? |
| |
| ▲ | jibal 3 hours ago | parent [-] | | The convention is that a leading `-` isn't recognized as a flag after `--`. |
|
|
| ▲ | p-e-w 6 hours ago | parent | prev | next [-] |
| When something appears to be poorly designed, then the deeper explanation is often that it’s indeed poorly designed. |
|
| ▲ | vips7L 4 hours ago | parent | prev | next [-] |
| Flags for Unix tools have never been friendly. |
| |
| ▲ | VBprogrammer 2 hours ago | parent [-] | | Find is a great example. It's such a useful and powerful tool but it's arguments get me on a regular basis. |
|
|
| ▲ | TZubiri 5 hours ago | parent | prev [-] |
| One 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 |
| |
