[pzmarzly]

Jujutsu equivalents, if anyone is curious:

What Changes the Most

    jj log --no-graph -r 'ancestors(trunk()) & committer_date(after:"1 year ago")' \
      -T 'self.diff().files().map(|f| f.path() ++ "\n").join("")' \
      | sort | uniq -c | sort -nr | head -20

Who Built This

    jj log --no-graph -r 'ancestors(trunk()) & ~merges()' \
      -T 'self.author().name() ++ "\n"' \
      | sort | uniq -c | sort -nr

Where Do Bugs Cluster

    jj log --no-graph -r 'ancestors(trunk()) & description(regex:"(?i)fix|bug|broken")' \
      -T 'self.diff().files().map(|f| f.path() ++ "\n").join("")' \
      | sort | uniq -c | sort -nr | head -20

Is This Project Accelerating or Dying

    jj log --no-graph -r 'ancestors(trunk())' \
      -T 'self.committer().timestamp().format("%Y-%m") ++ "\n"' \
      | sort | uniq -c

How Often Is the Team Firefighting

    jj log --no-graph \
      -r 'ancestors(trunk()) & committer_date(after:"1 year ago") & description(regex:"(?i)revert|hotfix|emergency|rollback")'

Much more verbose, closer to programming than shell scripting. But less flags to remember.

[palata]

To me, it makes jujutsu look like the Nix of VCSes.

Not meaning to offend anyone: Nix is cool, but adds complexity. And as a disclaimer: I used jujutsu for a few months and went back to git. Mostly because git is wired in my fingers, and git is everywhere. Those examples of what jujutsu can do and not git sound nice, but in those few months I never remotely had a need for them, so it felt overkill for me.

[Jenk]

Tbf you wouldn't use/switch to jj for (because of) those kind of commands, and are quite the outlier in the grand list of reasons to use jj. However the option to use the revset language in that manner is a high-ranking reason to use jj in my opinion.

