Live data from Hacker News

Highlights from Git 2.28

github.blog

61–70 of 147 posts

Re: Highlights from Git 2.28

#61
I'm a somewhat advanced user of Git. My coworkers use me as a reference when they have a problem of a difficult merge to solve.

I don't follow each Git release, but I also didn't notice a great productivity enhancement for a long time. Sure it is a sign of a mature project, but I'd like to know:

What's the somewhat recent Git feature that you really improved your productivity?

Re: Highlights from Git 2.28

#62
post #9

Someone please give me the missing link here: 1. I do `git log` which helpfully pipes to `more` where I can use vim-stsyle search to find the commit I'm interested in. 2. I find the relevant commit. 3. Now I want to `git show` that commit. Currently I double click on the human unreadable commit, copy it, quit `more` to get back to the command line, type `git show`, then paste the commit. Navigate, click-click, shortc…

I have a series of keybindings[1] for fish that use fzf to select from various git objects. One keybinding selects from commits. So with this I can type `git show ` and then pick the commit I want from the fzf interface.

[1] https://github.com/lilyball/fzf-git.fish

Re: Highlights from Git 2.28

#63
post #30

I just came back to git and gitlab from Perforce and while it's felt like coming home and some things are improving around submodules and LFS there's still a lot of rough edges I'd like to see smoothed over. Its not easy to set up git config settings for a distributed team. I assume for security reasons a repo can't configure its own settings just from a pull but even still I want that functionality. Why do I check i…

This is the sort of thing that a configuration management system like Ansible does. Consider deploying one to all managed devices.

Git itself is not the right place to have it because of the security issues with it, but if you can run Ansible or something similar then you have root on the system anyway.

Re: Highlights from Git 2.28

#64

Earlier quoted context omitted.

I use, and prefer "trunk" since I rarely use branches, but "canon" might change my mind.

I've been debating "mast" as it sort of evokes "trunk" in an amusing seafaring sort of way, and partly for the same reason a lot people like "main" because their muscle memory is "ma ". For several reasons my muscle memory at this point is "mast ", so "mast" is even a slight improvement over my muscle memory. But I'm not sure I'd get that much interest from other people to use "mast", it might just be something in my…

I've also been debating just calling it "default" since we always refer to it as the default branch anyway.

Re: Highlights from Git 2.28

#65
post #61

I'm a somewhat advanced user of Git. My coworkers use me as a reference when they have a problem of a difficult merge to solve. I don't follow each Git release, but I also didn't notice a great productivity enhancement for a long time. Sure it is a sign of a mature project, but I'd like to know: What's the somewhat recent Git feature that you really improved your productivity?

git restore

Re: Highlights from Git 2.28

#66

Earlier quoted context omitted.

Probably the ubiquitous "master".

It's the ubiquitous "master" that everyone is trying to get rid of. There are details in several of the linked articles. TL/DR: The master/slave analogy is problematic and lots of projects have decided we don't need that terminology around any more, when we can pick less problematic names easily (easier now that there is a config option for it without needing to create a full git init template).

That’s not the type of master that’s it’s referring to. But I’m not sure etymology really matters I guess.

Re: Highlights from Git 2.28

#67

Earlier quoted context omitted.

I've been debating "mast" as it sort of evokes "trunk" in an amusing seafaring sort of way, and partly for the same reason a lot people like "main" because their muscle memory is "ma ". For several reasons my muscle memory at this point is "mast ", so "mast" is even a slight improvement over my muscle memory. But I'm not sure I'd get that much interest from other people to use "mast", it might just be something in my…

I've also been debating just calling it "default" since we always refer to it as the default branch anyway.

Useful to know: the linked GitLab documentation points out several flaws with "default" as the name for a branch, in particular the cognitive association with financial default (a negative circumstance), which would make internationalization hard and while not as terrible an association and history as "master" still a bad association that now I've thought about it I cannot stop thinking about.

Re: Highlights from Git 2.28

#68
post #61

I'm a somewhat advanced user of Git. My coworkers use me as a reference when they have a problem of a difficult merge to solve. I don't follow each Git release, but I also didn't notice a great productivity enhancement for a long time. Sure it is a sign of a mature project, but I'd like to know: What's the somewhat recent Git feature that you really improved your productivity?

For the past few years the performance work (e.g. commit graph) has made a huge difference for large/fast moving repos. They're big enough to be productivity enhancements for some people: when we merged our Android-like multi-repo setup into a proper mono-repo we required updating git because things like git status/git commit/git log could take minutes without the recent perf fixes.

It pays to follow the release notes because some of these features are opt-in (e.g. commit graph is still optional).

The sparse checkout stuff is great but still too low-level for us to use, but it's laying the groundwork for something good.

Re: Highlights from Git 2.28

#69

Earlier quoted context omitted.

Probably the ubiquitous "master".

It's the ubiquitous "master" that everyone is trying to get rid of. There are details in several of the linked articles. TL/DR: The master/slave analogy is problematic and lots of projects have decided we don't need that terminology around any more, when we can pick less problematic names easily (easier now that there is a config option for it without needing to create a full git init template).

IMHO the only problem is what people wanna see in words.

master/slave has been with us since forever (https://news.ycombinator.com/item?id=23969906) and describes a relationship between two entities where one is the controller and the other is controlled, in many religions (including the most popular one) there is still a master God (or more than one) and believers are slave to God (with the capital G)

But in Git there is simply a "master" branch, there is no master/slave relationship, there is no hierarchy enforced, branches are just copies that diverged from the master copy, master as in master recording or "the source from which all copies will be produced"

I honestly have a hard time understanding what's problematic with it.

Re: Highlights from Git 2.28

#70

Earlier quoted context omitted.

Probably the ubiquitous "master".

It's the ubiquitous "master" that everyone is trying to get rid of. There are details in several of the linked articles. TL/DR: The master/slave analogy is problematic and lots of projects have decided we don't need that terminology around any more, when we can pick less problematic names easily (easier now that there is a config option for it without needing to create a full git init template).

In the rest of the world is not as problematic, as we associate master with teacher. But we are used to America forcing their culture down our throats. Like they did when tried to force down their hatred for the police on us. So, another one to the list. It would be nice if some day they tried to consider how the rest of the world sees things. For a change.
Post reply on HN