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

61–70 of 98 posts

Re: Highlights from Git 2.54

#61

Post by jayd16 »

crote wrote: post #57
jayd16 wrote: post #39

Earlier quoted context omitted.

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

You're talking out of both sides of your face here. It's dangerous and also it's super easy and you should do it first thing without having to think because it's so easy. You shouldn't run this code but also the build machine automatically runs it.

We already know we're definitely going to run some of these. We know we want to maintain changes to these hooks. Can we stop pretending like we're not doing that? We get it. Some of these will be untrusted so let's design a system to handle that instead of not designing a system and deciding to be just short of as unsafe as possible.

Automation an uniformity increases safety. Human intervention increases human error. Its just a matter of actually finding a good solution to know what is trusted but instead we get "just set it up manually because its safer."

Re: Highlights from Git 2.54

#62

Post by NekkoDroid »

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 wish that git would auto check for a `.githooks` directory in the repo root and prompt on first clone if the `core.hooksPath` should be changed for this repositry and when pulling any tracked file in hooksPath causes a warning (though this still leaves out the case that some hook just invokes a script in the repo outside the dir).

Re: Highlights from Git 2.54

#63

Post by jbverschoor »

jayd16 wrote: post #35
jbverschoor wrote: post #30

Earlier quoted context omitted.

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?

Yes that’s perfectly fine of course. But these days that’s not so common

Re: Highlights from Git 2.54

#64

Post by NekkoDroid »

jauntywundrkind wrote: post #44
jinushaun wrote: post #19

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

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.

Re: Highlights from Git 2.54

#65

Post by baq »

NewsaHackO wrote: post #50
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

jj is a "unofficial" Google project that one has to sign a Google CLA to contribute to. I don't think it would be a good idea to trust/transition to a system like that from git.

what has one to do with the other...?

Re: Highlights from Git 2.54

#66

Post by baq »

locknitpicker wrote: post #54
roblabla wrote: post #8

Earlier quoted context omitted.

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.

it is true. some history is marked immutable by default; in git, everything is mutable by default and you have to add branch protection on the server side. (granted, you can change what is immutable in jj relatively easily, so you shouldn't ignore branch protection if you're using jj exclusively with a git repo, either.)

Re: Highlights from Git 2.54

#67

Post by baq »

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.

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

Re: Highlights from Git 2.54

#68

Post by the_duke »

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

Re: Highlights from Git 2.54

#69

Post by kps »

locknitpicker wrote: post #54
roblabla wrote: post #8

Earlier quoted context omitted.

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.

It's not true, in that sense. Commits in jj are basically the same as commits in git as far as mutability is concerned. But in jj you normally work with changes, rather than commits, and open changes are mutable (by altering which immutable commit they point to in the backing store). And there is effectively an append-only audit trail of these alterations (which is what makes `jj undo`/`jj redo` simple).

Some comments here are confusing the issue by saying ‘commit’ when they mean ‘change’ in the jj sense.

Re the grandparent comment, `jj describe` provides a change description, analogous to `git commit --amend --edit` in git terms.

Re: Highlights from Git 2.54

#70

Post by krzyk »

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…

Local hooks are just a convenience. CI checks are assurances, you have to have them.

If one hates the round-trip he/she will adopt hooks quickly.

Post reply on HN