The most frequent "complex" command I use is to find commits in my name that are unsigned, and then sign them (this is owing to my workflow with agents that commit on my behalf but I'm not going to give agents my private key!)

    jj log -r 'mine() & ~signed()'

    # or if yolo mode...

    jj sign -r 'mine() & ~signed()'

I hadn't even spared a moment to consider the git equivalent but I would humbly expect it to be quite obtuse.

[palata]

Actually, signing was one of the annoying parts of jujutsu for me: I sign with a security key, and the way jujutsu handled signing was very painful to me (I know it can be configured and I tried a few different ways, but it felt inherent to how jujutsu handles commits (revisions?)).

[arccy]

The only reasonable way to use signing in jj is with the sign-on-push config https://docs.jj-vcs.dev/latest/config/#automatically-signing... rather than as commits are made

[Zambyte]

Why? I have my signing behavior set to own and I haven't noticed any issues, but I don't actually rely on signatures for much.

[singron]

If you need to type in a password to unlock your keychain (e.g. default behavior for gpg-agent), then signing commits one at a time constantly is annoying.

Does "own" try to sign working copy snapshot commits too? That would greatly increase the number and frequency of signatures.

[rjh29]

It's the dvorak of git... Maybe more efficient but incompatible with everyone else and a very loud vocal minority.

You can find this pattern again and again. How many redditors say 120fps is essential for gaming or absolutely require a mechanical keyboard?

[palata]

Yeah I think that dvorak is a good example, too.

I don't get the mechanical keyboard one, though. I am fine with any keyboard, I just like my mechanical keyboard at home. Just like I am fine with any chair, but ideally I would have a chair I like at home.

120fps I have no experience with, but I would imagine it's closer to video quality. Once you're used to watching everything in 4K, probably it feels frustrating to watch a 1080p video. But when 4K did not exist, it was not a need. I actively try to not get used to 4K because I don't want to "create the need" for it :-).

[alsetmusic]

> Just like I am fine with any chair, but ideally I would have a chair I like at home.

I love my Aeron chair. I've had it for fifteen years and it's still in great shape.

I used to have chronic back pain. Getting good ergonomics at home really put that to bed.

[account42]

> 120fps I have no experience with, but I would imagine it's closer to video quality. Once you're used to watching everything in 4K, probably it feels frustrating to watch a 1080p video. But when 4K did not exist, it was not a need. I actively try to not get used to 4K because I don't want to "create the need" for it :-).

I suggest not worrying too much about that - been using a big 4K TV with lots of 4K movies for a long time now and SD content is still as watchable as ever.

For framerates, especially in an interactive context, this is what happens though in my experience. But it also really depends what happens on screen - more movement needs higher framerates to feel smooth.

[SatvikBeri]

It's totally compatible though, and that's a big selling point. I use jj and nobody else at my work uses it and that has never been an issue.

[palata]

I think the "incompatible" was more in the dvorak sense, which I believe is that whenever you are on another computer, it most likely won't have dvorak.

For jujutsu, it's fine on your own computer, but you probably have to use git in the CI or on remote servers. And you probably started with git, so moving to jujutsu was an added effort (similar to dvorak).

[shiroiuma]

>I think the "incompatible" was more in the dvorak sense, which I believe is that whenever you are on another computer, it most likely won't have dvorak.

That's not a problem, just switch to Qwerty when you use a different computer. For me at least, it's not hard at all to switch between Dvorak and Qwerty.

[palata]

> For me at least, it's not hard at all to switch between Dvorak and Qwerty.

Sure, but you had to learn both. And what benefit did you get from learning Dvorak?

I feel the same with jujutsu: I have to learn it on top of git, and I don't see a lot of benefits from knowing it.

[FrankBooth]

It doesn’t support submodules. So no, not totally compatible.

[zhengyi13]

That's a feature, not a bug /s

[herewulf]

Reminds me of how I started using Git when it was up and coming: It was the best Subversion client out there and no one knew I was using it!

[RankingMember]

I don't even like using "natural" keyboards despite the ergonomic advantage because it ruins my muscle memory when I'm on the (much more prevalent) "regular" keyboard.

[bastardoperator]

Looks like the Perl of Git too. Those commands are wild compared to vanilla git.

[account42]

> How many redditors say 120fps is essential for gaming or absolutely require a mechanical keyboard?

Those don't fit the others - they don't really require the user to adapt or are more complex in any way but are just nicer versions of the standard.

[deno]

I mean let's not be hasty. Mechanical keyboards used to be just normal keyboards when computers were still computers.

[rjh29]

That is a fair argument. I don't know why they dropped out of favour - price? Noise?

[lamasery]

My guess would be price. Shoppers probably got more sensitive to the price of a keyboard as the price of computers dropped, and approximately none of them were choosing between two computer-bundles at the store with any regard for keyboard quality.

[deno]

Most people and companies just use the keyboard that shipped with the computer. I don't think noise is as much of an issue as people make it out be.

Marketing made up this story about linear switches being for gamers. So now every mechanical keyboard needs to make unnecessary noise and offer extra resistance for harder bottom out or you're not a serious typist.

But that's not inherent to the keyboard. Linear switches are not any louder than cheapo office high-profile membrane.

[shiroiuma]

I'm not a gamer these days, but from what I've seen, the gamers like a different type of keyswitch than regular typists. Normal typists like a clicky keyswitch where it clicks with very little travel, and has plenty of travel after this to avoid bottoming out. (so, Cherry blue)

Gamers want mechanical keyswitches with no click at all. (Cherry brown I think)

[rjh29]

I find the resistance to be a hindrance when typing. Fastest typing speed and comfort for me is my thinkpad keyboard which uses scissor switches with a very low profile - you need less effort per keystroke!

[alper]

Pretty much everybody who does work at the real office where I am has a mechanical keyboard by now.

[mamcx]

No, jj is super simple in daily use, in contrast with git that is a constant chore (and any sane person use alias). This include stuff that in git is a total mess of complexity like dealing with rebases. So not judge the tool for this odd case.

[palata]

> in contrast with git that is a constant chore (and any sane person use alias)

I don't use aliases, I guess I'm insane?

Also 99.9% of the time, git "just works" for me. If I need to do something special once a year, I can search for it. Like I would with jujutsu.

[Exoristos]

One rarely needs more from git than `git add -A && git commit -m`.

[tcoff91]

I rebase stacked diffs all the time so jj makes my life so much easier because its rebasing is much more ergonomic than git.

[beanjuiceII]

this seems very easy in git tho how much easier can it get, do you have an example of each of them?

[rstuart4133]

As someone else said, jj comes into its own when a reviewer insists you split your PR into many commits, because they don't want to review 13k lines in one chunk. In that case it is easier because there is no rebase. To change a PR commit in the middle of the stack you checkout a PR commit, edit it - and done. The rebase happened automagically.

Notice I didn't say "edit it, commit, and done" because that's another thing you don't do in jj - commit. I know, `git commit` is just a few characters on the cli - but it's one of several git commands you will never have to type again because jj does it without having to be asked.

If the rebase created a merge conflict (it could do so in any PR commit above the one you edited) - it's no biggie because jj happily saves merge commits with conflicts. You just check it out, and edit to remove the conflict.

Jj does grow on you over time. For example, when you start with jj you end up in the same messes you did as a git beginner, when you recovered with 'rm -r repository', followed by 'git clone git@host/repository.git'. Then you discover 'jj op restore' which compared to git's reflog is a breath of fresh air. And while you might at first find yourself chafing at the loss of git staging, you gradually get comfortable with the new way of working - then you discover `jj evolog`, and it's "omg that's far better than staging". Ditto with workspaces vs worktrees, and just about everything else. It might be difficult to lose work with a bad git command, but actually impossible to lose work with a jj command.

It is a steep learning curve. We are talking months to use it fluently instead of treating it as git with better porcelain. If all you ever do is work with one commit at a time, it's a lot of effort for not a lot of return. But as soon as you start managing stacks of changes, duplicating them, splicing them, it makes you feel like a god.

That said, if you are starting out - I'd suggest starting with jj instead of git. You've got to go through a learning curve anyway. You may as well do it with the kinder, gentler, more powerful tool.

[dpatterbee]

Git rebases don't work if there are conflicts, jj doesn't have this problem. Also idk if you can rebase onto multiple parents with git but jj can do it.

[account42]

I prefer `git commit --patch` and having a full editor for commit messages rather than a command-line -m argument to encourage me to actually write something useful.

[alper]

Nix does not really work in that even basic things are absurdly complicated and can take days of messing with poor libraries and documentation.

That's not been my experience with jj which after the initial hurdle is a breeze.

[buu700]

I don't know about jujutsu, but I've actually found that Nix removes a lot of complexity. It's essentially just npm for tooling.

Managing a flake.nix can be a bit more complex than a package.json in practice, due to the flexibility of the format and some quirks around Nix's default caching behavior, but working with it is a breath of fresh air compared relying on globally installed tools. Having said that, you might want to check out Devbox. I haven't used it myself, but found it recently and thought it looked like a nice abstraction over raw Nix.

[qudat]

To be completely fair to JJ: you can still use git commands and any aliases with it. I daily JJ in all of my repos but I created these aliases inside of git. That's one of the great aspects of JJ: it's fully compatible with git.

[stingraycharles]

I don’t understand how people can remember all these custom scripting languages. I can’t even remember most git flags, I’m ecstatic when I remember how to iterate over arrays in “jq”, I can’t fathom how people remember these types of syntaxes.

[crispyambulance]

I am convinced that the vast majority of professionals simply don't bother to remember and, ESPECIALLY WITH GIT, just look stuff up every single time the workflow deviates from their daily usage.

At this point perhaps a million person-years have been sacrificed to the semantically incoherent shit UX of git. I have loathed git from the beginning but there's effectively no other choice.

That said, the OP's commands are useful, I am copying them (because obviously I won't ever memorize them).

