The use of init.defaultBranch here is really problematic, because different repositories may use a different name for their default, and this is a global (your home directory scope) setting you have to pre-set.
I have an alias I use called git default which works like this:
default = !git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@'
then it becomes
..."$(git default)"...
This figures out the actual default from the origin.
I work at a company that was born and grew during the master->main transition. As a result, we have a 50/50 split of main and master.
No matter what you think about the reason for the transition, any reasonable person must admit that this was a stupid, user hostile, and needlessly complexifying change.
I am a trainer at my company. I literally teach git. And: I have no words.
Every time I decide to NOT explain to a new engineer why it's that way and say, "just learn that some are master, newer ones are main, there's no way to be sure" a little piece of me dies inside.
Why does your company not migrate to one standard? Github has this functionality built in, and it's also easy enough to do with just git.
I'm personally a huge fan of the master-> main changejus5t because main is shorter to type. Might be a small win, but I checkout projects' main branches a lot.
It's extremely obvious that "main" is more ergonomic. It's sad that we're so resistant to change (regardless of how valid you think the initial trigger was)
No, actually, zero people 'must admit' that it was a stupid, user hostile and needlessly complexifying change.
I would say any reasonable person would have to agree that a company which didn't bother to set a standard for new repos once there are multiple common options is stupid, user hostile and needlessly complexifying. And if the company does have a standard for new repos, but for some reason you don't explain that to new engineers....
There was only a single standard before, so there was no reason why a company should make any company specific standard. The need for companies to make a standard only exists, since the master to main change, because now there are two standards.
Except git init still creates branches named master without configuration (although with a warning), which will only change in 3.0 for obvious reasons, and tons of people (including me) still use master, and old projects don't just vanish.
I love the arguments where you tell me what I “must admit”.
I simply don’t, therefore your entire point is meaningless.
I’m sorry that something so inconsequential irked you so much. Maybe you need to read a book about git if this stumped you bad enough to want to voice your upset about it years later?
I’d consider yourself lucky that everything else is going so well that this is what’s occupying you.
I have a global setting for that. Whenever I work in a repo that deviates from that I override it locally. I have a few other aliases that rely on the default branch, such as “switch to the default branch”. So I usually notice it quite quickly when the value is off in a particular repo.
I'm of the opinion that Git hooks are personal. That's why they're not part of the source code itself. I make extensive use of hooks, but they're tailored to my needs.
Note that you can skip hooks by passing the --no-verify flag to subcommands. Comes in handy when they're slow and you know that you've just fixed the wrong formatting that the previous invocation of your pre-commit hook complained about.
Nice, I use finicky as well, but now and again I have to change a rule or even add a new one. pisses me right off. Anyway thank you for sharing your dotfiles.
> Using commit log diffs as changelogs is a bad idea: they're full of noise. Things like merge commits, commits with obscure titles, documentation changes, etc.
> The purpose of a commit is to document a step in the evolution of the source code. Some projects clean up commits, some don't.
> The purpose of a changelog entry is to document the noteworthy difference, often across multiple commits, to communicate them clearly to end users.
> they're full of noise. Things like merge commits
From another angle, merge commits can also be a solution to the problem. `git merge --no-ff --edit` can be a great way to summarize an entire branch of commits. Most PR tools will give you an easy way to create those kind of merge commits. Don't settle for the default "merge branch x into y", create a meaningful title and fill in details/summary of what happened in the branch. With traversal tools like git log --first-parent you can see a high level of just your merge commits with the gnarly details of whatever steps led up to the merge commit itself.
I've certainly seen good projects where `git log --first-parent` was always a useful first pass changelog (no matter how "clean" the rest of commits were or were not). Probably still not a changelog you should send as a document to end users (because still written from a development standpoint rather than a user standpoint), but a good place to start writing the end user documentation.
Me too, but some tools combine the best of both worlds. In my team we use commitizen [1] which drinks both from keepachangelog and conventional commits and we are quite pleased with our changelogs so far.
> Facebook aside you really see this across the board on almost any platform, that once the product reaches it's 1.0 stage, (where it is good, does what the users want it to do, and has realised its vision) it begins a process of gradual decay, as the focus of the product managers (now panicking to find some statistics to improve to show their bosses) shifts from "building functionality" to "increasing engagement/retention/active users per month".
Best example for me: Revolut. The app and product as a whole was so simple and good.
One year ago (or maybe 1.5 years ago) it started going downhill, fast. The app got so complicated that I often simply cannot find what I'm looking for (my card or the balance in a specific currency). Everyone I know using Revolut has the same complaint, especially older people like my parents or in-laws.
Valora Digital | Senior iOS | Full-time | Zurich, Switzerland | ONSITE or REMOTE (CET +- 2h)
Valora Digital[0] is the digital unit of Valora[1], a European retailer with 2700 stores across 5 countries. We are tackling interesting challenges in areas such as Autonomous Stores (think Amazon Go), E-commerce & Delivery, Loyalty, Payments and Process Improvement. For this purpose we are building up a development team from scratch. You will be one of the first engineers and will have a big part in shaping the culture as well as choosing our stack. We are looking to bring the startup ethos to the corporate world and get to combine the best of both worlds: ample funding, a huge customer base to deploy to and lots of freedom.
We are using Swift and SwiftUI to build a modular architecture that will underpin a portfolio of apps. I'm head of mobile and an iOS developer myself.
* It ensures the default branch is not deleted (main, master)
* It does not touch the current branch
* It does not touch the branch in a different worktree[2]
* It also works with non-merge repos by deleting the local branches that are gone on the remote
[1]: https://github.com/fphilipe/dotfiles/blob/ba9187d7c895e44c35...[2]: https://git-scm.com/docs/git-worktree
reply