Ingo Steinke is a Berlin-based senior web developer focusing on front-end web development to create and improve websites and make the web more accessible, sustainable, and user-friendly.
squashing should never be the default in my opinion. we can squash, edit, pick and edit locally, but to me it is one of the misfeatures of git/GitHub/popular repositories to throw away meaningful commit messages that contributors might have taken a long time to describe properly.
Another misfeature of current version control is rather a shortcoming of the default diff algorithms, producing too many "changes" and "conflicts" like when two different additions have been made to the same file, or when indentation changed so that editing two lines produces pseudo-change noise of any nested lines. This might also be the main reason making it so painful and dangerous to rebase in complex projects.
Good idea for hju: forcing developers to make small pull requests (following the principle of trunk based development) but how exactly would we force fellow developers to do so?
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
misfeatures of git/GitHub/popular repositories to throw away meaningful commit messages that contributors might have taken a long time to describe properly.
That's just my opinion but I think long descriptions should go in the issue trackers, pull requests discussion, company wikis. Easier to update. Easier find after the fact. But not in the git descriptions. For documentation, being immutable is an anti-feature.
Git didn't have an issue tracker, because the Linux developers already did those things by email, so for them the long detailed descriptions in the git messages made total sense.
forcing developers to make small pull requests (following the principle of trunk based development) but how exactly would we force fellow developers to do so?
Not forcing but nudging.
Nudging by making squashing the default.
You can only squash pull requests that are focused on one thing.
That's a useful friction here.
Hi, I'm Matt Ferrin, specializing in TypeScript, Continuous Delivery, and Functional Programming. I also excel at imaginary conversations. Stay tuned for tech insights!
I think you could have a websocket write conflicts into a separate adjacent file dynamically. Then it’s a little like Google docs if everybody detects and aligns changes immediately.
If 2 people can’t immediately align their local changes, it surfaces a disagreement or lack of understanding. It might be a disagreement about something petty though. Everything comes with a trade off.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
Your comment reminded me that git (and hju) is by default the wrong choice for documentation.
We overuse it because we know git, but frankly pause and reflect the next time you want to do that.
Basically Wikipedia is the proven method for collaborating on documentation.
Git is the newer kid that does it worse and add tons of overhead.
You can have counter examples like a static blog where you are the only one and commit on main and need to use a CI. Ok then that's fine.
But in general documentation is a completely different use case than software.
Think about those 420 awesome-something github repositories that could have been one wiki instead.
You don't need a global history of commits that span multiple files.
You need multiple histories, one per file, that are mostly independant
(just make sure to support renaming).
Most importantly, for documentation you want to remove the gatekeepers that nitpick your pr.
The inventor of the wiki correctly stated that it was inefficient because "The best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer."
Hi, I'm Matt Ferrin, specializing in TypeScript, Continuous Delivery, and Functional Programming. I also excel at imaginary conversations. Stay tuned for tech insights!
I fully agree. I have found that all supporters of squash commits either create so low quality patches that keeping commits separate just adds noise or they want to use some tools that cannot handle anything more complex but a single commit (e.g. Gerrit?).
I find that never using squash but rebasing feature branches is much much better in long run. Yes, I might combine some patches in the process to create easier to understand history but never squash everything without thinking.
And i always find it funny when software developers complain that the concepts used in Git are too hard to learn. How on earth do you think you can write correct programs if you cannot even wrap your mind around as simple as Git?
Some old git commands do have poorly named flags and some commands like checkout and reset have way too many modes, but those cannot be fixed without breaking backwards compatibility.
Maybe we should have easy-git (eg?) that is just an alternative command line interface to git, where the intent is easy to use instead of backwards compatibility. Of course, that would prevent scripting those commands because your scripts would fail when its interface is "improved" in the future.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
And i always find it funny when software developers complain that the concepts used in Git are too hard to learn. How on earth do you think you can write correct programs if you cannot even wrap your mind around as simple as Git?
That's pretty simple really, i'm more likely to write correct programs if I have less cognitive load to spend on my version control tool. And to other things unrelated to the task at hand.
What happens is that some people have spent huge amount of times polishing their git skills, and written thousands of commits in git, doing hundreds of rebases, practiced the best practices, ... so they are like long-time users of emacs. For them everything make sense, feels productive and there is no point in using something else.
Personally I'm more interested in the beginner's mind than in the expert's mind. With sufficient training, everything seems OK.
Maybe we should have easy-git (eg?) that is just an alternative command line interface to git, where the intent is easy to use instead of backwards compatibility.
Agree, you can't touch /usr/bin/git itself because it's like the low-level library that everone relies on.
I'm using lazygit when I'm in the terminal, does the job really well
A simple terminal UI for git commands, written in Go with the gocui library.
Sponsors
Maintenance of this project is made possible by all the contributors and sponsors. If you'd like to sponsor this project and have your avatar or company logo appear below click here. 💙
Elevator Pitch
Rant time: You've heard it before, git is powerful, but what good is that power when everything is so damn hard to do? Interactive rebasing requires you to edit a goddamn TODO file in your editor? Are you kidding me? To stage part of a file you need to use a command line program to step through each hunk and if a hunk can't be split down any further but contains code you don't want to stage, you have to edit an arcane patch file by hand? Are you KIDDING me?! Sometimes you get asked to stash…
squashing should never be the default in my opinion. we can squash, edit, pick and edit locally, but to me it is one of the misfeatures of git/GitHub/popular repositories to throw away meaningful commit messages that contributors might have taken a long time to describe properly.
Another misfeature of current version control is rather a shortcoming of the default diff algorithms, producing too many "changes" and "conflicts" like when two different additions have been made to the same file, or when indentation changed so that editing two lines produces pseudo-change noise of any nested lines. This might also be the main reason making it so painful and dangerous to rebase in complex projects.
Good idea for hju: forcing developers to make small pull requests (following the principle of trunk based development) but how exactly would we force fellow developers to do so?
Completely agree with your second paragraph.
That's just my opinion but I think long descriptions should go in the issue trackers, pull requests discussion, company wikis. Easier to update. Easier find after the fact. But not in the git descriptions. For documentation, being immutable is an anti-feature.
Git didn't have an issue tracker, because the Linux developers already did those things by email, so for them the long detailed descriptions in the git messages made total sense.
Not forcing but nudging.
Nudging by making squashing the default.
You can only squash pull requests that are focused on one thing.
That's a useful friction here.
I think you could have a websocket write conflicts into a separate adjacent file dynamically. Then it’s a little like Google docs if everybody detects and aligns changes immediately.
If 2 people can’t immediately align their local changes, it surfaces a disagreement or lack of understanding. It might be a disagreement about something petty though. Everything comes with a trade off.
@jmfayard @ingosteinke
Your comment reminded me that git (and hju) is by default the wrong choice for documentation.
We overuse it because we know git, but frankly pause and reflect the next time you want to do that.
Basically Wikipedia is the proven method for collaborating on documentation.
Git is the newer kid that does it worse and add tons of overhead.
You can have counter examples like a static blog where you are the only one and commit on main and need to use a CI. Ok then that's fine.
But in general documentation is a completely different use case than software.
Think about those 420 awesome-something github repositories that could have been one wiki instead.
You don't need a global history of commits that span multiple files.
You need multiple histories, one per file, that are mostly independant
(just make sure to support renaming).
Most importantly, for documentation you want to remove the gatekeepers that nitpick your pr.
The inventor of the wiki correctly stated that it was inefficient because "The best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer."
I agree with this. For work, I put one link to the wiki location in the git readme and call it good.
I fully agree. I have found that all supporters of squash commits either create so low quality patches that keeping commits separate just adds noise or they want to use some tools that cannot handle anything more complex but a single commit (e.g. Gerrit?).
I find that never using squash but rebasing feature branches is much much better in long run. Yes, I might combine some patches in the process to create easier to understand history but never squash everything without thinking.
And i always find it funny when software developers complain that the concepts used in Git are too hard to learn. How on earth do you think you can write correct programs if you cannot even wrap your mind around as simple as Git?
Some old git commands do have poorly named flags and some commands like checkout and reset have way too many modes, but those cannot be fixed without breaking backwards compatibility.
Maybe we should have easy-git (eg?) that is just an alternative command line interface to git, where the intent is easy to use instead of backwards compatibility. Of course, that would prevent scripting those commands because your scripts would fail when its interface is "improved" in the future.
That's pretty simple really, i'm more likely to write correct programs if I have less cognitive load to spend on my version control tool. And to other things unrelated to the task at hand.
What happens is that some people have spent huge amount of times polishing their git skills, and written thousands of commits in git, doing hundreds of rebases, practiced the best practices, ... so they are like long-time users of emacs. For them everything make sense, feels productive and there is no point in using something else.
Personally I'm more interested in the beginner's mind than in the expert's mind. With sufficient training, everything seems OK.
Agree, you can't touch /usr/bin/git itself because it's like the low-level library that everone relies on.
I'm using lazygit when I'm in the terminal, does the job really well
simple terminal UI for git commands
A simple terminal UI for git commands, written in Go with the gocui library.
Sponsors
Maintenance of this project is made possible by all the contributors and sponsors. If you'd like to sponsor this project and have your avatar or company logo appear below click here.💙
Elevator Pitch
Rant time: You've heard it before, git is powerful, but what good is that power when everything is so damn hard to do? Interactive rebasing requires you to edit a goddamn TODO file in your editor? Are you kidding me? To stage part of a file you need to use a command line program to step through each hunk and if a hunk can't be split down any further but contains code you don't want to stage, you have to edit an arcane patch file by hand? Are you KIDDING me?! Sometimes you get asked to stash…