[freedomben]

> I am convinced that the vast majority of professionals simply don't bother to remember and, ESPECIALLY WITH GIT, just look stuff up every single time the workflow deviates from their daily usage.

I wrote a cheat sheet in my notes of common commands, until they stuck in my head and I haven't needed it now for a decade or more. I also lean heavily on aliases and "self-documenting" things in my .bashrc file. Curious how others handle it. A search every time I need to do something would be too much friction for me to stand.

[dheera]

I just use Claude Code as a terminal for git these days. It writes up better commit messages than I would write anyway. No more "git commit -m fix"

[selcuka]

That could work if Claude Code made the code changes, but if you made them and only asked Claude to commit them, how does it know "why" you made those changes? Does it have access to your bug tracking system, for example?

[dheera]

> but if you made them and only asked Claude to commit them, how does it know "why" you made those changes?

It's an LLM. It can diff and figure out why I did what I did, in most cases

> Does it have access to your bug tracking system, for example?

You can give it access and tell it to look there

[awesome_dude]

If Claude was used in the creation of the change, there's usually some dialogue for Claude to use.

FWIW i use Claude to help with code changes, then give the diff to Gemini to review/ create meaningful commit messages

[yujiachen]

I just wrapped these 5 diagnostic commands into a Claude Code skill. Because the post is useful but I'm not sure I can remember these git commands all the time... https://github.com/yujiachen-y/codebase-recon-skill

