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`
Enslaved people will be so happy to hear these news!
Highlights from Git 2.28
41–50 of 147 posts
Re: Highlights from Git 2.28
#42Someone 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…
Just use vim, it even highlights the git log file:
$ git log | vim -
Inside vim search what you want with '/' When you find the commit you want put the cursor everywhere over the commit ID and run this normal mode command:
:!git show
You will be shown the diff in your default text view program (normally it's 'more' but can also be vimdiff), press when you finish and you will be sent directly to the place where you left off.
You can also remap this behaviour to any key/alias you want.
Hope this helped!
Re: Highlights from Git 2.28
#43Git now includes a GitHub Actions workflow which you can use to run Git’s own integration tests on a variety of platforms and compilers. There’s no extra effort required on your part: if you have a fork of git/git on GitHub, each push will be run through the array of tests necessary to validate your change.But wait: doesn’t Git use a mailing list for development? Yes, it does, but now you can use GitGitGadget on the git/git repository. This means that you can open a pull request, and have GitGitGadget send it to the mailing list on your behalf. So, if you’re more comfortable contributing to Git like that instead of composing emails manually, you can now contribute to Git from start to finish using GitHub.
Nice to see efforts to reduce barriers to contributing.
Re: Highlights from Git 2.28
#44Re: Highlights from Git 2.28
#45I 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…
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.
Re: Highlights from Git 2.28
#46I can almost hear all the fragile tooling built around `master` branches in git screaming.
Re: Highlights from Git 2.28
#47I wonder about which primary branch naming convention they’ll arrive at. “primary” is my personal favorite ;)
I think most important thing is not which branch name we chose, it's that we all chose completely different ones. I'm going for "principal".
Re: Highlights from Git 2.28
#48I wonder about which primary branch naming convention they’ll arrive at. “primary” is my personal favorite ;)
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).
Re: Highlights from Git 2.28
#49I 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…
Along the same vein, I’d love to be able to configure client-side hooks [1] automatically on clone.
[1]: https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks
Re: Highlights from Git 2.28
#50Earlier quoted context omitted.
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 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 own projects.