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!
Remembering app-specific one-offs is kind of the worst!
Especially because the text is actually written by a human, and it's clear from every sentence
no idea where I saw that though and it was many many years ago.
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.
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.
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.
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.
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).
git -h branch
git branch --help
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.
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.
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.
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.
> 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.
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.
For example:
git log mybranch myfile.txt
git show mybranch:myfile.txt
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.
Now we can all run important CLI programs like Zork without a 'command doesn't exist' to command ratio of 1:4