[freedomben]

indeed, I held off for a while but finally caved because I got sick of seeing commits with `git commit -m .` littered in there. These are personal projects so I'm the only one dev-ing on them, but still so nice to have commit messages.

[bluGill]

I refuse to have alises and other custom commands. Either it is useful for everyone and so I make a change to the upstream project (I have never done this), or it won't exist next time I change my system so there is no point. I do have some custom tools that I am working on that haven't been released yet, but the long term goal is either delete them or release them to more people who will use them so I know it will be there next time I use a different system.

[irishcoffee]

> I refuse to have alises and other custom commands.

I am the same way, and have caught much flack for it over the years.

But when I sit down at a foreign system (foreign in the sense that I haven't used it before) because something is broken and my help was requested, I don't have any need to lean on aliases.

I worked with someone once that had a very impressive bashrc, and it was very effective for them... on their workstation. Plop them in front of a production system, they can't even remember how to remount / rw because they've been using an alias for so long.

This is also why I learned vi, having started with emacs 30 years ago initially, as it was first taught to me. I know it'll be there, and I know how to use it.

[tcoff91]

You don’t need aliases when you have fzf fuzzy history search with ctrl-r

[freedomben]

it's a tradeoff for sure. With dig especially I can't ever remember the normal syntax because I have aliases and scripts for things. I feel the aliases are wroth it since I'm on my own machine(s) 99.5% of the time, but it does suck to be handicapped

[alwillis]

> At this point perhaps a million person-years have been sacrificed to the semantically incoherent shit UX of git. I have loathed git from the beginning but there's effectively no other choice.

Yes! We mostly wouldn’t tolerate the complexity and the terrible UX of a tool we use everyday--but there's enough Stockholm Syndrome out there where most of us are willing to tolerate it.

[TeMPOraL]

Unless you're aware that such powerful commands are something you need once in a blue moon, and then you're grateful that the tool is flexible enough to allow them in the first place.

Git may be sharp and unwieldy, but it's also one of the decreasing amount of tools we still use - the trend of turning tools into toys consumed the regular user market and is eating into tech software as well.

[crispyambulance]

Tools, done right, are a joy to use and allow you to be expressive and precise while also saving you labor. Good tools promote mastery and creative inquiry.

Git is NOT that.

Git is something you use to get stuff done, until it becomes an irritating obstacle course of incidental complexity.

[irishcoffee]

Hg is a joy to use compared to git. Sure wish hg had won.

[skydhash]

Why should there be tolerance? You look it up once, then write a script or an alias if it's part of your workflow. Or made a note if it's worth that. I use magit and I get quick action and contextual help at every step of my interaction with git.

[kelvinjps]

That's why I really like lazygit, I don't need to remember much because all the keymaps are shown in the UI. I like those kinds of Ui like whichkeys in neovim, or helix, or Doom Emacs.

[dec0dedab0de]

I just use my ide integrations for git. I absolutely love the way pycharm/jetbrains does it, and I'm starting to be ok with how vscode does. Remembering git commands besides the basics is just pointless. If I need to do something that the gui doesn't handle, I'll look it up and put it in a script.

[shiroiuma]

>I am convinced that the vast majority of professionals simply don't bother to remember and, ESPECIALLY WITH GIT, just look stuff up every single time the workflow deviates from their daily usage

Partly that, but for me at least, I have a bunch of simple bash scripts and aliases for things I do frequently. Git makes this really easy because you can set aliases for lots of custom commands in the .gitconfig file.

[ngruhn]

I don't even think git cli UX is that bad. Didn't git pioneer this sub-command style? Much better than like e.g. ffmpeg. Sure some aspects are confusing. I still don't understand why `checkout` is both for changing branches and clearing uncommitted changes. But overall I think the tool is amazing. I've not observed a bug in git once.

[skydhash]

> I still don't understand why `checkout` is both for changing branches and clearing uncommitted changes.

Because `checkout` is for getting the working directory to the state of a specific revision. Which both means switching branches (which are just pointer to revisions) and clearing changes (and get back to the starting revision). In both cases, you "check out" the version of the file at a specific commit or HEAD.

[jcynix]

> Didn't git pioneer this sub-command style?

No, various other tools used it before git, e.g. openssl.

[ngruhn]

sure but it certainly popularized it

[twohaibei]

`git change` can switch branches too if thats easier to grasp :)

