Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Highlights from Git 2.54

github.blog

Post reply on HN
Print view View original

81–90 of 98 posts

Re: Highlights from Git 2.54

#81

Post by WorldMaker »

ufo wrote: post #5

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…

Many projects have used "hook managers" like Husky for this to install hooks to run based on repository-stored metadata.

These new config-based hooks are definitely a step down the road towards obsoleting the third-party hook managers. One of the things they are for is for managing scripts to support multiple hooks for the same event. The new config format supports multiple hooks for the same event natively. (Which also helps in stacking personal ones versus repository ones.)

The only thing missing is that the repository's .git/config isn't itself source controlled in that repository, so for now there would still be an "install step", but it's now a lot simpler of an "install step" with the install being "append .example-gitconfig into your .git/config" rather than "set X files to X different contents in .git/hooks/*" where X is the number of event hooks to be concerned about.

It does open the door further to if there should be a ".gitconfig" in the Repository working tree that can also contribute repository-wide shared config, what config it can or cannot contribute, and how you secure that as a reviewable opt-in (especially change notifications). But a smartly built secure UX there would be a massive improvement over, say, shell scripts in npm postinstall operations touching .git/hooks "for you" (which is how many of the current hook managers auto-install, as side effects in dependency installs).

(ETA: Though most "install scripts" now just use the very scriptable `git config` command and so just be `git config set --local hook.$name.$field $value` sequences, which is also a simpler improvement over previous ways to install and/or merge hooks files by hooks managers.)

Re: Highlights from Git 2.54

#82

Post by WorldMaker »

NekkoDroid wrote: post #64
jauntywundrkind wrote: post #44

Earlier quoted context omitted.

Why doesn't it do what you what? I hate to be the worry wart, but I am worried folks are going to avoid `git rebase -i` even more now. It is such an excellent excellent UI in my opinion: it shows you the history of what is clearly, and let's you modify it as you please!

> Why doesn't it do what you what? If you have anything else branching/referencing a commit after the reword commit that isn't part of the branch you are rebasing you now have all those references still pointing to the old commit and need to go through every one of them to fix them.

