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

111–120 of 133 posts

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

#111

Post by IshKebab »

sigseg1v wrote: post #107
IshKebab wrote: post #95

Earlier quoted context omitted.

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.

Hasn't been my experience at all, but also why would you do that? The CLI has an awful confusing UX and also doesn't easily show you the state of things.

If you're trying to teach a child how filesystems work, do you open a terminal and teach them `ls` and `cd`? No of course not. You use some kind of GUI file manager with a tree view.

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

#112

Post by inigyou »

eviks wrote: post #108
inigyou wrote: post #92

Earlier quoted context omitted.

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?

Then you have to have an illegal filename symbol.

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

#113

Post by xorcist »

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's a bit of a mystery, especially since the one of the lowest surprise character they could have chosen was a colon, and indeed colon is already used to separate branch and path -- but only where they are one option and not two.

For example:

  git log mybranch myfile.txt
but:

  git show mybranch:myfile.txt
That's indeed one of the things that trip up people when I try to introduce them to the git model. I wish it had been different.

The double dash is normally not needed when it is self evident if a branch or file is referred to. It is only needed when a file no longer exists or a file and a branch exists with the same name. One could easily have imagined the one-argument syntax to be dominant. It would have been a bit awkward in a few situations, but a lot less confusing in others.

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

#116

Post by gritzko »

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.

The only way out is malleable software. Have the core data structures and algorithms in a native library. Have a layer of JavaScript/Lua/LISP on top of that. Editable, customizable, reusable.

This is not a theory. I work in such a system every day.

git sort of tried that with plumbing/porcelain separation and bash scripts, but it did not quite work. It all became a C monolith with very peculiar UX.

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

#117

Post by epistasis »

peff wrote: post #100
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".

Add in "--" a third time, and it's a file in the path spec, like it is for tools like rm.

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

#118

Post by epistasis »

gene91 wrote: post #19
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.

Currently, git log -- a -- prints all commits that affects the files whose name is a or two dashes.

Yes, that would change behavior slightly. To restore behavior for pathspecs including a "--" file, you would need to add an additional -- to make the revspec explicitly blank:

    git log -- -- a --

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

#119

Post by epistasis »

jibal wrote: post #63
epistasis wrote: post #12

Earlier quoted context omitted.

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

Yes, doesn't that match git's behavior? Or are you saying that's not the case?

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

#120

Post by angry_octet »

When I read Claude lingo [1] in a nominally human-authored piece it gives a sensation akin to cockroaches crawling on your face.

Which seems unfair because what if they have subconsciously regurgitated Claude-speak?

[1] "That’s a real cost,"

Post reply on HN