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

51–60 of 98 posts

Re: Highlights from Git 2.54

#51

Post by jayd16 »

lou1306 wrote: post #48
jayd16 wrote: post #46

Earlier quoted context omitted.

This is very much not a serious solution. Look at the case of LFS. LFS needs an install step and it needed to be brought into git itself to cut through all of the problems. Manually managing hooks is not sufficient. No amount of "please don't fuck it up" in the readme is going to save you. Even CI checks for what should and shouldn't look like an lfs stub is non-trivial. I don't think such a thing even exists today.

The alternative is have hooks _forcibly_ run on people's machines, which is fantastic as an attack vector and CVE generator but probably not a good choice in other respects.

No there are a million miles in-between no support/Don't use it and arbitrary code execution.

Signed git plugins and manifest or a canonical way to define hooks in repo that most tools can interface with and allow the user to automatically set up but asks to do so or really so much more.

I don't know why people get fixated on this as if 99.999% of what git pulls down isn't code you expect to run and there are systems in place to protect that.

Re: Highlights from Git 2.54

#52

Post by n_e »

jayd16 wrote: post #39
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.

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 ab…

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

Because we want to be sure that the checks have passed, and that they have passed in a clean environment.

Contributors can, in addition, use git hooks, or run tests in watch mode, or use their IDE.

Also it's annoying to have slow git hooks if you commit often.

Re: Highlights from Git 2.54

#53

Post by jayd16 »

numbsafari wrote: post #47
jayd16 wrote: post #35

Earlier quoted context omitted.

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?

Tools growing unexpected code execution is how we keep having problems with secrets and other important things being stolen. If you add this feature to git, generally, then anybody cloning a git repo is going to have to deal with the fact that `git clone` might run arbitrary code. `git clone` is like `cp`. Do you want `cp` to unexpectedly run code? It should never do that. Why force git to be a build tool? Just docum…

Git is already a build tool and LFS is a great example of something git should be able to do and is also an example of how bolted on these things feel because of pointless push back in talking about a real solution.

You don't need to bring up bad ideas as if it precludes the existence of good ideas. Let's talk about good ways to solve these problems and improve the tool.

Re: Highlights from Git 2.54

#54

Post by locknitpicker »

roblabla wrote: post #8
aulin wrote: post #4

Earlier quoted context omitted.

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?

jj describe gives a name to a commit. In jj, everything rewrites the history, so there's no real point in calling it out in the command name since it's just the default behavior.

> In jj, everything rewrites the history (...)

Surely that isn't true, otherwise it would be completely unusable for auditing.

Re: Highlights from Git 2.54

#55

Post by chrishill89 »

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

Yeah it’s a direct inspiration.

Re: Highlights from Git 2.54

#56

Post by locknitpicker »

IshKebab wrote: post #36
wakawaka28 wrote: post #34

Earlier quoted context omitted.

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…

> It's very widely remarked that the Git CLI is pretty miserable, (...)

You hear some very vocal critics expressing hyperbolic personal opinions on the topic, but I find that in the majority of the cases the opinions aren't objective or grounded on reality. It's just people whining.

The litmus test is asking what is the worst example of this "pretty miserable" CLI they talk about. More often than not it's just baseless nitpicking. I recommend you give the litmus test a try to see how far this myth flies.

Re: Highlights from Git 2.54

#57

Post by crote »

jayd16 wrote: post #39
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.

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 ab…

You're looking for a technological solution for a human problem.

Automatically running arbitrary code from random repositories is a Really Bad Idea, so Git will almost certainly never auto-install pre-commit hooks. Just mention it in the README and run a checker in CI to confirm they are using it, it really isn't that difficult.

People wasting 2 minutes of their own time once during their first contribution because they didn't read the README is not that big of a deal. What's next, you want a script to automatically sign a project's legally-binding CLA on checkout?

Re: Highlights from Git 2.54

#58

Post by locknitpicker »

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.

> By running the linters and any other checks on CI instead.

Running linters on CI is an antipattern if there was ever one. That and configuring pipeline runs to fail for linting issues.

Sometimes some people just want to create their own problems. Configuring the editor solves most of the problems, and hooks add a failsafe. Once the code is committed, it should be immutable.

Re: Highlights from Git 2.54

#59

Post by optionalsquid »

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

Re: Highlights from Git 2.54

#60

Post by chrishill89 »

IshKebab wrote: post #36
wakawaka28 wrote: post #34

Earlier quoted context omitted.

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…

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

This command is implemented by just one single (but prolific) contributor. His own idea.

Post reply on HN