I remember old YouTube having these kinds of exchanges. I would get DMs asking for a five star rating on a video they uploaded about some relevant topic in exchange for a likewise five star rating. I miss those days
Mine look similar except the body is mostly “the X was doing Y, but it should’ve been doing Z” or “the docs say bla, $link”. I try to separate the individual “update A to do B” in separate commits, but sometimes it just isn’t possible.
We squash everything (and rebase rather than merge) so I don’t worry much about the individual commits. I like that main is pretty concise and doesn’t have a ton of work-in-progess stuff in the log.
We are mortal enemies you and I 😄 I’d much rather have a descriptive commit history than huge commits which make git blame meaningless. Function over beauty for me.
A nemesis! I’m pretty lucky I guess that no one at my workplace has strong git opinions that differ
Do you have multiple people’s commits being squashed together? Or how is blame being made useless for you? I’m at a rather small company where generally it’s just one person working on a thing at a time. The blame will point to their squashed commit that, if they wrote a good message like the top of this thread, will give you a lot of context.
Imagine finding a bug in angularjs, doing a git blame and finding this commit
feat(module): new module loader
211 changed files with 1,051 additions and 1,242 deletions.
AngularJS isn’t even the worst offender. I’ve seen backports of multiple fixes getting squashed into one commit for “a clean history” with all the useful commit messages ending up in one commit.
Many user stories I’ve seen implemented in a sprint take multiple days to write. Sometimes they have 5+ commits with a multitude of files changed and (if done right) each commit has an explanation why something was done or at least what was done. Having a granular view of changes also allows finding related changes quickly with less code to read.
If someone changes the implementation of a function call in one commit and it introduces a bug, it’s nice to have only that change instead of the entire class with it and changes in other files too. Additional changes mean now you have to read through more code to be sure that the function implementation change was not done due to a modification of the class or whatever else was changed which might be the actual source of the problem.
IMO squashing commits has its uses. It’s a tool in a toolbox, but it’s not the only tool.
My squashed commit messages typically enumerate everything I changed and why.
IMO squashing commits has its uses. It’s a tool in a toolbox, but it’s not the only tool.
I think we agree on this.
One case that has come up for me several times: working on a feature, committing as I go. And then I realize some of what I did won’t work or isn’t what product actually wants. Leaving those commits in the history that show the function doing the wrong thing would be misleading. Especially if that was never actually in production or left my local machine.
I guess I have an unspoken belief that every commit on main should work, but you could achieve that with tags instead.
I was recently spelunking to try to find why something in old code was the way it was. I found the commit where they changed the line, but it was orphaned from the larger context. The message didn’t say more than like “change field from footype to bartype”, but not why. So I had to try to piece together what other changes were part of this change. If it had been a single commit that showed them like adding the new field, new model, and whatnot, it would have been clearer to me that those things all go together.
When there’s a limit to the size of a commit message it does make it difficult to actually list all the changes, so sometimes this is all you can write.
I know in theory you’re meant to commit little and often, but in practice it doesn’t always work out that way.
Even if you have a big commit, you can always write something more descriptive than this. And commit messages can be huge, so the limit shouldn’t be an excuse to write a useless message.
For those wondering how to exceed the 70 (80) recommended character limit and still follow best practices:
Write the title on the first line, keep below 70 characters.
Make two (2) newlines
Write one or more descriptive paragraphs.
The first line will be shown as commit message, and the full text can usually be viewed by checking out the commit. Sentences can span multiple lines, but try to keep the line length below 70 characters for best readability.
This off the top of my head, so feel free to correct me if I’ve misremembered the best practices.
I generally write a single line summary and then a list of the specifics like:
Did stuff (except more detailed than that)
- The first thing I did
- Maybe some more detail about the first thing because there's a rationale to explain
- The second thing I did
- Third thing
Git is one of those things that take a bunch of learning to understand but is makes perfect sense once you do. I read like half of the pro git book and after that I was like it’s so simple! If course it still requires you to read half a book…
For some reason I’ve always been able to visualize version control systems and workflows pretty well and understand how they work. I used to host a CVS server when I was in college back in 2001 so my teammates and I we could collaborate on our lab projects. Then moved on to Subversion, which I used for a very long time. Then I worked at a small company who used Canonical’s Bazaar and finally joined a big corp who used Git.
Throughout the years I simply developed some good practices that I applied to Git and that seemed to be enough. But, I’d occasionally get into this detached head state that I didn’t really understand. And this happened often with my teammates at that job. They’d end up with bizarre scenarios. So I started reading the book and experimenting and was soon pretty solid in Git and ended up being the SME on that topic for our team. Everyone would come to me when they got stuck.
I’m still learning new shit about Git even 8 years later lol. But, the step from being a newbie to a normal user is really big.
Cloning a repo to build the source code isn’t even remotely hard.
When you manage the repo of an entire team who work together on different release versions of a product using a very specific workflow with squash commits and cherry-picking? And when team members fuck up the repo’s history with a bad git pull/push? Yeah, it gets more complicated.
Even with merge policies, if someone doesn’t understand what they’re doing or how it works, it won’t help.
Last project I worked on, we asked our developers to rebase on the parent branch and squash on their pull requests. But, they often encountered conflicts because they never updated their branch. They would pull the parent branch into their feature breach, or do a regular merge, or merge different other branches together and you’d end up with commit duplication everywhere. They didn’t have any discipline.
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.