git --end-of-options
65 points by robalex
65 points by robalex
I've become increasingly jj-pilled lately. It feels like such a balm compared to this kind of Git nonsense. I'm still getting the hang of it, but overall it's really good at doing what I mean, it's not hard to figure out what to do what you want, and maybe best of all, knowledge of how to work one jj command transfers to other ones really well.
I mean, look at the git log docs.. How the hell is anyone supposed to make sense of this? And these behaviors are different for every command. Note in particular the explosion of individual flags governing display options, as well as the combination of commit-range syntax (sorry, "special notation") and even more individual flags to further filter on the commit set. Little of this transfers to other git commands.
Compare that to the jj log docs. You could print it on a single page and still have blank space. git log's junk drawer of complexity is almost totally replaced by three DSLs: one for specifying sets of revisions, one for specifying sets of files, and one for templating output. And those three DSLs get used pervasively across jj. You learn them, then you can use them everywhere. Way simpler, way more compositional, way more intuitive. (To be fair to Git, they've had 20 years to accumulate this cruft, but jj feels way better positioned to avoid it.)
I haven't seen this difference come up as often in the many "why jj" posts cropping up now, but I think it's a pretty noteworthy one.
I know that commands usually need -- before user-supplied arguments, but requiring a custom flavor of that is too much of a footgun.
--- was right there
Was the original choice to use -- to resolve file argument ambiguity, as opposed to something simpler like making files an explicit argument, as silly as it seems? Or was there a not-obvious trade off in that design decision?
Yes, using a well-established UNIX option parsing behaviour for something else entirely is about as daft (and thoroughly on brand for git) as you might imagine.
It might seem like a cute re-use of the idea, if you're not thinking about security.
And I think it's justifiable to say that people shouldn't be giving untrusted data to the git command line or environment. Tools packaging git should be sanitising their input and/or using the structured API.
Few of the package managers reviewed in the article would have been protected if -- worked.
Honest result when you overcomplicate a tool. Imo git is a new Vasa ship.
Unix's "everything is just text" strikes again. Command lines are such perfect examples of structured data, so I guess the coordination problems involved in climbing out of this hole are just too much for us to collectively manage.
Looking back on the Tcl vs Scheme bunfight of the 90s makes me think maybe worse would have been better in that instance, given how much S expressions (as a family, e.g. including json, xml) have failed to catch on in the Unix ecosystem. At least Tcl had (has, I guess) a reasonably principled approach to layering sublanguages into strings.