[neonstatic]

I think this is where LLMs shine. I experience the same difficulty with a lot of command line tools, .e.g find is a mystery to me after all these years. Whatever the syntax is, it just doesn't stick in my memory. Since recently I just tell the model what search I want and it gives me the command.

[awesome_dude]

The relevant XKCD comic https://xkcd.com/1597/

FWIW I too was once a "memorised a few commands and that was it" type of dev, then I read 3 chapters of the Git book https://git-scm.com/book/en/v2 (well really two, the first chapter was a "these are things you already know") and wow did my life with git change.

[weedhopper]

I’ve recently been looking into some tools that provide quick or painless help like pop up snippets with descriptions and cheat sheets, got any recommendations?

[arcanemachiner]

Navi is good for generating personal cheatsheets:

https://github.com/denisidoro/navi

But for Git, I can't recommend lazygit enough. It's an incredible piece of software:

https://github.com/jesseduffield/lazygit

[rusted_gear]

I've found tldr to be useful

https://github.com/tldr-pages/tldr

[alwillis]

Cheaters: https://brettterpstra.com/projects/cheaters

[FergusArgyll]

Just handroll one, I wrote one in python, use an sqlite db, call out to fzf and voila you have the perfect tool. Codex can prob one shot it

[Cthulhu_]

I don't, I will google things and fiddle, then put it in a git alias (with a comment on what it does and / or where I got it from) and push it to my private dotfiles repo, taking it with me between computers and projects.

[dewey]

You research it once, use it and then remember that it has "ancestor" in the command somewhere and then use ctrl + R to dig up something from your shell history.

[dzaima]

jj's template and revset languages are very simple syntactically, so once you're comfortable with the few things you do use often it's just a question of learning about the other existing functions (even if only enough to know to look them up), which slot right in and compose well with everything else you know (unlike flags which typically have each their own system).

Or, perhaps better yet, defining your own functions/helpers as you go for things you might care about, which, by virtue of having been named you, are much easier to remember (and still compose nicely).

[jiggunjer]

Really, I got stuck trying to commit all files except those containing the string abc. As for revsets it's not easy to grab a single branch?

[usrbinbash]

> I don’t understand how people can remember all these custom scripting languages.

We can't.

Why do you think the `man` command exists?

[yujiachen]

Same here, so I wrap the post into an agent skill. Hope I can use them next time. https://github.com/yujiachen-y/codebase-recon-skill

[limaoscarjuliet]

Some things are idioms that one repeats so often they just stick, e.g. I use "grep.... | cut -c x-y | sort | uniq -c | sort -nr" to quickly grep frequency of some events from a log file.

