Highlights from Git 2.28 • Hacker News Board

Re: Highlights from Git 2.28

#71

Post by WorldMaker » Mon, Jul 27, 2020, 10:31 PM UTC

bengale wrote: post #66

WorldMaker wrote: post #54

Earlier quoted context omitted.

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.

There's a lot of back and forth on the discussion, and summaries are included in the tops of almost all of the linked articles. In general, the name "master" branch was commonly used in proprietary git predecessor BitKeeper which almost all of the early git developers were familiar with [1] and it did use master in a master/slave meaning. (It had a concept of "slave repositories".) While git has never had a concept of "slave branches" and the meaning may very well have meant to evoke one of the other etymologies, the word was "in the air" because of BitKeeper, which did intend it in a master/slave relationship, so git is guilty by association if not guilty by intent. Which is fine, no one is suggesting git is guilty by intent, they are simply suggesting it is time now to do what early git developers failed to do and question the association (both associations, using the word simply because it was a word commonly thrown around in tech up to that point, and in the association of master with chattel slavery).

[1] Bitkeeper was the SCS that the Linux kernel had been using up to that point, and whose dropping of free licenses to open source projects like the Linux kernel was the immediate cause of the creation of both git and Mercurial.

Re: Highlights from Git 2.28

#72

Post by sildur » Mon, Jul 27, 2020, 10:31 PM UTC

romanoderoma wrote: post #69

WorldMaker wrote: post #54

Earlier quoted context omitted.

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

Americans have issues. A lot of issues to be honest. Add to the mix their fervor about what they think is right with their utter disregard about what the rest of the world has to say about it, and you will get an interesting recipe for neocolonialism.

Re: Highlights from Git 2.28

#73

Post by chrisshroba » Mon, Jul 27, 2020, 10:38 PM UTC

yboris wrote: post #26

I like that you can change `git init` to have a different default branch name. At work we've renamed all `master` branches to `main`

Just curious - what reasons do people have for not using master?

Re: Highlights from Git 2.28

#74

Post by WorldMaker » Mon, Jul 27, 2020, 10:39 PM UTC

sildur wrote: post #70

WorldMaker wrote: post #54

Earlier quoted context omitted.

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.

> In the rest of the world is not as problematic, as we associate master with teacher.

Every word has more than one association. The argument is not that every association for the word is negative, but that one association is extremely negative, and we have the ability to use words that have fewer negative associations, so why shouldn't we use words with fewer negative associations?

That extremely negative association certainly isn't unique to the American past either, and if you think you are immune you are likely ignoring your own past. It's maybe being promoted by Americans because Americans see it as a more recent part of their past, still are wary of scars left behind from it. (Though even that isn't uniquely American; South African Apartheid is another easy example of recent history.)

Re: Highlights from Git 2.28

#75

Post by u801e » Mon, Jul 27, 2020, 10:42 PM UTC

jancsika wrote: 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…

If you use vim, you can do this within vim:

  :r !git log

find the log entry you're interested in, move the cursor over the sha1 value, type yiw to yank it into vim's " register (by default). Then open a new window by pressing ctrl-w n.

In that window run

  :r !git show

where will retrieve the sha1 value you yanked into the " register.

It's fewer steps, doesn't require using the mouse, and allows you to see both the git log output and git show output in different adjacent windows. You can always press u to undo the change in the new window, switch windows to get back to the git log output, find another sha1 and repeat the process.

Re: Highlights from Git 2.28

#76

Post by jayd16 » Mon, Jul 27, 2020, 10:42 PM UTC

lilyball wrote: post #60

jayd16 wrote: 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…

> 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. Git settings can do a lot, including running arbitrary commands. Having this set up automatically is a massive security issue. Put a script in your repo somewhere and instruct people to run the script after cloning. > Why…

>Because the configuration may be different from machine to machine

This is the crux of the issue. I want something to ensure turn-key configuration in a secure and cross platform way.

Maybe github/gitlab could generate something like an installer script instead of just a clone url.

Re: Highlights from Git 2.28

#77

Post by daigoba66 » Mon, Jul 27, 2020, 10:44 PM UTC

pojntfx wrote: post #2

I wonder about which primary branch naming convention they’ll arrive at. “primary” is my personal favorite ;)

I’ve migrated several repositories from mercurial, and didn’t bother to rename “default”. It works perfectly fine and no one is ever confused.

Re: Highlights from Git 2.28

#78

Post by WorldMaker » Mon, Jul 27, 2020, 10:48 PM UTC

romanoderoma wrote: post #69

WorldMaker wrote: post #54

Earlier quoted context omitted.

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

Bitkeeper, which early git developers were familiar with, did use master in a master/slave relationship. While git does not enforce such "hierarchy", there remains an association (both in how we use the word outside of the context of git as well as historically in how the word was used by predecessor SCSes).

> master/slave has been with us since forever

"Tradition" or "we've always done it that way" is not a great excuse, especially when part of the problem is systemic papercuts. It's not surprising that systemic issues rely a lot on "tradition" to do their dirty work.

Whether or not you agree with the particular etymology/association being questioned, the very point of questioning it is whether or not this "tradition" is worth the pain of systemic papercuts. We've got a lot of other useful words, we don't have to keep using ones that cause papercuts just because of "tradition" (whether or not you personally suffer from those papercuts).

Re: Highlights from Git 2.28

#79

Post by mbakke » Mon, Jul 27, 2020, 11:11 PM UTC

neves wrote: 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?

As someone doing lots of merges in a big and active project, git rerere has saved me hours whenever I need to redo a complicated merge.

It's not at all new according to a quick grep of RelNotes, but I only recently discovered it, so it is new to me.

Re: Highlights from Git 2.28

#80

Post by merb » Mon, Jul 27, 2020, 11:16 PM UTC

neves wrote: 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 switch/git switch -c so much better than git checkout and the confusing switches.