Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Highlights from Git 2.28

github.blog

Post reply on HN
Print view View original

51–60 of 147 posts

Re: Highlights from Git 2.28

#51

Post by sixstringtheory »

jimbobimbo wrote: post #45
JelteF wrote: post #39

Earlier quoted context omitted.

You can add a small script to your project that you tell people to run the first time after cloning. Then with that script you can setup everything you want. Such as symlinks to git hooks also stored in the repo (so that they stay up to date), or set up the merge tool that you want.

Our team had started a practice of "devbox setup" scripts in each repo a few years ago. They're invaluable. Instead of following pages of instructions in various state of decay, running just one script puts you into the ready state in a few seconds. Any questions about why something is not working has only one answer: run the setup script. Highly recommend this.

I love having idempotent makefile tasks that can do this kind of thing.

And as far as "pages of instructions in various states of decay," couldn't agree more that those aren't a good solution. I usually observe those instructions containing lots of terminal commands. I'd rather have those in an executable format, with commenting if explanation is needed. Then it's (usually, hopefully) pretty obvious where something breaks, instead of rotting instructions nobody can say 100% what is or isn't current.

Re: Highlights from Git 2.28

#52

Post by jrockway »

Twisol wrote: post #3
pojntfx wrote: post #2

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

I saw somebody on Twitter call theirs "canon", which I've really taken a liking to. It fits nicely in regular speech too :D

Is the most recent commit on this main branch called "HEADCANON"?

Re: Highlights from Git 2.28

#53

Post by romanoderoma »

Twisol wrote: post #38
solatic wrote: post #8

Earlier quoted context omitted.

Canon is excellent, but I fear it wouldn't catch on due to its religious origins / connotations.

I can appreciate that "canon" is used in religious contexts, but its meaning and origin go back further than that. Wiktionary (hardly the best source, I know) lists three secular meanings before the religious ones begin. The most relevant is this one: > A group of literary works that are generally accepted as representing a field. Also, the coinage "fanon" (as in derivative works by a fanbase) comes directly from the…

> but its meaning and origin go back further than that

master/slave goes back to Mesopotamia, 4 thousands years ago and was used to describe the relationship between men and gods

> Man was believed to have been created to serve the gods, or perhaps wait on them: the god is lord or master (belu) and man is servant or slave (ardu)

I guess being that old is not good enough nowadays

Re: Highlights from Git 2.28

#54

Post by WorldMaker »

globular-toast wrote: post #35
pojntfx wrote: post #2

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

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

Re: Highlights from Git 2.28

#55

Post by joshmanders »

eclipseo76 wrote: post #48
apetresc wrote: post #5

Earlier quoted context omitted.

Github has said the most popular one across all their repos is `main`, and that's what they'll be going with themselves. (Source: https://github.com/github/renaming )

I personally hope this won't catch on because some third party library still expect master to be the default branch. When main is used, I have to monkeypatch some script I use to work aroud it. edit: I fixed the script to use branch [0] instead of branch master (using GitPython).

Maybe you can fork them and submit a patch with the changes fixing it. :)

Re: Highlights from Git 2.28

#56

Post by stephenhandley »

Twisol wrote: post #3
pojntfx wrote: post #2

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

I saw somebody on Twitter call theirs "canon", which I've really taken a liking to. It fits nicely in regular speech too :D

I think quaid would be good, you know because of Randy Quaid and also because of Total Recall

Re: Highlights from Git 2.28

#58

Post by marvy »

Normal_gaussian wrote: post #34
arp242 wrote: post #25

Earlier quoted context omitted.

It's rather hard to type as it's switching hands a lot; both "master" and "main" are easier to type, and are also shorter (as least "main" would be an improvement in that sense; "primary" would be quite the regression IMO).

That is why the single handed "fred" branch shall be the beacon of all truth. Until it is accused of being sexist, or too western.

How about just "fed"?

Re: Highlights from Git 2.28

#59

Post by WorldMaker »

Normal_gaussian wrote: post #34
arp242 wrote: post #25

Earlier quoted context omitted.

It's rather hard to type as it's switching hands a lot; both "master" and "main" are easier to type, and are also shorter (as least "main" would be an improvement in that sense; "primary" would be quite the regression IMO).

That is why the single handed "fred" branch shall be the beacon of all truth. Until it is accused of being sexist, or too western.

Easily solved, keep it to the QWERTY home row and make it the "asdf" branch. Could even backronym it to something like All Saved Data Files, maybe.

Re: Highlights from Git 2.28

#60

Post by lilyball »

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 do I check in the name of the merge tool used for a file type in the .gitattributes but I can't check in what that name points to?

Because the configuration may be different from machine to machine. For example, one machine might have git-lfs installed in /usr/local/bin, another in $HOME/.nix-profile/bin/git-lfs. Similarly, the actual filters may be set up differently from machine to machine, e.g. one person might use `git lfs install` (to install globally) and another `git lfs install --skip-smudge --local` (to install locally to this repo, configured to skip fetching unknown objects on clone or pull).

> I work with less technical artists and they really don't want to think about git configs at all. They just want to save and push. As far as I know there's no solution to preconfigure a repo to pull submodules or set up custom merge drivers. Best thing I've found is to maintain repo setup scripts but its pretty cumbersome and you have to manually target the tools you want to support.

Skimming config right now, I do see a `submodule.recurse` flag which, if set, causes any command except `clone` that has --recurse-submodules to automatically recurse.

The aforementioned setup script could set this config flag and run `git submodule update --init -recursive` to clone the submodules too in case the user didn't pass --recurse-submodules to `git clone`.

Post reply on HN