commented:
I know that commands usually need -- before user-supplied arguments,
but requiring a custom flavor of that is too much of a footgun.

  commented:
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.

  commented:
Honest result when you overcomplicate a tool. Imo git is a new Vasa
ship.

  commented:
So you're saying we might get a really cool museum of git one day??

  commented:
Definitely yes. Not sure if it will be in Sweden.

  commented:
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?

  commented:
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.

  commented:
Comment removed by author
.