Don't feel bad - no one remembers them all, we just remember a few idioms we use...

[mgfist]

Same, but now with AI I don't have to remember that anymore

[awesome_dude]

For now - the law of enshittification means that the free/cheap access to AI will be curtailed soon enough.

[mgfist]

Pretty much any OS locally runnable LLM can generate this stuff.

[gspr]

You and me both. Git is just so prevalent and fundamental to so much these days that I forced myself to use only a cheat sheet lying on my desk until I could comfortably use a reasonably productive subset by memory. Little did I know that that would make my colleagues think I'm some sort of git sage.

But jq I use maybe once a week, and it just won't stick. Same for any git features beyond basic wrangling of the history tree (but, on the flip side, that basic wrangling has eliminated 99% of the times I have to look things up).

[drob518]

Nobody does. One person figures it out, then writes a blog post, and we all Google for it. Even git’s man pages are long and sometimes cryptic.

[robrain]

If I look something up twice, I record it in Obsidian. If I need it more than a couple of times, I'll probably make an alias, a script or a mask [1] file. Autocomplete and autosuggest are essential to my workflow. And good history search.

[1] https://github.com/jacobdeichert/mask

[SoftTalker]

Yeah especially with git. All I know is pull, add, commit, push. Everything else I have to look up.

[TheRealPomax]

If you don't have to codedive new projects all the time, there's zero reason to memorize these. If your job is to look at new codebases all the time, you probably learn to remember these commands pretty quickly.

[Fokamul]

You add them into your GIT config file as shortcuts?

If you have multiple machines (/must have), just apply your user config to current machine?

[TeMPOraL]

People naturally remember what they use frequently. For things they use infrequently, they search on-line and/or read the friendly manual.

And yes, I'm also ecstatic when I manage to iterate over anything in `jq` without giving up and reaching for online reference. For `git`, functionality I use divides neatly into "things I do at least every week or two" and "things that make me reach for the git book every single time".

I mean, that was true until ~year or so. Now, I just have an LLM on speed dial. `howto do xyz in $tool`, `wtf is git --blah`, `oneliner for frobbing the widget`, etc.

[michaelcampbell]

`jq` and `ffmpeg` were two of my very early uses of LLM's for daily ease.

[PapstJL4U]

lazygit helped me to get more into different git commands - I still don't know them by heart. but at least I use more git has to offer.

and when a new branch is one key stroe away from being created, I am more inclined to use it.

[NoSalt]

So, how does one iterate over an array in jq? Asking for a friend.

[wwader]

Assume input is an array you can do it several ways depending on what you want:

    # output each value in the array separately 
    .[]

    # output each value but transform it in some way
    .[] | . * 2


    # map each value into a new array
    map(. * 2) 

    # same as above but manual iterate/collect
    [.[] | . * 2]

[socalgal2]

a project isn’t dying because of no commits. Rather it’s stable

I often feel I need to setup bots to make superfluous commits just to make it look like my useful and stable repos are “active”

One example (not mine) a a qr-code generator library. Hasn’t been updated in 10 years. It’s perfect as is. It just provides the size and the bits. You convert those bits to any representation you want. It has no need to be updated

[wredcoll]

It's rare, I think, for a project to have such a well defined and singular purpose that has not changed in 10 years nor have any bugs been discovered or its dependencies changed underneath it.

It's not impossible, of course, but if I saw even a qr library that hadn't changed in 10 years I would worry that it wouldn't build on current systems (due to dependencies) and that nobody was actually using it (due to lag of bug reports).

[latexr]

I have several of those projects. I avoid dependencies as much as possible, striving to only use things which I know ship with my target OS. I code for a level of correctness and longevity. That benefits everyone, including myself.

A QR (or barcode) library is exactly the type of thing I’d assume would still work fine, since there’s nothing new to do, the parsing rules don’t change, it’s a static, known, solved problem.

[robinsonb5]

> A QR (or barcode) library is exactly the type of thing I’d assume would still work fine, since there’s nothing new to do, the parsing rules don’t change, it’s a static, known, solved problem.

