81–90 of 133 posts
Earlier quoted context omitted.
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
I also appreciated that the site didn’t give me a popup asking me to sign up to its newsletter.
Earlier quoted context omitted.
Access to a well-established set of tools for operating on unstructured text (coreutils, grep, sed, awk, etc.).
That's not the benefit of text, just adoption. All these tools could've just as well grown to be popular with a proper format, and your point would be exactly the same
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
git's data model is incredibly powerful and flexible, but its UX is famously... interesting: https://stevelosh.com/blog/2013/04/git-koans/
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.
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!
git's data model is incredibly powerful and flexible, but its UX is famously... interesting: https://stevelosh.com/blog/2013/04/git-koans/
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).
Earlier quoted context omitted.
These are great
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?
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!
git's data model is incredibly powerful and flexible, but its UX is famously... interesting: https://stevelosh.com/blog/2013/04/git-koans/
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!
git's data model is incredibly powerful and flexible, but its UX is famously... interesting: https://stevelosh.com/blog/2013/04/git-koans/
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.
Earlier quoted context omitted.
[flagged]
That's still the default in my localhost, but I get a warning that it'll change.
The whole default branch name change was a terrible idea that caused many more problems than it solved—as was already pointed out at the time.
But if you're going to set a name anyway, may as well call it trunk, or dominatrix, depending upon today's silliness level.