5 ms·

How is it rewarding? No one ever sees the history, honestly. Writing good code results in working code the people build off of. Maintaining clean, linear git hi

by kobeya 9y ago

How is it rewarding? No one ever sees the history, honestly. Writing good code results in working code the people build off of. Maintaining clean, linear git histories does.. what exactly?

burntsushi 9y ago
Uh, I read commit history all the time. (My initial comment assumes you believe the idea that a clean history is useful, because that's the context of ekidd's comment. So I really don't feel like debating that particular point, if that's what you're getting at. It's been re-litigated hundreds of times.)
mikegerwitz 9y ago
> No one ever sees the history, honestly. Then you wouldn't see value in rewriting. Unless you're not reading the history because it's a pain to read because it's messy. I use `git blame` relatively frequently to understand the rationale and history behind the code I'm working on, or to track down bugs. Of course, this also requires writing decent commit messages---something that I encourage developers to do so that those maintaining their code in the future have some direction. Commit messages are a bit different than software documentation, not a substitute. I bisect looking for bugs, where a clean history with small commits _that actually build_ is essential to quickly finding a bug. That can even be automated if you can create a script that can run a test suite or some other test to check for success. This becomes increasingly important the more code and complexity you're dealing with. There are other cases where I look at history, but those are significant examples.
Zitrax 9y ago
No one ever sees the history? Really ? To me the need for checking history is extremely common. Many projects have multiple delivery, maintenance and other branches, patches need to be applied here and there. Bugs are found and the versions affected needs to be identified. Not maintaining a clean history would cause severe pain.
- lolive 9y ago
  How do you enforce a commit policy in your projects? Do you automate it? Or do you provide feedback by mail, IM, ... to the author when a commit mistake is detected?
  - nicwolff 9y ago
    We have a GitHub integration that runs on every pull request and push, which triggers an AWS Lambda function that verifies that disables the big green "Merge" button if the branch could not also be fast-forwarded onto its parent.
  - lomnakkus 9y ago
    Review-before-merge, maybe? Obviously, for any old arbitrary project, there's going to be limits to what you can ask your contributors to conform to before they just leave, but we're discussing "Best Practices"[1] here. I think these articles are useful because they spread the knowledge of "How To Be A Good Contributor"... for free. [1] Ugh. Not a term I like, but really this is almost always(!) the best way to do it.
strken 9y ago
Your git history is very important for working out what the rest of your team did, when they did it, and why. Having a clean and linear history, preferably with informative commit messages and maybe even references to bugs or features, lets you understand what was going on faster and with fewer mistakes and false starts. Why would you want to understand what was going on? Maybe for fixing a bug, maybe for working out why a seemingly useless change was necessary, maybe to understand the context of a code review building on previously merged branches, or maybe just because you need to catch up on what happened while you were gone. If that's not important to you, then don't bother, but it can be hard to understand what you're missing until you've tried both ways.

by kobeya 9y ago

How is it rewarding? No one ever sees the history, honestly. Writing good code results in working code the people build off of. Maintaining clean, linear git histories does.. what exactly?

burntsushi 9y ago

Uh, I read commit history all the time. (My initial comment assumes you believe the idea that a clean history is useful, because that's the context of ekidd's comment. So I really don't feel like debating that particular point, if that's what you're getting at. It's been re-litigated hundreds of times.)

mikegerwitz 9y ago

> No one ever sees the history, honestly. Then you wouldn't see value in rewriting. Unless you're not reading the history because it's a pain to read because it's messy. I use `git blame` relatively frequently to understand the rationale and history behind the code I'm working on, or to track down bugs. Of course, this also requires writing decent commit messages---something that I encourage developers to do so that those maintaining their code in the future have some direction. Commit messages are a bit different than software documentation, not a substitute. I bisect looking for bugs, where a clean history with small commits _that actually build_ is essential to quickly finding a bug. That can even be automated if you can create a script that can run a test suite or some other test to check for success. This becomes increasingly important the more code and complexity you're dealing with. There are other cases where I look at history, but those are significant examples.

Zitrax 9y ago

No one ever sees the history? Really ? To me the need for checking history is extremely common. Many projects have multiple delivery, maintenance and other branches, patches need to be applied here and there. Bugs are found and the versions affected needs to be identified. Not maintaining a clean history would cause severe pain.

lolive 9y ago
How do you enforce a commit policy in your projects? Do you automate it? Or do you provide feedback by mail, IM, ... to the author when a commit mistake is detected?
- nicwolff 9y ago
  We have a GitHub integration that runs on every pull request and push, which triggers an AWS Lambda function that verifies that disables the big green "Merge" button if the branch could not also be fast-forwarded onto its parent.
- lomnakkus 9y ago
  Review-before-merge, maybe? Obviously, for any old arbitrary project, there's going to be limits to what you can ask your contributors to conform to before they just leave, but we're discussing "Best Practices"[1] here. I think these articles are useful because they spread the knowledge of "How To Be A Good Contributor"... for free. [1] Ugh. Not a term I like, but really this is almost always(!) the best way to do it.

strken 9y ago

Your git history is very important for working out what the rest of your team did, when they did it, and why. Having a clean and linear history, preferably with informative commit messages and maybe even references to bugs or features, lets you understand what was going on faster and with fewer mistakes and false starts. Why would you want to understand what was going on? Maybe for fixing a bug, maybe for working out why a seemingly useless change was necessary, maybe to understand the context of a code review building on previously merged branches, or maybe just because you need to catch up on what happened while you were gone. If that's not important to you, then don't bother, but it can be hard to understand what you're missing until you've tried both ways.