Hacker News Reader

> offers me 7 kinds of ketchup and 20+ kinds of cereal, but no one says "I am avoiding

They even write articles about decision paralysis and being overwhelmed by choice and all that, so yes the exact same issue apparently exists in that domain

> You will need to keep the name of previous branch in your head

Not even that - "git checkout -" is like "cd -", but for branches.

I have it on a short alias - cor. I do "cob asdf", do some work, then "cor". (I have 28 aliases for git alone, 2 or 3 letters each. And I still get to autocomplete any options when necessary, thanks to https://github.com/cykerway/complete-alias).

Don't you think having 28 aliases for the git incantations in your worflow is a clear signal something is wrong with git?

This argument makes sense only if you think Git has, like, 2 uses.

It's mostly because of my attempts to minimize keypresses due to RSI. I would end up with similar, albeit lower, number of aliases if I were to use jj.

Magit (for Emacs) is geared towards one-key-per-action/flag. E.g. `c` when you are in the Git Status window.

Meant to say that `c` triggers the “commit” interaction. Just `cc` if you want to commit without options.

Don't you think having 300+ commands in /bin is a clear signal something is wrong with Unix? No?

There are certain cases that - isn't allowed in though, like git branch -d.

I've only ever needed it for checkout, but in other commands I believe the full syntax @{-1} should work.

> no one says "I am avoiding large grocery stores because they force me to make too many decisions"

I say that. I 100% prefer going to the smaller store if I don't need anything "fancy" because the large offerings stress me out.

That said I'm fine with git and don't care about Jujutsu, so I don't know what that says about me :)

But jj is as powerful as git. The choices are meaningless.

If you have one piece of code that does what you need with four conceptually different types of state that interact in various ways when state is mutated, and another that does it with one type of state and a lot fewer interactions, what's the better architecture?

A car and a bicycle fundamentally get you from point a to point b.

Is the decision which you take meaningless if your destination is 50 miles away?

You missed the point. The analogy was: Git has more choice and like having access to exotic Ketchups that can be nice. But jj can do anything that git can, so in the metaphor, git gives you a ton of choice but jj gives you all the same flavors.

Now if jj makes you assemble several pieces and makes it more difficult to get the flavors, while with git you could just grab the correct bottle, you could argue that the choice git offers is not meaningless. But that's a hard sell.

I think by now, there is pretty good evidence that the complexity of operating git is incidental. It's the result of badly designed primitives the user has to interact with (index, stash, commits, branches). As always, once you have internalized the primitives and their interactions, the complexity (mostly) disappears. But if you frequently train new students in using git, you stay painfully aware of it.

Or you're missing the point ( • ‿ • )

I think you've straight up reinforced my example. The end result is the same, but the way to get there is different.

Depending on what your destination is, a different tool might ultimately turn out to be better for the job. Even if they're both representing their state in a compatible manner on disk.

You're probably just not realizing that the way you interact with git isn't necessarily how everyone does - and that other people might have usecases that you've never thought about... Because you're not in their situation. So you're only seeing one way to reach the destination, which is why the one tool always looks like the correct choice.

To be clear, my current day job really wouldn't get any value out of any of these features either. We're doing simple trunk development on various repositories with roughly 5 authors providing commits.

Almost no merge conflicts, the most anyone does is git blame to figure out when the line was edited etc. under these circumstances, commits are essentially fire and forget and you're fine only interacting with the repository through your ide even.

Nobody, including you, have produced an example of a workforce that's substantially easier due to gits model.

Either gits design is unnecessarily complex, or there should be a pay off to the complexity somewhere. Some flavor you can't get, or can't get easily, with jj.

I wouldn't need these features either, but I believe teaching jj to beginners will be easier than teaching git. This is further evidence that the problem is git, not the problem space and the need for different workflows: If a different set of concepts serves both power users and beginners better, at what point do we stop pretending that it's all just tradeoffs?

I’m working solo on a project, with trunk based development. I still find jj nicer to use than git. I do do pull requests but just to ensure that CI passes on every commit.

Everybody is different, and that’s okay.

This is the point!

Almost anyone (above the age of 5) on this planet is familiar with food, not the case with `git` and it's obvious non-obviousness

I would argue that any professional developer should be familiar with basic manipulations in git...

You would be surprised. Google uses "g4" (e.g. "p4"-like), much like many game developers like me. It's not like we don't use "git" (we have devops/infra groups) - but lots of folks use Perforce/PlasticSCM/other systems that are not "git".

Just because "git" is super-popular, does not mean that ANY PROFESSIONAL DEVELOPER SHOULD BE FAMILIAR with it... Sorry but no!

Well if you can use jj, it means that you work against a git repository, doesn't it? Or does jj work with g4 repositories?

I guess I have to give `jj` a try then!

A better analogy would be: You have 7 ways to the ketchup section with varying lengths.

Some will lead you into a universe from which you will never return.

That can work too... "To get to the ketchup section, I can go via fresh produce row or via bread row or via canned food row... Which path do I pick? Going via produce row is faster but I need to pick up some hot dog buns..."

On the other hand IKEA did design their showrooms so there is exactly one recommended way to get to any section. I find this highly annoying, but they keep doing this, so I am guessing some people like it?

> I am hearing this argument a lot, but I don't really get it. My grocery store forces me to make a lot of decision when it offers me 7 kinds of ketchup and 20+ kinds of cereal, but no one says "I am avoiding large grocery stores because they force me to make too many decisions".

I say that all the time. I hate decision paralysis. I'll specifically buy stuff in ways (such as online order + pickup) that I don't have to look at tons of different products.