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

91–98 of 98 posts

Re: Highlights from Git 2.54

#91

Post by baq »

wakawaka28 wrote: post #89
baq wrote: post #88

Earlier quoted context omitted.

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.

> rebase workflow is ergonomic enough for the amount of splitting or rewording anyone realistically needs

The point is this is perhaps true for you but most definitely not for others. there’s a Jevon’s paradox-like mechanic at play here which you can’t see if your axiom is ‘I don’t need this.’

Re: Highlights from Git 2.54

#92

Post by IshKebab »

locknitpicker wrote: post #56
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, (...) 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 basele…

I would say probably joint worst are:

1. The way you delete things is just incomprehensibly inconsistent.

2. Naming of things is sometimes massively more confusing than it should be. Index? Why not "draft"? Ours/theirs presume some kind of ownership that doesn't exist, and they flip around depending on what command you're doing. To be fair a lot of the naming is decent.

3. The messages the CLI prints are unnecessarily obscure. They presume expertise without being friendly. For example look at the error you get from a submodule update where the commit can't be found. Does it say "Error: submodule points to but that commit was not found on the remote. Was it pushed?". No it does not. (I can't remember the exact message but I remember thinking how awful it was.)

Re: Highlights from Git 2.54

#93

Post by immanuwell »

git history is a genuinely welcome addition - rebase -i has always been a sledgehammer when sometimes you just need a scalpel, and it's nice to see git finally acknowledging that not every history edit needs to be a whole production

Re: Highlights from Git 2.54

#94

Post by codethief »

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 understand there's a security reason for this

While I understand the security concerns, too, wouldn't this be solved by including a `trust` command like in direnv and mise? (I.e. have the user review the hooks before executing them for the first time.)

Re: Highlights from Git 2.54

#95

Post by krzyk »

jayd16 wrote: post #75
krzyk wrote: post #70

Earlier quoted context omitted.

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.

LFS hooks are not just a convenience, for example. CI, despite being a useful thing in its own right, is not a replacement.

Fair, I don't use LFS so I don't know how it works.

I was writing more in regards of hooks as "checks" for workflow/lints/etc.

Re: Highlights from Git 2.54

#96

Post by Razengan »

Is there any simple non-hacky way to "save" a snapshot of the working state, without clearing the working state like `stash` does?

I sometimes go in too far deep with a bunch of changes that should be committed separately but need to be worked on together, and I need to save it occasionally in case of data loss etc, and the only way I have/know is the good old "compress entire folder to a .zip"

Re: Highlights from Git 2.54

#97

Post by sharts »

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…

Use a dev container

Re: Highlights from Git 2.54

#98

Post by crote »

jayd16 wrote: post #61
crote wrote: post #57

Earlier quoted context omitted.

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

In one case you are asking Git to run untrusted and unvetted code from a repository of unknown provenance you just cloned - without any kind of branch restrictions or sandboxing. Oh, you clone and check out a branch of some random leftpad fork you come across? Sure, let's immediately run their post-checkout shell script! It's like automatically running "curl | sh" on every random website you visit.

In the other case the repo owner itself is asking it to run pre-vetted code in a controlled sandbox - and only for branches where it is explicitly enabled. It's like running "wc -l", in a sandbox, on mostly-trusted input files.

Post reply on HN