341–350 of 404 posts
Earlier quoted context omitted.
Comment with a ticket-id would be more efficient.
On a long-lived codebase you're going to end up with nearly as many such comments as there are lines of code. Now that's a cluttered mess.
Either a short quip, doc string, or link to the full story is an accessible combo. Nothing is the correct choice for unsurprising code.
Earlier quoted context omitted.
> git-rebase is stupid because somebody doesn't know how to use it? No, it's stupid because it's really common for people to fuck it up, and because the purported benefits (clean history) are not something which matters.
If I tell you it matters to me, will that change your mind? You've told me that it doesn't matter to you, but that hasn't changed my mind. It's not a matter of objective truth, it's a preference.
Earlier quoted context omitted.
The way I phrase and teach what I consider to be the important rule of git is: > Don't rewrite history on shared branches with proper communication. I don't teach "never", I don't teach that `main` is special, I don't teach that force pushing is forbidden, because I don't believe in those things. I highly prefer a rebase-heavy workflow. In addition to not "cluttering" the history, it's an invaluable tool to keep comm…
It’s annoying when someone force pushes to a branch that you just reviewed, but you can no longer see the history so you have to scan through the whole PR you already reviewed looking for the change. Please just commit the fix, let me see it, then squash it.
Earlier quoted context omitted.
Why not document it then? In a place where everyone can read it, instead of only developers.
...are you suggesting spending hours searching through documentation, hoping to possibly find something relevant, instead of just being able to run "git blame" to see why a specific line was changed?
Code tells how, not why—the domain of specs and comments. Commit messages effectively don’t exist for non-developers.
I put spec links in doc strings whenever possible. They are accessible to everyone—devs, PMs, SMEs, stakeholders that pay bills, and myself when at a web browser.
Searching is not required but even if it was it would be a tiny fraction of “hours.”
Earlier quoted context omitted.
Is there something wrong with the latest version of the method? Instead of one from ~18 months ago which may not work any longer?
I'm not sure I get you. What do you mean the "latest version of the method"? And why shouldn't code from 18 months ago not work? Some minimal regression testing should be in place for production code, and it is probably also used regularly. So, yes seeing e.g. how "CSV export for class A" is implemented is a great guide for implementing "CSV export for class B".
Everything you need is in the most recent copy. Showing an old one invites errors for no benefit.
Earlier quoted context omitted.
The way I phrase and teach what I consider to be the important rule of git is: > Don't rewrite history on shared branches with proper communication. I don't teach "never", I don't teach that `main` is special, I don't teach that force pushing is forbidden, because I don't believe in those things. I highly prefer a rebase-heavy workflow. In addition to not "cluttering" the history, it's an invaluable tool to keep comm…
You can simply pass flags to “git log” to hide merge commits, without needing to rewrite history to “destroy” that information. While they are often noisy, sometimes they can be useful. I usually prefer to hide information rather than destroy it.
Earlier quoted context omitted.
If a strategy requires humans to be virtuous AND vigilant it is doomed to failure. I rarely use history and prefer merge/squash, with automated CI tools, and tests. "Why" is kept in doc strings, comments, specs, and story tickets. Everything viewable in gitlab with automatic links. All this gets out of the critical path, every day. I submit that, if your code is so complex that diagnosing a bug is a major research pr…
If a strategy requires humans to be virtuous AND vigilant it is doomed to failure. Sorry, but I don’t buy that. By the same principle, there’s also no point in writing unit tests or defining static types or having code reviews, all of which require thought and extra work, yet can yield considerable dividends when done even moderately well. I rarely use history and prefer merge/squash, with automated CI tools, and tes…
As an industry we get paid primarily for 1) working software and 2) communicating with stakeholders.
Tidy yet inaccessible (to non-dev) construction stories are not on that path. I would argue unit tests et al are, to ensure #1.
No stakeholders? Put why into a readme, where it can be seen at a glance. Comments can reference docs.
Complexity must be broken down into bite-sized chunks for a solution to be feasible in the first place, reliable in the second. i.e. skull-size limits. If there’s any code I don’t understand I rewrite it until I can. With tests of course.
"Don't make me think" has been the best principal of coding for me for a long time. Looking at how much thinking overhead rebase is producing, I'd prefer to avoid it.
Please write the spec for next generation version control. I feel like Git is great but we could have one which is easier to use and has built in concepts like Pull Prequest or deployed state.
FWIW, Mercurial's been there for almost 20 years.
Earlier quoted context omitted.
> Agreed. But the rewrite occurs in your private branch. It's history is just as private as the undo list in your editor. No one cares about what's going on in your editors undo list. And by the same logic they shouldn't care about commits in a private branch. The rebase becomes part of the public branch eventually, inflicting your lies on everyone else. > If you avoid rebase, then you end up "rebasing" without rebas…
I think the crux of the argument is what you think about private git commits. You may think of them as "holy" history. Assuming the commits are still private, I give them no more prestige than the editor's undo log. What do you think of the editors undo log? It's a very real historical log. Should it be treated as "holy" history too? If not, what makes the undo log less true/important than a private git commit log?
Squashing is often dumb and unhelpful, because you're now re-summarizing the points in time that you already considered worth highlighting when they happened (when you had the most context to judge them!).
Rebasing is lying about the order and/or context that those changes happened in.
Your undo log is comparable to squashing, but not at all to rebasing.
And then again, the first-order vs second-order summarizing distinction matters, and you already capture the second-order summary in your merge commit. Squashing is just destroying information for zero practical benefit.
> private
You keep using that word, but branches are often a lot less private than you think. Push it to get a colleagues' input on something? Congratulations, it's now public. Created a pull request that you want to revise? Already public.