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

91–100 of 133 posts

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

#91

Post by inigyou »

majewsky wrote: post #68
jchw wrote: post #51

Earlier quoted context omitted.

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

What if someone asked you the same about a new repo?

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

#92

Post by inigyou »

eviks wrote: post #55
bradley13 wrote: post #9

As with almost any successful system: more and more special features and edge cases get added. Git has become ridiculously complex. I wonder: would it not be better to tell users with those edge cases to fix their problems some other way? To take an example from the article: why does someone have a filename beginning with a dash? Maybe don't do that.

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

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

#93

Post by throw0101d »

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

> 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 many ways it has evolved rather than be designed.

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

#94

Post by xigoi »

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!

On Linux, the en dash is typed with `[Compose]--.` and the em dash with `[Compose]---`.

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

#95

Post by IshKebab »

ulrikrasmussen wrote: post #80
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/

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.

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

#97

Post by zahlman »

xigoi wrote: post #94
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!

On Linux, the en dash is typed with `[Compose]--.` and the em dash with `[Compose]---`.

Unless, you know, you configured it to work differently. I'm using [Compose]nd and [Compose]md . And a bunch of other cute things, like [Compose][Compose] for escape (with Caps Lock as my compose key).

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

#98

Post by IshKebab »

oneeyedpigeon wrote: post #72
jchw wrote: post #51

Earlier quoted context omitted.

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…

> I have no reason or desire to change my default branch name And you're absolutely entitled to. I have no problem with anyone choosing to stick with "master", provided they have no issue with me preferring "main".

But I do have an issue with you preferring `main`. It means I have the constant annoyance of remembering whether a project uses `main` or `master`.

It's not a big annoyance but it is an especially painful one because it didn't used to exist and it was deliberately introduced for completely bullshit reasons.

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

#99

Post by gritzko »

xg15 wrote: post #30
TZubiri wrote: post #27

Earlier quoted context omitted.

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

Yeah, now the LLMs are guessing the commands...

Spot on. I had my repo messed up more than once. Sometimes it is quick enough to push that to GitHub.

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

#100

Post by peff »

epistasis wrote: post #11

Perhaps I'm missing something (it's been a long day), but couldn't "--" be used for both? git cmd --options -- rev -- pathspec would be the fully specified revspec and pathspec git cmd --option -- rev -- would be just the revspec, excluding accidental options, without a pathspec git cmd --option revspec -- pathspec and the single "--" would work as it currently does.

If it's used for both, then you couldn't have "--" itself as a pathspec. In your first example, the current meaning is: a pathspec containing "rev", "--", and "pathspec".
Post reply on HN