I agree with you - and yet the barcode library I used recently for a variable-data-printing project was last updated 13 hours ago, despite having been around since 2008!

[xp84]

Well said. Even an awesome library with no bugs that has no external dependencies still depends on the stdlib. For a while, before we were using containers, we even had the issue on Mac dev machines especially, where a half dozen Rubygems would crash while building its C extensions if your Mac OS version wasn’t just what the author expected, due to changes in the compiler shipped by Apple. So a MacOS major update might on its own functionally break a gem, even if the gem itself was designed well and you were using the same Ruby version.

[saila]

This might be true for libraries or utilities that have a well-defined scope and no dependencies, but that's not what the article is focused on. When considering a company's main product, it's usually never done and patterns of activity—and especially changes in those patterns—can give you insight into potential issues.

[fishpen0]

In a real company? A private codebase at a minimum should still be getting regular security patching and dependency updates. Always eventually one of those updates requires some level of refactor. If I see a project with no commits, I run away.

[latexr]

> a project isn’t dying because of no commits. Rather it’s stable

Agreed. Assuming there are no open issues and PRs. When I find a project, if the date of the last commit is old, I next look at the issues and PRs. If there are simple-to-deal-with issues (e.g. a short question or spam) and easy-to-merge PRs (e.g. fixing a typo in the README) which have been left lingering for years, it’s probably abandoned. Looking at the maintainer’s GitHub activity graph should provide more clues.

> I often feel I need to setup bots to make superfluous commits just to make it look like my useful and stable repos are “active”

I have never done it, but a few times thought about making a “maintenance” release to bump the version number and release date, especially since I often use a variant of calendar versioning.

[dcre]

Saw all the replies crying over how verbose these are, clicked through to TFA expecting to see simpler commands. Nope, they're basically the same thing, just slightly shorter. I would never memorize either the jj or git versions if I planned to use them regularly; I'd make aliases.

[WolfeReader]

This is the only sane reply on this entire comment tree.

To me, the verbosity of both Git and JJ commands to do these things are an indication that neither of these tools are meant to do them.

[AlexeyBelov]

crying over? Let's not be confrontational. I could say you're "crying" with this comment, but is that a good thing to say?

[dcre]

Come on.

[newsoftheday]

I don't want to program git, I want to get stuff done so I would reject using that tool and do what the article author did running tried and true pipeable Linux/UNIX commands. It's also the same reason why I dislike Gradle and use Maven, I don't want to program my build I want to define and run my build.

[nine_k]

But the git commands in the article is also programming of the same kind, just using more terse, more obscure language. All the shell pipelines are sort, uniq, and grep.

A language that properly maps to the data model, and has readable identifiers is a boon. Git is a database, a database needs a proper query language.

[gib444]

Hah someone really looked at jq (?) and thought: "yes, more of this everywhere". I feel jq is like marmite (edit: aka vegemite, i.e. "you either love it or you hate it")

[maleldil]

It's really not that bad, although the jq comparison might be apt. You have such primitives you need to understand, and then everything just fits together nicely. I find this much easier to write and understand than git's cryptic format strings.

Disclaimer: I love jq too :)

[plandis]

It doesn't seem any more egregious than something like:

`git log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --`

Which is something I see a lot of people alias in Git for viewing logs.

[skydhash]

> `git log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --`

If you remove the rainbow specification, it should be

  git log --graph --pretty=format:'%h -%d %s (%cr) <%an>' --abbrev-commit --

And most programmers are used to C style formatting.

[okkdev]

Cool! Thanks :) Jujutsu is such a nice tool. I don't understand why everything has to be so divisive nowadays. Enjoy the tools you like.

[NamlchakKhandro]

Didn't ask for it thanks

[cynicalsecurity]

Not interested, thank you.

[faangguyindia]

I can't remember all of this, does anyone know of any LLM model trained on CLI which can be run locally?

[lamasery]

If you copy those commands into a file and use that file to prompt the “sh” LLM.

[stingraycharles]

That works until you need a small variation of any of these commands and you’re lost.

[fainpul]

Try https://cheat.sh/

[esafak]

Not a model, but a product: warp.dev