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

71–80 of 98 posts

Re: Highlights from Git 2.54

#71

Post by wakawaka28 »

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.

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 means use them. I happen to think git rebase is all you need. Giving people crutches to avoid using it just delays their enlightenment. But not everyone reaches enlightenment, it's true.

I don't think jj adds anything compelling over git either. But different strokes for different folks...

Re: Highlights from Git 2.54

#72

Post by wakawaka28 »

baq wrote: post #67
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.

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.

Re: Highlights from Git 2.54

#73

Post by BeetleB »

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.

By default, if you push to main/master, it marks those commits as immutable (you can still force change). You can configure this to other branches.

But ... is it really that different from git? You can always rewrite history in git, correct?

Re: Highlights from Git 2.54

#74

Post by [deleted] »

krzyk wrote: post #70
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…

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.

[deleted]

Re: Highlights from Git 2.54

#75

Post by jayd16 »

krzyk wrote: post #70
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…

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.

Re: Highlights from Git 2.54

#76

Post by codygman »

baq wrote: post #65
NewsaHackO wrote: post #50

Earlier quoted context omitted.

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

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

Re: Highlights from Git 2.54

#77

Post by jayd16 »

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.

That doesn't automate the maintenance of the hooks, doesn't handle cross branch differences, opens you up to all kinds of security holes because now it'll just do whatever the hook points to which is likely to be in the repo and not in some special higher scrutiny flow...

All the push back to making this system good just ensures its as terrible as the nay-sayers fear.

Re: Highlights from Git 2.54

#78

Post by adregan »

Excited for the new release!

Though looks like `git history split` won't yet replace my typical workflow:

    $ git rebase -i // with e on commit in question
    $ git reset HEAD~
    $ git add -p
As I can't edit the hunk.

`git history reword` will be handy once I wire up a script to pipe the log of recent commits through fzf for interactive selection (not sure if it's just me, but I prefer interactive selection over any other form of reference to a git hash).

And I bet I'll get some use out of `git rebase --trailer`.

Re: Highlights from Git 2.54

#79

Post by WorldMaker »

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 feel like a lot of this is an "elephant memory" problem, too. ("An elephant never forgets.") Git was built very quickly and its early CLI was intentionally rough. Git was originally built with the idea that it was going to be all "plumbing" and to leave the good UX decisions to whatever "porcelain" people wanted to use on top, with some even expecting that there might be multiple competing "official" "porcelain" CLIs. Eventually that debate got settled in the surprise way to some of the earlier decisions about git being plumbing-first in that eventually git picked up both the "plumbing" and the official "porcelain".

There's a lot of arguments that still seem to think of the git CLI before a lot of the porcelain projects started merging into git upstream. There's a lot of people that mostly only learned the plumbing tools and don't care for the porcelain projects. It certainly doesn't help that much of the best porcelain still isn't the default experience. You have to remember `git rebase -i` for the best porcelain rebase experience. You have to remember `git add -p` for the best porcelain add experience. (This article even indirectly hints at the silliness that the best interactive `git add` is `-p` for "pinteractive" because `-i` "interactive" was already taken by a weaker one.)

That said, a lot of the porcelain is there today to take advantage of. Git has improved significantly from its plumbing-first worst CLIs. `git checkout` finally got split into `git switch` and `git restore` and both of those are great. (And no longer marked "experimental", they are official daily-use approved porcelain now.)

That's also sort of the highlight of this post that a lot of the porcelain continues to improve. The UX of the git CLI isn't etched in stone. New, better commands are possible, and indeed are getting built by smart people, some of who even care about UX for themselves and their fellow developers. Git is no longer the rush project it once was. Git no longer sees itself as "plumbing-first" at the expense of the "porcelain".

It will just maybe take a while for more of the elephants to forget the past horror stories and befuddlement.

Re: Highlights from Git 2.54

#80

Post by NewsaHackO »

codygman wrote: post #76
baq wrote: post #65

Earlier quoted context omitted.

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

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.
Post reply on HN