3 ms·

> since PRs usually cover a feature or a fix for a ticket, these frequently involve doing multiple things to implement the feature or fix the bug Hence the cal

by ilammy 4y ago

> since PRs usually cover a feature or a fix for a ticket, these frequently involve doing multiple things to implement the feature or fix the bug Hence the calls to “split changes into multiple smaller PRs” you hear so often, since the scope of the unit of change is actually important. If your unit of change is a PR, you'd want PRs to have limited scope & nice description, and you would not really mind that a feature requires 10 PRs to implement. > Your parenthetical clause is not theoretical. It is absolutely theoretical until it is required in practice. Your reality is dealing with codebases that span multiple years. Other people might have different circumstances. They might not have come to value the tidy history made of self-contained commits because they never had a need for one. Either perceived, or quite real. Why would you need git blame if you stay at a company 2 years tops? Why would you need git blame once your feature is effectively rewritten? twice? Why would you need git blame if you’re just an intern and merging & picking is done by senior greybeards? Why would you need git blame if everything is perfectly explained in the ticket linked from a PR? Why would you need git blame if the code is clear and does not require git archaeology to understand it? There are ways to get things successfully done without git blame or “nice” history. And your output is not history, your output is feature in use by real users. I called it “commit discipline” because it is discipline: it has benefits but most of them are non-obvious and hard to explain to undisciplined; the discipline requires extra effort to follow; in order to effectively acquire it you need nurturing, training, and reinforcement; after sticking with it for N years it’s just what you do and you do not imagine doing things otherwise. Oh, and you absolutely can get things somehow done without it and do not even realize what you’re missing. Or do things with it and do not realize that you’re wasting time on irrelevant work.

Izkata 4y ago
> It is absolutely theoretical until it is required in practice. The problem with this assumption is once it is required in practice, you can't go back in time and change the past decade. This is one of those things you have to assume will be required if it's to be of any use at all. > Why would you need git blame if you stay at a company 2 years tops? It's not for you tracking your own code, it's for figuring out what was going on 3 developers ago (or 3 developers in the future looking at your code). > Why would you need git blame once your feature is effectively rewritten? twice? To know what happened that caused them to write that really weird line in the original code, how important it is, and whether those two rewrites need something like it. I'm going through this right now, rewriting some perl daemons in python because the underlying system it uses has become so unreliable and having such svn history from 10+ years ago has been a great help - even for simple things like finding that yes, the comments are wrong because they were for a version of the code before a refactor. > Why would you need git blame if you’re just an intern and merging & picking is done by senior greybeards? There's a good chance you're making the seniors' jobs harder by squashing it. > Why would you need git blame if everything is perfectly explained in the ticket linked from a PR? You're assuming the ticket still exists. We're on our 3rd system (at least), and I'm regularly in code that links pack to a ticket system that we haven't had in almost a decade. > Why would you need git blame if the code is clear and does not require git archaeology to understand it? What's "clear" can be really subjective. It probably was clear to the one who wrote the original version, but for any number of reasons it isn't anymore. (Idioms from one language you don't know well, quirks of the individual developer, an original clear design that slowly mutated over time and with multiple developers and is no longer clear, etc...)

by ilammy 4y ago

Izkata 4y ago

> It is absolutely theoretical until it is required in practice. The problem with this assumption is once it is required in practice, you can't go back in time and change the past decade. This is one of those things you have to assume will be required if it's to be of any use at all. > Why would you need git blame if you stay at a company 2 years tops? It's not for you tracking your own code, it's for figuring out what was going on 3 developers ago (or 3 developers in the future looking at your code). > Why would you need git blame once your feature is effectively rewritten? twice? To know what happened that caused them to write that really weird line in the original code, how important it is, and whether those two rewrites need something like it. I'm going through this right now, rewriting some perl daemons in python because the underlying system it uses has become so unreliable and having such svn history from 10+ years ago has been a great help - even for simple things like finding that yes, the comments are wrong because they were for a version of the code before a refactor. > Why would you need git blame if you’re just an intern and merging & picking is done by senior greybeards? There's a good chance you're making the seniors' jobs harder by squashing it. > Why would you need git blame if everything is perfectly explained in the ticket linked from a PR? You're assuming the ticket still exists. We're on our 3rd system (at least), and I'm regularly in code that links pack to a ticket system that we haven't had in almost a decade. > Why would you need git blame if the code is clear and does not require git archaeology to understand it? What's "clear" can be really subjective. It probably was clear to the one who wrote the original version, but for any number of reasons it isn't anymore. (Idioms from one language you don't know well, quirks of the individual developer, an original clear design that slowly mutated over time and with multiple developers and is no longer clear, etc...)