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

51–60 of 133 posts

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

#51

Post by jchw »

4gotunameagain wrote: post #47
oneeyedpigeon wrote: post #36

Earlier quoted context omitted.

There are advantages beyond avoiding the use of a charged term.

[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 the abolishment of slavery in the U.S.

The word "master" is of course still in widespread use elsewhere too. We still say "Master's degree" or "mastering a skill".

The point of this entire exercise was group dynamics, but what I hate most about it is something that I also hate about other recent bullshit: I hate that not wanting to play is in itself forced to be an active stance. I have no reason or desire to change my default branch name; it is staying master. That is not an attempt to signal anything at all. This is not "chud-coded". It is literally, the absence of a desire to participate.

And we'll never forget it either, because now even in pre-existing projects we have to checkout/pull master then main. Or worse. You know how many times I've accidentally rebased off of an ancient version of something because master still exists? This is surprisingly common.

It was an entire waste of time and everyone who has remaining respect for themselves should be honest about it.

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

#52

Post by andy99 »

peheje wrote: post #38
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/

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?

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

#53

Post by dc3k »

ffsm8 wrote: post #50
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/

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.

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

#55

Post by eviks »

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

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

#56

Post by Sharlin »

cubefox wrote: post #34
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!

Then how do you type in an en dash instead? Also, according to LLMs, the en dash is used in far more languages than the em dash. Many languages don't use the em dash at all. Using the em dash for sentence interruptions seems to be specifically an US American English tradition: Most languages which use dashes for sentence interruptions use spaced en dashes instead.

I get en dash with alt+- and em dash with alt+shift+-. One of the niceties of the macOS keyboard layouts. There’s also the ellipsis and middot among other things.

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

#58

Post by reaperducer »

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?

Because it's my computer, not yours, and I'll do what I want with it?

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

#59

Post by Bugg4 »

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/

The hobgoblin one sent me

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

#60

Post by stingraycharles »

dmurray wrote: post #49
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!

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.

Post reply on HN