logoalt Hacker News

Highlights from Git 2.54

117 pointsby ingvelast Monday at 5:29 PM66 commentsview on HN

Comments

ajoberstarlast Tuesday at 1:02 AM

Nice to see some seemingly jujutsu inspired features getting into Git core.

  git history reword ~= jj describe

  git history split ~= jj split
https://git-scm.com/docs/git-history

https://www.jj-vcs.dev/latest/cli-reference/#jj-describe

https://www.jj-vcs.dev/latest/cli-reference/#jj-split

show 4 replies
optionalsquidtoday at 4:40 PM

Support for config based hooks is very nice.

Only a few days ago, I was just looking for some way to automatically check (and fail) if there are inactive hooks when I try to commit. I already use `advice.ignoredhook`, but it's easy to miss the warning if you commit through VSCode, and possibly through other IDEs.

With this, I can just write a simple script to perform that check, and add it to my global config

the_duketoday at 4:51 PM

Config based hooks seem to miss the mark though?

The per-repo config is in `.git/config`, so that can still not be checked into the repo itself, unless I'm missing something?

So not very useful at all...

I get the security implications, but there could be a checked in `$REPO/.githooks`, and a prompt asking to allow running those hooks , with an approval marker being stored inside `.git/`.

ufotoday at 12:06 PM

I have always had this problem with hooks and new contributors: since hooks don't run by default if you just clone the repository, my open source projects get many PRs from new contributors that did not run the linting and commit hooks. I understand there's a security reason for this but what workflows have worked best for you to get everyone to run the hooks? And do you think the new config-based hooks can help new contributors?

show 9 replies
charles_ftoday at 2:45 PM

git history makes me think of git revise^1, which gives you a bunch of handy tools to changes your history, move commits around, remove some of them, cut them (which git history now does). I found it very handy in the past

1: https://git-revise.readthedocs.io/en/latest/man.html

WhyNotHugotoday at 12:58 PM

The new additions to `git add -p` seem pretty neat. Staging changes with `-p` is seriously underrated!

jinushauntoday at 1:05 PM

`git history reword` is great. Using `git rebase -i` just to fix a spelling error is overkill and doesn’t actually do what I want.

show 1 reply
everybodyknowstoday at 3:21 PM

> ... rewrites any descendent branches to point at the updated history.

But what about local heads referred to only by a "soft" tag? Is their history rewritten, or is it left to refer to the old history?

greg_dctoday at 1:21 PM

Those new git history commands will save me an average of maybe a minute a day, but it's still definitely handy nonetheless! After 2 months, that's an hour back!

The git log -L change is nice to see as well. Anything that makes git more filterable gets my vote.

samtrack2019last Monday at 6:27 PM

the new git history command seems to be useful for quick reword, altho since i use lazygit/magit i don't really see much of a problem to me

show 1 reply
Rover222today at 1:25 PM

I do almost no direct git work myself these days. Using claude in Conductor. Working on a team. I'll tell claude what do do in git sometimes, but there doesn't seem to be much need to do it myself anymore, even with complicated rebases, reflogs, etc.

show 1 reply