I can't believe some of the comments I have seen made back and forth. let's shoot for a professionalism to supercede all others
Squash your commits
241–250 of 350 posts
Re: Squash your commits
#242Sometimes I feel like it's a minority position, but I think it strange all the efforts people go to in order to essentially make the git DAG look like a (lie of a) straight-line CVS or SVN commit list. Seeing how the sausage was actually made (no rebases, no squashes, sometimes not even fast-forwards) isn't pretty, but it is meaningful and will tell you a great deal about a project and its developers... I trust that.…
> It's real and visceral and how software is actually made... It's also extraordinarily cluttered, and it really gets in the way when someone later want to do a 'git bisect' to track down when a bug was introduced. When I'm working I do frequent little commits just to capture and back up my broken stream-of-thought experiments. None of those are going to be relevant to people who work with this code in the future; ho…
But squashing makes git bisect even harder, since the chunks are bigger. If you have a very granular history then you can see exactly what 15 line change caused the breakage
(though the counterpoint is that maybe there are parts of the granular history that are just busted for other reasons)
Re: Squash your commits
#243Sometimes I feel like it's a minority position, but I think it strange all the efforts people go to in order to essentially make the git DAG look like a (lie of a) straight-line CVS or SVN commit list. Seeing how the sausage was actually made (no rebases, no squashes, sometimes not even fast-forwards) isn't pretty, but it is meaningful and will tell you a great deal about a project and its developers... I trust that.…
This discussion needs to happen because git is fundamentally flawed. There should be no way to change the history but at the same time you should be able to hide the immaterial commits. (Yes, bzr had this. I still mourn over the demise of bzr.)
Re: Squash your commits
#244I mentioned this in a tweet[0] but we have a quasi-tradition of shipping on April 1st: * https://github.com/blog/1815-l-is-for-labels * https://github.com/blog/1451-branch-and-tag-labels-for-commi... * https://github.com/blog/626-announcing-svn-support [0]: https://twitter.com/gjtorikian/status/715972348860633088
I loved this feature too, but thought it was a joke at first!
Re: Squash your commits
#245Earlier quoted context omitted.
>Seeing how the sausage was actually made, ... it is meaningful and will tell you a great deal about a project and its developers... I trust that. ...tidy commits are aberrations and full of little lies... ...small, harmless lies. Interesting choice of words. Here's another way to think about squashing private commits for public consumption: programmers do not install keyloggers and upload their entire keystroke hist…
«If squashing those commits is a lie, the Backspace key without an audited keystroke log is also a lie.» In a world with infinite storage space and a good UX on top of it, I could absolutely see a case where it might be amazing to have a source control integration with the full undo stack of my editors. VCR roll through someone's efforts Twitch style and grab a box of popcorn as you drinking game your way through the…
Early versions of Microsoft Word kept the undo history in the .doc file. I remember reading about a few cases where someone wrote things like "my boss is an ass", erases it and then sends the report to the boss, boss accidentally clicks undo too much and guess what he sees.
Re: Squash your commits
#246Earlier quoted context omitted.
isn't pretty, but it is meaningful and will tell you a great deal about a project and its developers... I trust that. Here is a (made up), but generally realistic git log git log | grep -i WIP mon 5pm - WIP, going to work on this from home tue 4:45pm - WIP, going to work on this from home wed 2:30pm - WIP, meeting wed 5pm - WIP thu Noon - WIP, working from the cafe on my laptop fri 5pm - WIP, working from home sat 3p…
I think this is a strawman - I don't think anyone is suggesting publishing WIP commits.
Isn't that exactly what the original commenter is suggesting?
> no rebases, no squashes, sometimes not even fast-forwards
Re: Squash your commits
#247This always reminds me of stackenblochen https://youtu.be/Qo_2ReMNzhU
Re: Squash your commits
#248Earlier quoted context omitted.
> Only squash when it removes bug that only ever existed on your machine. Everything else should be recorded in the history. You can squash into master without losing the history of the code review with git. This gives you the best of both worlds, a more accurate history than the one you propose, and a master that isn't broken.
I've often wondered if it would be possible to design a source control system that could track this lineage. Kind of like, "inside" of a commit would be a hidden history that you could unpack if you wanted to. "This single commit is actually the squash of these other commits made by this guy". "This commit is actually the rebase onto mainline of this commit a guy made when his machine was behind". The commit would lo…
Have you used Phabriactor? This sounds an awful lot like a Diff in its terms. "master" is a linear sequence of Diffs being landed, with Diff number in the commit message. You can paste that diff number in the web UI and see the individual commits that were part of it.
Re: Squash your commits
#249Earlier quoted context omitted.
> It's real and visceral and how software is actually made... It's also extraordinarily cluttered, and it really gets in the way when someone later want to do a 'git bisect' to track down when a bug was introduced. When I'm working I do frequent little commits just to capture and back up my broken stream-of-thought experiments. None of those are going to be relevant to people who work with this code in the future; ho…
But squashing makes git bisect even harder, since the chunks are bigger. If you have a very granular history then you can see exactly what 15 line change caused the breakage (though the counterpoint is that maybe there are parts of the granular history that are just busted for other reasons)
Agreed, I certainly don't advocate squashing more commits than necessary! The granular, the better. As I mentioned, I'll often tease apart separate commits out of something that I originally stuffed into a single commit: whitespace changes, add some comments, fix a bug, all separate even if they started out as one commit.
I just don't find it useful to see every commit when someone uses Git like I do, committing all sorts of intermediate broken work while experimenting. Especially not commits that are going to be broken regardless.
Re: Squash your commits
#250Earlier quoted context omitted.
It's not destroyed, it's simply not on master. If you want to push that branch and have the history forever, that is an option.
Anything not stored on the system of record cannot be counted on to exist at any point in the future. From a strategic standpoint, thinking of that data as anything other than 'destroyed' would be a grave error of judgement. From a retention standpoint the difference between 'could' and 'did' is profound.
If you have an issue with people deleting branches that were intentionally preserved to save history that was then squashed onto master, that's not the fault of anyone who squashed their commits but left them preserved on a branch.