5 ms·

> Because lord knows there will be a moment down the road where there's a line of code that doesn't quite make sense. This is that code reviews and code commen

by MAGZine 10y ago

> Because lord knows there will be a moment down the road where there's a line of code that doesn't quite make sense. This is that code reviews and code commenting are for. You shouldn't need to dig into the nitty-gritty of multiple commits of a single feature to understand a single line. Written once, read hundreds—right? > And I'll want _full_ history to understand where that line came from. See how it evolved. So you want a full keystroke history as well, then? Because as far as I'm concerned, this is essentially what an unsquashed commit history is. Don't get me wrong, I'm not saying you should have 15,000 line commits that encompass a single feature—these lines should have made their way back into the code a long time ago—but seeing dozens of one-line changes is useless: "fix ci by including dependency"; "&& instead of ||"; "tidy up style"; "strings should be UTF-8"—and these are just useful names for useless commits which totally ignore commits of "..."; "shit"; "fixes stuff"; "work"; "progress";. These commits just fragment the history and especially gitblame, because it becomes difficult to see many changes cleanly wrapped into a single, logically grouped block.

forrestthewoods 10y ago
There exists a spectrum from full keystroke history to squashed commit. Squashed commits throws away information. It is lost forever. Full keystroke contains all that information information but it is incredibly noisy. Per commit state snapshot is a pretty happy median. It doesn't tell you all the things that keystrokes could tell you. But it's very easy to use. And tells you a lot of things that squashed commits does not. The obvious answer is to squash commits, but keep the information. Intermediate commits aren't needed very often. But they can be exceptionally useful when they are needed. Especially if the commits were from an employee who is no longer working at your private company. Git still needs a p4 timelapse view tool. It's wonderful. All that tool needs is a little check box called "expand squash". That's the best of both worlds. Everyone gets what they want. But that tool and checkbox don't exist. So given the choice between squashed vs unsquashed I'll take unsquashed 100% of the time. At a private company that is. Open source projects, especially large projects, might choose differently.
- ChristianGeek 10y ago
  Doesn't an undeleted feature branch essentially offer the same functionality as "expand squash?"
- rimantas 10y ago
  Data is not necessarily information. If three commits to fix a typoe make you happy, so be it. I don't need and I do not want this kind of history and information.
  - forrestthewoods 10y ago
    In throwing away three commits to fix a typo you also throw away 10 commits that show how the parameters in a function declaration changed over time. You may need that information. And you're choosing to throw the baby out with the bathwater.

by MAGZine 10y ago

forrestthewoods 10y ago

There exists a spectrum from full keystroke history to squashed commit. Squashed commits throws away information. It is lost forever. Full keystroke contains all that information information but it is incredibly noisy. Per commit state snapshot is a pretty happy median. It doesn't tell you all the things that keystrokes could tell you. But it's very easy to use. And tells you a lot of things that squashed commits does not. The obvious answer is to squash commits, but keep the information. Intermediate commits aren't needed very often. But they can be exceptionally useful when they are needed. Especially if the commits were from an employee who is no longer working at your private company. Git still needs a p4 timelapse view tool. It's wonderful. All that tool needs is a little check box called "expand squash". That's the best of both worlds. Everyone gets what they want. But that tool and checkbox don't exist. So given the choice between squashed vs unsquashed I'll take unsquashed 100% of the time. At a private company that is. Open source projects, especially large projects, might choose differently.

ChristianGeek 10y ago
Doesn't an undeleted feature branch essentially offer the same functionality as "expand squash?"
rimantas 10y ago
Data is not necessarily information. If three commits to fix a typoe make you happy, so be it. I don't need and I do not want this kind of history and information.
- forrestthewoods 10y ago
  In throwing away three commits to fix a typo you also throw away 10 commits that show how the parameters in a function declaration changed over time. You may need that information. And you're choosing to throw the baby out with the bathwater.