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

121–130 of 133 posts

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

#121

Post by gene91 »

epistasis wrote: post #118
gene91 wrote: post #19

Earlier quoted context omitted.

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

Previously working command needs to continue behave the same way. Your original proposal was intended to provide backward compatibility (your third point in original comment), and that’s an important part of why it could work.

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

#122

Post by dns_snek »

IshKebab wrote: post #111
sigseg1v wrote: post #107

Earlier quoted context omitted.

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.

git CLI and various GUIs are awful in different ways. CLI is awfully inconsistent and hard to learn, but GUIs obfuscate what's happening behind the scenes and make it harder to recover from mistakes.

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

#123

Post by IshKebab »

dns_snek wrote: post #122
IshKebab wrote: post #111

Earlier quoted context omitted.

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.

git CLI and various GUIs are awful in different ways. CLI is awfully inconsistent and hard to learn, but GUIs obfuscate what's happening behind the scenes and make it harder to recover from mistakes.

> but GUIs obfuscate what's happening behind the scenes and make it harder to recover from mistakes.

I disagree. "What's happening behind the scenes" is not the corresponding CLI command - it's the actual modification to the commit graph, and GUIs are much better at exposing what is happening. Think about something like a rebase. Find any article explaining Git rebase. It will have diagrams showing what happens to the commits and those diagrams are exactly what a Git GUI displays!

To follow my filesystem analogy, when you move a file, the thing that's happening behind the scenes is that the file is moved, not `mv A B`.

> make it harder to recover from mistakes.

Also disagree. I'm not sure what you're talking about exactly but assuming reflog, then most GUIs don't support that and you're going to have to use the CLI in either case. But "GUIs don't cover this rare feature" isn't a reason to ditch them completely.

I agree there are a lot of awful GUIs though. It doesn't help that the Git website lists dozens of them and only 2 or 3 are any good. My recommendation: if you use VSCode, the Git Graph extension. If you want a standalone tools, SourceGit or maybe GitX if you're on Mac.

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

#124

Post by yencabulator »

gritzko wrote: post #116
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.

JJ's use of the Git file format is done via https://github.com/GitoxideLabs/gitoxide -- there's still some missing features in the networking part, but the local-file-manipulation features are fully there.

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

#126

Post by gritzko »

yencabulator wrote: post #124
gritzko wrote: post #116

Earlier quoted context omitted.

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.

JJ's use of the Git file format is done via https://github.com/GitoxideLabs/gitoxide -- there's still some missing features in the networking part, but the local-file-manipulation features are fully there.

Great lib. I meant libdog, a different thing. gitoxide is like "git implemented in Rust" while libdog is "git's necessary primitives in C" (objects, packs, sync proto, own index format, diff/merge, etc). As a result, gitoxide is 270KLoC while libdog is 24KLoC, plus 44KLoC of tokenizers. libdog uses token-level algorithms for diff, merge, blame. It also does syntax highlighting in the pager - they all need grammars.

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

#127

Post by ButlerianJihad »

IshKebab wrote: post #111
sigseg1v wrote: post #107

Earlier quoted context omitted.

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.

It may surprise you to discover that children are quite capable of visualizing filesystem trees without a GUI, and learning `cd` and `ls` may lead them to experiment with `ls -R`, and learning the semantics of '.' and '..'

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

#128

Post by ButlerianJihad »

windward wrote: post #73
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.

It's from 2019, so it's hardly a recent development. It's also very discoverable if you see it in the wild. You may be surprised that `--` doesn't work, but you won't be surprised `--end-of-options` represents the end of options. What problem does this actually cause you? What additional complexity has adding this feature added to your development cycle?

“Surprised” is not the emotion I would describe when discovering yet another legacy of the insufferable verbosity of EMACS Lisp that the insufferably verbose Stallman loved to spell everything out and create insufferable “new standards” because his autocomplete environment was insufferably superior to everyone else.

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

#129

Post by windward »

ButlerianJihad wrote: post #128
windward wrote: post #73

Earlier quoted context omitted.

It's from 2019, so it's hardly a recent development. It's also very discoverable if you see it in the wild. You may be surprised that `--` doesn't work, but you won't be surprised `--end-of-options` represents the end of options. What problem does this actually cause you? What additional complexity has adding this feature added to your development cycle?

“Surprised” is not the emotion I would describe when discovering yet another legacy of the insufferable verbosity of EMACS Lisp that the insufferably verbose Stallman loved to spell everything out and create insufferable “new standards” because his autocomplete environment was insufferably superior to everyone else.

Well it's a problem that's existed since day one

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

#130

Post by IshKebab »

ButlerianJihad wrote: post #127
IshKebab wrote: post #111

Earlier quoted context omitted.

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.

It may surprise you to discover that children are quite capable of visualizing filesystem trees without a GUI, and learning `cd` and `ls` may lead them to experiment with `ls -R`, and learning the semantics of '.' and '..'

That would surprise me a great deal if it were true.
Post reply on HN