Hacker News Reader

Comment by stinos | Hacker News Reader

No :)

I'm well aware a suboptimal repository commit history hygiene doesn't necessarily correlate with the actual code quality, but yeah this really doesn't look nice nor convenient to work with. I wonder e.g. what the reason is behind pushing a hundred tiny updates to the README in one day, to master?

View on HN

They are updating the README files through the github web interface and saving as they update each section.

Why not make all the edits in one pass? It just looks horrendous. I wonder though, is there a git history fixer out there somewhere that rewrites history to merge commits with the same message into one?

`git rebase -i` and then change `pick` to `squash` for the ones you want squashed, but if you’ve pushed all the commits to master you’re now going to have to force-push master, which is... sub-optimal.

Nah, rebase is too slow on large histories and it might not be your own commit which complicates things.

No it isn't. Are you thinking about filter-branch?

I am not. Manually issuing rebranch is too slow for any git histories over a few hundred. You'd then also have to find which commits you want to merge, merge them and so on and on. Rebranch basically works if you just want to fix one mistake in history you know you have.

... what? `rebranch` isn't a command in git? I think you mean rebase, and sure, if you were rebasing the entire history it would be slow and awful. But don't do that. Rebase at like `HEAD~10` (or whatever) to only clean up the last 10 commits. There's no performance issues or even management issues. Maybe go read the rebasing section (https://git-scm.com/book/en/v2/Git-Branching-Rebasing) of the git manual...

Yes, autocorrect changed it. So last ten commits isn't slow but I literally asked about entire git history.

Why would you rebase an entire git history? No one is arguing for that.

I... like, the first comment in the thread I asked if there's a tool that could go over the entire git history of a repo and fix such issues up, rebase isn't a solution in that case because it does get slow and it requires manual work which is slow, I don't understand how people are losing the context so quickly here.

Your comment didn't say "the entire git history of a repo", and in the context of this thread, people made the reasonable assumption your were talking about a few sequential commits, as discussed regarding the edits to README on the Requests repo.

I work in a large monorepo with so many commits you couldn't fathom.

Rebase isn't at all slow. I know this because I do it often to squash my own commits or move things around between branches.

I disagree about it not being slow, it depends on hardware. In addition to that I did not ask about how to fix a commit history manually, I asked for a tool that would go over an entire commit history and automatically fix the issues for me.

The entire comment is:

> Nah, rebase is too slow on large histories and it might not be your own commit which complicates things.

I don't see any questions being asked. Rebase on the commits we're discussing (readme tweaks) are trivial: fixup fixup fixup

> I don't see any questions being asked.

Read the thread next time. I started by asking if there's a fixer and then someone suggests a single command that absolutely doesn't solve the problem and would take enormous time to use on some projects, even more so if your PC isn't the best of the best.

OK, I see your original comment, no need to be rude. If you're working on a computer that struggles with 'making a commit' and 'editing a text file', I feel like you're working in an environment that's going to be very frustrating when writing code.

Are you thinking about rebasing through an IDE? IDEs are uniformly terrible at git.

I just don't like downvotes because people take comments out of context.

I am not thinking about rebasing trough an IDE. Try rebasing in Chromium's repository, it's simply not fast. The thing I asked for is something that would auto-fix the entire commit histories in cases such as the Requests repository, the suggested use of rebase is too tedious and slow. Has something still remained unclear?

> Try rebasing in Chromium's repository, it's simply not fast

The intent for a tool which could do this quickly is unclear. Rebasing millions of commits will be slow, also rebasing published history will also generate a lot of extra paperwork.

Writing a utility to sort a rebase todo by message and change the later commits with the same message to be fixups is trivial.

Late to the party, but it would be trivial to use `git rebase -i` and a decent editor to fix the Requests commit history. I just gave it a go locally and got good results with less than a minute's editing.

You could I suppose but you run the risk of losing your work in the browser. It is a trade off.

“You” are a developer, why the heck are “you” working in a textarea rather than a proper editor? Updating a readme is not the sort of thing that you have to do urgently from a coffee shop while on holiday in South Asia...

Apparently the README is very important for this project. How else could I learn that it's the most downloaded python package and that I can certainly trust it?

you can certianly trust it

Tbf, a lot of python projects have .rst README files, and getting a local preview can be more of a pain than looking at the GH preview in the browser.

That doesn’t apply in this case, though, where the README is markdown

> Tbf, a lot of python projects have .rst README files, and getting a local preview can be more of a pain than looking at the GH preview in the browser.

rst may be less popular than md but there's no shortage of local preview options, including plugins/extensions for popular editors.

Even for .rst, the Github editor lets you create a new branch. More likely, they simply didn't feel that was particularly important.

Commit early, commit often...

You can do that in a branch without polluting git history.

Git gives you the tools to do that effectively. Namely cheap branching and rebasing. That means you can commit to your heart's content on your own branch, then squash it all down to something useful for master. A hundred tiny commits on a shared branch is just being a bad citizen.

It makes sense to say backup early, backup often. Commits in a version control system that's meant to keep track of development history aren't really meant to be used as a backup system. Just as a backup system isn't really meant to keep track of development history.

Reply on news.ycombinator.com