The notable features are: - Move commits up and down, fixup, drop - Rename commits from the editor (without having to stop for a reword during the rebase run) - Visualize modified files along commits - 'Explode' a commit ,creating a commit for each modified file (a thing I found myself doing quite often)
Feedbacks (both on the tool and the code) and contributions welcome, hope it could fit other people needs too !
I'm comfortable git fooing w/e is necessary, but ever since we adopted this, git related conversations went to almost zero. It's great.
No. This kind of policy has plenty of downsides[1] and the upsides are relatively minor.
But I can’t relate in general to those workflows where PRs have to be tiny and revertable (why need to revert so often).
Having your git history reflecting this is great when you need to take decisions. Because no one will care about your individual commits. Every discussion will revolve about the task. So you make the PRs a bijective relation with it, and by extension the commits on the main branch. Then for special group of tasks like features, you have a specific branch you manage the same way. The other branches you create PRs from can be as messy as you like. And your local copy is yours to do whatever you want.
Commits are in practice a superset of all of that. Some commits will correspond to a task. But many commits will just do the work without having to go through the beaurocracy of “project management”. Having to “project manage” each and every commit if you want a useful and fine-grained (but not micromanaged) version control history is impractical.
There’s a lot of small tasks in the concrete code. It doesn’t make sense to give every little change a task.
And the flipside of that is that you can give up on making commits that are fine-grained enough. Now you’re back in squash town where, sure, your task list is just right. But your commits are sometimes a jumble of different concerns in order to stick to one-task-on-commit.
> Because no one will care about your individual commits.
Will someone care about your tasks?
You don’t pre-empt what commits you care about when you are trying to find the reason for some change in the Git history. You don’t find the exact commit that explains it, clear as day, and then throw it away because there is no associated task.
> So you make the PRs a bijective relation with it, and by extension the commits on the main branch.
It sounds useful with a mathematical name I guess?
Insisting on one-to-one mappings for such small things like commits smells of micromanagement. Yes, either people-management or your own time management.
You're misunderstand me there. I'm talking about the main branch's commits, on the main repository, not every branch and every commits, and not the local repos. And it's not dogmatic, just very nice to have. If you want a hotfix, it's very easy to create a new branch, commit the fix, push it, create a PR, and squash merge it. Unless you like to edit "main" directly on a collaborative project.
Or you can then instruct everyone how to cleanup their commits and make sure that each one is atomic. And you can merge your usual way. I have no dog in this fight. It's just that the above is easier to do. It's pretty much the same result.
No I don’t. I’m also talking about the commits that go into the main branch. The “permanent history”, not all the commits that happen on feature branches.
> And it's not dogmatic, just very nice to have.
A squash-only policy is by definition dogmatic. That’s the only thing that I’ve argued against here—a policy. Having the freedom to do it or not is totally different.
> Or you can then instruct everyone how to cleanup their commits and make sure that each one is atomic. And you can merge your usual way. I have no dog in this fight. It's just that the above is easier to do. It's pretty much the same result.
No. OR you can let people do what they want. Let them squash if they want.
If squashing is such a win they can do that. No instructions necessary.
But that rarely happens and you need these kind of safeguards and directive for the team to be productive at all. It especially avoid discussions about who’s right.
Okay. Great!
> But that rarely happens and you need these kind of safeguards and directive for the team to be productive at all. It especially avoid discussions about who’s right.
It’s like you’ve listened to nothing that I’ve said.