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

31–40 of 98 posts

Re: Highlights from Git 2.54

#31

Post by sgarland »

Flimm wrote: post #17
IshKebab wrote: post #14

Earlier quoted context omitted.

As well , not instead. Just add `pre-commit run -a` to your CI. Job done. It's still annoying for new contributors though because they might not know how to set up pre-commit (which was quite a pain until recently because it's written in Python).

To clear up any confusion, Git runs pre-commit hooks, and they can be written in any programming language. There's a completely separate and independent project that gave itself the confusing "pre-commit" name, and it is written in Python. This project aims to make it easier to configure pre-commit hooks. An alternative to it is "prek", written in Rust.

Yes, and I hate it so, so much, and frankly don’t get the appeal. You want one-click installation of hooks? Bundle a shell script called run_first.sh that symlinks the hooks into .git.

Re: Highlights from Git 2.54

#32

Post by esafak »

ufo wrote: post #15
sethops1 wrote: post #6

Earlier quoted context omitted.

> what workflows have worked best for you to get everyone to run the hooks By running the linters and any other checks on CI instead.

We do run the linter on CI as well, but I think our comitters would get faster feedback if they ran those checks locally.

You can issue installation instructions on linter failure in CI.

Re: Highlights from Git 2.54

#33

Post by baq »

aulin wrote: post #4
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

Not familiar with jj and don't want to get into bike shedding, but how is describe supposed to be a good name for history rewrites?

in jj the history has mutable and immutable commits.

Re: Highlights from Git 2.54

#34

Post by wakawaka28 »

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

If this is meant to be a dig, you should keep in mind how much jj owes to git.

Re: Highlights from Git 2.54

#35

Post by jayd16 »

jbverschoor wrote: post #30
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…

I don't want you to run arbitrary hooks on my machine. As with CI/CD... your hooks should simply point to a script instead

Ok well what about when I pay you and give you a local machine to work on?

Can I pay you to run hooks on the work machine I own because it saves a lot of work on the share build machines? Can we talk about making that situation less error prone?

Re: Highlights from Git 2.54

#36

Post by IshKebab »

wakawaka28 wrote: post #34
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

If this is meant to be a dig, you should keep in mind how much jj owes to git.

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 (e.g. comments in package.json). People try and improve it but are rebuffed because the maintainers claim it's fine as it is. Effort goes elsewhere to a competitor project which starts to attract users. Maintains of the original project have a sudden and coincidental change of heart!

Re: Highlights from Git 2.54

#37

Post by IshKebab »

sgarland wrote: post #31
Flimm wrote: post #17

Earlier quoted context omitted.

To clear up any confusion, Git runs pre-commit hooks, and they can be written in any programming language. There's a completely separate and independent project that gave itself the confusing "pre-commit" name, and it is written in Python. This project aims to make it easier to configure pre-commit hooks. An alternative to it is "prek", written in Rust.

Yes, and I hate it so, so much, and frankly don’t get the appeal. You want one-click installation of hooks? Bundle a shell script called run_first.sh that symlinks the hooks into .git.

The pre-commit tool does way more than that. For example the clang-format hook will download and run a specific version of clang-format.

Re: Highlights from Git 2.54

#39

Post by jayd16 »

sethops1 wrote: post #6
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…

> what workflows have worked best for you to get everyone to run the hooks By running the linters and any other checks on CI instead.

Why waste a round trip, build time, loss of flow and CI machine queue wait time when you can catch things early?

CI should also run all the checks but CI checks are not a replacement for local hooks. LFS and things like it can't be implemented as remote CI checks.

Why are we acting like a James Bond villain, slowly lowering the changes into the vat of sharks after we've left the room? I want the hooks. Can we talk about making that easy, assuming some people want them?

Re: Highlights from Git 2.54

#40

Post by Sol- »

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…

I always considered hooks a nice to have feature for devs to already validate that their PRs will probably satisfy certain CI checks. If they don't install or run them for whatever reason, it's on them to do another iteration and update the code to make it mergeable if CI complains. So I usually considered it fine that they are only opt-in, since the merge will be gated by a CI outside of the dev's control anyway.
Post reply on HN