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

11–20 of 133 posts

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

#11

Post by epistasis »

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.

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

#12

Post by epistasis »

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?

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

#14

Post by zanecodes »

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.

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 inertia of existing systems that might be used under the hood, like DNS for instance.

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

#15

Post by ButlerianJihad »

wafflemaker wrote: post #10
ButlerianJihad wrote: post #8

https://m.xkcd.com/1597/ By the way, something munched the article title. An endash is incorrect command-line usage. It’s supposed to be a double hyphen.

From the title I've learned that git uses an em-dash instead of double dash as options delimiter. Thanks for pointing out that the title was wrong -- I've never had a need to use -- with git, so didn't know that it doesn't work.

I'm sorry, you've learned what now?

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

#16

Post by _blk »

eru wrote: post #7
_blk wrote: post #5

> git log --end-of-options "$rev" -- "$path", Argh, that's when I wished for object oriented shells. Powershell sure isn't perfect but objects encoding their own meaning really helps differentiate those cases (but it may not always help the user if types aren't clear to the reader)

I don't think you need object orientation for that. Haskell and Rust solve these problems also just fine, without any OOP in sight.

Hmm, not sure I understand. How are those shell based?

I agree that rust and haskell are not your typical OO (or not OO at all in a traditional sense) I guess my poorly worded claim was less focused on the OO nature of psh than on the typization (which both of these also do) - if you knew what type $rev and $path are, it's easier to distinguish intent, whether objects or not.

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

#19

Post by gene91 »

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