Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

git's –end-of-options Flag

nesbitt.io

Post reply on HN
Print view View original

101–110 of 133 posts

Re: git's –end-of-options Flag

#101

Post by seletskiy »

eviks wrote: post #70
majewsky wrote: post #69

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

Master Git and a novice were walking to the market to collect alms.

The novice asked: "Master, what is the advantage of unstructured text over structured? Is it not mere adoption?"

Master Git said nothing and pointed to the first shop, kept by the old scrooge Postgre.

As they entered, Master Git said quietly, shaping his mouth funnily:

  SELECT weight/2 FROM shelf WHERE name = ''
Postgre, long weary of Master's wisdoms, took a weight of three from the nameless shelf and cut it unevenly. The whole piece he pressed into the novice's bowl; the larger part, he kept for himself.

Next stood a shop kept by a bright newcomer, Duck D'Bee.

Master Git repeated:

  SELECT weight/2 FROM shelf WHERE name = ''
Duck D'Bee smiled, carefully took an unnamed jar from a vertical stack and handed over one piece and half of another.

Their journey ended at a giant abandoned building beneath a dead neon sign: ORCL. The door stood open. Inside, putrid odour and dust lay upon deflated balloons and faded banners saying A.I. The shelves were still full of unmarked boxes.

Master Git shouted into the dark:

  SELECT weight/2 FROM shelf WHERE name = ''
Silence was the reply. At this point the novice became enlightened.

Re: git's –end-of-options Flag

#102

Post by mhh__ »

pydry wrote: post #67
doctoboggan wrote: post #4

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.

This 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.

Re: git's –end-of-options Flag

#103

Post by [deleted] »

eviks wrote: post #70
majewsky wrote: post #69

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

[deleted]

Re: git's –end-of-options Flag

#104

Post by eviks »

zahlman wrote: post #96
eviks wrote: post #57

Earlier quoted context omitted.

What are the advantages over structured text?

Long-term compatibility and the avoidance of vendor lock-in.

How can text enable compabitility if you can't be certain how to parse it, and the rules can change any time??? Similarly with vendors - how can they lock you into themselves if you use some widespread open format?

Re: git's –end-of-options Flag

#105

Post by zahlman »

eviks wrote: post #104
zahlman wrote: post #96

Earlier quoted context omitted.

Long-term compatibility and the avoidance of vendor lock-in.

How can text enable compabitility if you can't be certain how to parse it, and the rules can change any time??? Similarly with vendors - how can they lock you into themselves if you use some widespread open format?

The point is that every byte of it still means something to you even if you can't "parse" it.

Re: git's –end-of-options Flag

#106

Post by eviks »

throw0101d wrote: post #93
eviks wrote: post #70

Earlier quoted context omitted.

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

> All these tools could've just as well grown to be popular with a proper format, and your point would be exactly the same And what would this "proper format" be? Currently JSON is in vogue (or JSON5, which allows comments?), but a few years ago it would have been XML, before that… CSV? TSV? Or perhaps do a Choose Your Own Adventure: * https://libxo.readthedocs.io/ The Unix-y world has been around for decades, so it…

Yes, the lack of good design in that world is apparent and will continue to cripple a few more generations (but re. evolution that's often a false reading - in many cases it's some primitive napkin design made at the beginning of those decades that stuck without much evolution), but you've wandered into the wrong thread - it's not about the single best format that could've been, just about a circular logic flaw in the argument

Re: git's –end-of-options Flag

#107

Post by sigseg1v »

IshKebab wrote: post #95
ulrikrasmussen wrote: post #80

Earlier quoted context omitted.

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 accom…

When 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.

This 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.

Re: git's –end-of-options Flag

#108

Post by eviks »

inigyou wrote: post #92
eviks wrote: post #55

Earlier quoted context omitted.

> why does someone have a filename beginning with a dash? Maybe don't do tha Oh, the famous "you're holding it wrong". For one, that's a ridiculous limitation to place on the user, that's a pretty basic symbol, but also imagine someone else did that and you can't change it because it's outside of your control

It's a problem with mixing code and data, therefore needing to escape. You can solve it by adding another symbol, let's call it Options Introducer, but that doesn't actually solve it because someone can name a file starting with Options Introducer. GUIs don't have this problem because you are clearly typing in the textbox or outside of it, or even better, you can select the file you mean.

You could use an illegal file name symbol as the Options Introducer?

Re: git's –end-of-options Flag

#109

Post by Izkata »

dasyatidprime wrote: post #31
ButlerianJihad wrote: post #26

Earlier quoted context omitted.

Okay, edit submitted, but that is extra weird , because the double hyphen is a convention or placeholder for an emdash . When a transformation takes place, it becomes an emdash. There is no reason to transform it to an endash. I don't know any software that would do that. Checked with an LLM, too. That makes no sense at all!

TeX uses -- (double hyphen) for producing an en dash and --- (triple hyphen) for an em dash, and that's pretty darn longstanding and well-established. And FWIW, the English writing conventions that I learned use em dashes as punctuation without an adjoining space—like this—but allow en dashes surrounded by spaces as an alternative – like this – so I frequently see spaced double hyphen used as the ASCII equivalent of…

LibreOffice is the same, double hyphen is en-dash and to get an em-dash you have to type:

  :---:
I thought this was part of why it became an LLM signifier, most people can't tell the difference between the two visually and as far as I knew en-dash is what you usually get by accident, while LLMs use em-dash.

Re: git's –end-of-options Flag

#110

Post by Gormo »

bombcar wrote: post #78

This is actually one of the few places powershell begins to do something close to shine - the cli mixes data and commands in a way that we really shouldn't have to do. The saddest thing is even ASCII has characters to help with this but since keyboards can't type them nobody used them.

If keyboards did have keys for ASCII delimiters, people would start using them for a variety of purposes, and they'd start showing up in data streams, leading to the same issues we face with the typable delimiter characters we currently use. It's sort of a catch-22.
Post reply on HN