Which is a reminder that maybe `--update-refs` should be the default for `git rebase -i`. It's great that it is now going to be the default for both `git replay` and `git history`, and I know why git is conservative in updating defaults, but at some point there's a benefit to updating the defaults. (I'd also argue that `-i` itself should have long been the default for `git rebase`. Also, while we are at it, probably `--autosquash` should be default.)

Re: Highlights from Git 2.54

#83

Post by WorldMaker »

the_duke wrote: post #68

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/`.

This seems to be a first step in that direction, though. Merging repo suggestions into one per-repo `.git/config` is still a big improvement over N `.git/hooks/$EVENT` files. Plus the new config format is directly mergeable, whereas the old hooks files often weren't without extra work (they had to point to one and only one shell command, which might be an arbitrary binary rather than a mergeable shell script; hence why "hooks managers" are as much shell script managers as hooks file maintainers and often were generally mutually exclusive/do not cooperate).

Obviously it still leaves the door open if there should be a `.githooks` or `.gitconfig` file in the committed worktree that can suggest changes to `.git/config` with fewer manual steps, but this first effort in minimizing the number of manual steps and simplifying those manual steps to a simpler merge is still quite useful.

Which is also before pointing out that the `git config` command is already quite scriptable as a simple merge tool. You could in theory replace a "hooks manager" install script with just a sequence of `git config set --local hook.$name.*` lines. You still have to figure out how to get the user to run that script just like installing any other hooks manager, but that's an easy script now to write.

Re: Highlights from Git 2.54

#84

Post by semanticc »

ajoberstar wrote: post #3

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

It's not documented, but unfortunately neither of these re-signs the commits even if GPG signing is configured. They are based on `git replay`, and that doesn't sign either (at least yet).

Re: Highlights from Git 2.54

#85

Post by gucci-on-fleek »

NewsaHackO wrote: post #80
codygman wrote: post #76

Earlier quoted context omitted.

I'll consider avoiding jj because of this, personally.

It's always the first step. The second step would be switching the license and only supporting the changed licensed version, then "donating" the unmaintained version to the community.

Has Google ever done this before though? I'm not much of a fan of Google either, but they tend to just abandon products outright rather than relicence them.

Re: Highlights from Git 2.54

#86

Post by tredre3 »

wakawaka28 wrote: post #71
IshKebab wrote: post #36

Earlier quoted context omitted.

I don't know if it was meant to be a dig but I hope you don't think the fact that Git was a big advancement on SVN means it doesn't deserve any criticism. It's very widely remarked that the Git CLI is pretty miserable, and as soon as a better (so I hear) alternative comes along they suddenly realise and start improving it... This happens all the time in software. Some software has crap UX or missing obvious features…

>It's very widely remarked that the Git CLI is pretty miserable, and as soon as a better (so I hear) alternative comes along they suddenly realise and start improving it... This happens all the time in software. I don't think these claims have merit, for the most part. More often than not, people just don't take any time to learn git, then get on a soapbox about it. If you think these commands are worthwhile, by all…

> people just don't take any time to learn git, then get on a soapbox about it.

That is true. However those same people that struggled for years with git are able to pick up jj and be very productive with no issue whatsoever, in a matter of days. So either:

1. jj is a lot more intuitive out of the box

2. or jj makes learning it fun, so more people do it

Whichever it may be, hopefully git can improve by learning from it and we all win. Don't you agree?

Re: Highlights from Git 2.54

#87

Post by Rover222 »

ramon156 wrote: post #42
Rover222 wrote: post #27

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.

I'd advise to do what you're doing, but to check the commands it runs and figuring out why it does these things. The first step is usally "what does git [command] do?" followed by `man git-[command]` and see what it does. That way you're still "blazingly-fast with your SOTA-LLM!!!" while also understanding why :)

huh? I know git commands. it's just a dead skill with LLMs. SQL too.

Re: Highlights from Git 2.54

#88

Post by baq »

wakawaka28 wrote: post #72
baq wrote: post #67

Earlier quoted context omitted.

and now git owes jj a couple ergonomic improvements. this is a net win for both.

I think this is cluttering git with a bunch of special-case commands when rebase is all you need. Next thing you know, people will say we need to drop git because there are 5 ways to do everything.

Ah, the Dropbox comment. You don’t even need git for that matter, you can switch between filesystem snapshots.

The point is, ergonomics matter. Rebase is not ergonomic for splitting commits.

Re: Highlights from Git 2.54

#89

Post by wakawaka28 »

baq wrote: post #88
wakawaka28 wrote: post #72

Earlier quoted context omitted.

I think this is cluttering git with a bunch of special-case commands when rebase is all you need. Next thing you know, people will say we need to drop git because there are 5 ways to do everything.

Ah, the Dropbox comment. You don’t even need git for that matter, you can switch between filesystem snapshots. The point is, ergonomics matter. Rebase is not ergonomic for splitting commits.

That is an absurd straw man. The point is, rebase workflow is ergonomic enough for the amount of splitting or rewording anyone realistically needs. Furthermore, knowing rebase is essential for things that these new tools can't do. It's best for people to use one familiar tool for everything IMO.

Re: Highlights from Git 2.54

#90

Post by wakawaka28 »

tredre3 wrote: post #86
wakawaka28 wrote: post #71

Earlier quoted context omitted.

>It's very widely remarked that the Git CLI is pretty miserable, and as soon as a better (so I hear) alternative comes along they suddenly realise and start improving it... This happens all the time in software. I don't think these claims have merit, for the most part. More often than not, people just don't take any time to learn git, then get on a soapbox about it. If you think these commands are worthwhile, by all…

> people just don't take any time to learn git, then get on a soapbox about it. That is true. However those same people that struggled for years with git are able to pick up jj and be very productive with no issue whatsoever, in a matter of days. So either: 1. jj is a lot more intuitive out of the box 2. or jj makes learning it fun , so more people do it Whichever it may be, hopefully git can improve by learning from…

I think you should consider a third option:

3. After years of refusing to learn git and making excuses for their hate, the goobers finally buckle down and read the manual for a tool that coincidentally does stuff a little different from git. They leap at the opportunity to further blame git for their difficulties rather than themselves.

If there is a way git can be made to appease these people without making it horrible, then we should try to do it. But I still think these people would be better served by buckling down for a few hours to learn git as it was designed, because it is designed very well.

Post reply on HN