News for hackers. Stuff that matters.
Re:Comparing Git Workflows by forrestthewoods on Thursday May 26, 2016 @01:38PM (#11779915)
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.

Re:Comparing Git Workflows by rimantas on Thursday May 26, 2016 @05:16PM (#11781694)
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.
Re:Comparing Git Workflows by forrestthewoods on Thursday May 26, 2016 @05:24PM (#11781756)
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.
Re:Comparing Git Workflows by ChristianGeek on Thursday May 26, 2016 @09:27PM (#11783224)
Doesn't an undeleted feature branch essentially offer the same functionality as "expand squash?"