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

61–70 of 133 posts

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

#61

Post by jibal »

andy99 wrote: post #52
peheje wrote: post #38

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?

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.

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

#62

Post by reaperducer »

ButlerianJihad wrote: post #26
sheept wrote: post #24

Earlier quoted context omitted.

It is an en dash, not an em dash, since it's about as wide as an n. Some software substitutes a double hyphen -- with an en dash rather than em, and use the triple hyphen --- for the em dash. Perhaps Hacker News' title formatter is one of them.

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!

because the double hyphen is a convention or placeholder for an emdash

A /more recent/ convention.

My memory of early Associated Press computer systems is that two dashes is the endash (or "nutt") and three dashes is the emdash ("mutt").

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

#63

Post by jibal »

epistasis wrote: post #12
metadat wrote: post #2

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!

Since it separates out the pathspec, doesn't that match the long standing convention?

The convention is that a leading `-` isn't recognized as a flag after `--`.

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

#66

Post by kangalioo »

vips7L wrote: post #42
zanecodes wrote: post #14

Earlier quoted context omitted.

Sometimes you're using git in a context where you don't control the filenames, or where a potential attacker could influence or fully control them, at which point edge cases like this can easily turn into exploits. I also chafe whenever I run into artificial restrictions on things like characters in names of things, because there's no good reason for them besides the laziness of developers or the limitations and iner…

An attacker has access to your git??? You’re fucked. Give up.

Every git repository hosting platform - GitHub, GitLab, Bitbucket, Codeberg - necessarily gives end users control over filenames.

"User-controlled strings as parameters" is not "access to your git" but it is still an attack vector.

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

#67

Post by pydry »

doctoboggan wrote: post #4
metadat wrote: post #2

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/

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.

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

#68

Post by majewsky »

jchw wrote: post #51
4gotunameagain wrote: post #47

Earlier quoted context omitted.

[flagged]

It wasn't anyways. It was clearly in reference to "master copy", which is also not a charged term. Neither was "master bedroom". Hell, for most of my life I'd never even seen anyone raise objections over the master/slave dichotomy used in software and hardware either, which is a far easier to understand argument. It's all very recent, last decade and some change, despite many of these terms having come into use after…

> It is literally, the absence of a desire to participate.

I agree with this position, and yet I would argue that, by taking the time to write out this comment, you are acting inconsistenly with your own statement.

I have old repos with "master" and new repos with "main". If someone were to approach me about one of the old repos and ask about the default branch, I would immediately change it to "main" without any hesitation, because it is all but certain that trying to get into an argument will waste more of my time than just doing the change would.

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

#69

Post by majewsky »

eviks wrote: post #57
Chinjut wrote: post #18

The "Everything is text, do everything via text" philosophy has its advantages, and also its disadvantages.

What are the advantages over structured text?

Access to a well-established set of tools for operating on unstructured text (coreutils, grep, sed, awk, etc.).

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

#70

Post by eviks »

majewsky wrote: post #69
eviks wrote: post #57

Earlier quoted context omitted.

What are the advantages over structured text?

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
Post reply on HN