Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Squash your commits

github.com

Post reply on HN
Print view View original

111–120 of 350 posts

Re: Squash your commits

#111

Post by hnrodey »

jh3 wrote: post #85
munificent wrote: post #30

Earlier quoted context omitted.

> incompetent at using git This unfairly places the blame for Git's utterly shitty UX on the part of the users. When you have thousands of users who struggle to use a tool correctly, it's the tool's fault, not theirs. I've been using Git for years, work professionally full time on an open source project that lives on GitHub, maintain several open source projects with a number of committers and generally live and brea…

> I still fucking hate rebasing and get tripped up by it on the few times I end up having to deal with it. When I had no understanding of what was going on, I didn't like it either. Now that I use it frequently, I understand it better, so I don't hate it anymore. I like running `git rebase `, where is typically master, in my-new-thing branch because it lets me deal with any conflicts from upstream one by one. I also…

Genuinely curious, why the love for the `git rebase -i`? I find it much easier and more intuitive to squash a set of linear commits on a branch using `git reset --soft HEAD~n` where n is the number of commits to go back and "undo". Then make one more commit and you're off to the races. Note: this is not useful if force push is disabled and you've already pushed some of the commits to the remote (feature) branch.

Re: Squash your commits

#112

Post by WorldMaker »

phasmantistes wrote: post #69
WorldMaker wrote: post #59

Sometimes 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.…

I actually disagree. Large teams that still have linear commit histories doesn't mean it is a lie. It means that the code review process is more important that the code writing process. For example: I check out a repository, and create a local feature branch. I create a commit containing the tests for the new feature, then one for the first draft of the new feature, then two or three for bugfixes. Each commit is smal…

«Making the code review the atomic unit of work, rather than the messy string of local commits, helps the project enforce common etiquette, commit formatting, and readable history.»

I agree that code reviews should be important, and key to understanding the history of a project at a more useful timescale. I just disagree that they should be "atomic" and that a reviewer (even, or especially, a later code archeologist) may not have reason to inspect or dive into smaller units within code reviews.

Where I think that we may agree is that I feel that even if they shouldn't necessarily be "atomic", I agree that code reviews should probably be first-class objects when talking about and dealing with source control. In git, you can use --no-ff merges today as a useful approximation of code review boundaries (especially with PRs and GitHub's default --no-ff and including linking PR #s). It might be nice to see code reviews or other aggregates of commits/commit graphs be truly first-class citizens of git in some manner.

Re: Squash your commits

#113

Post by lotyrin »

phasmantistes wrote: post #69
WorldMaker wrote: post #59

Sometimes 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.…

I actually disagree. Large teams that still have linear commit histories doesn't mean it is a lie. It means that the code review process is more important that the code writing process. For example: I check out a repository, and create a local feature branch. I create a commit containing the tests for the new feature, then one for the first draft of the new feature, then two or three for bugfixes. Each commit is smal…

Yep, the key to understanding git (why there's mutable history, etc.) is to understand that because of its history (designed by Linus) it's not designed to make day-to-day developers's lives easier, but to serve foss project maintainers and release engineers.

People who review code for inclusion in a project, want to track meta-progress on issues, want to pin versions for release, etc., mutable history means they can squash fixups or fix your whitespace for you, rebase changesets onto other changesets, have history that reflects the project management strategy, etc.

Re: Squash your commits

#114

Post by alanh »

jh3 wrote: post #85
munificent wrote: post #30

Earlier quoted context omitted.

> incompetent at using git This unfairly places the blame for Git's utterly shitty UX on the part of the users. When you have thousands of users who struggle to use a tool correctly, it's the tool's fault, not theirs. I've been using Git for years, work professionally full time on an open source project that lives on GitHub, maintain several open source projects with a number of committers and generally live and brea…

> I still fucking hate rebasing and get tripped up by it on the few times I end up having to deal with it. When I had no understanding of what was going on, I didn't like it either. Now that I use it frequently, I understand it better, so I don't hate it anymore. I like running `git rebase `, where is typically master, in my-new-thing branch because it lets me deal with any conflicts from upstream one by one. I also…

Congratulations on learning it, but that hardly means that it’s particularly user-friendly or intuitive.

I also like rebasing from time to time, but I do feel like I’m tiptoeing on a tightrope above the alligator pit when I do so.

Re: Squash your commits

#115

Post by hnrodey »

dsmithatx wrote: post #32
natrius wrote: post #25

Earlier quoted context omitted.

I used to strongly believe what you do until my company started using Phabricator, which forces the squash workflow on you. It makes your history more useful, not less. The pull request is the appropriate unit of change for software. Make small commits as you develop, then squash them down into a single meaningful change to the behavior of your software.

As a git novice I wonder, doesn't a proper workflow do the same thing? When I submit a feature branch it might have a lot of ugly commits. However, once I merge it to an integration branch there is one nice commit explaining what I did. When coworkers create Pull requests I don't go through all of their commits and changes along the way. I just look at the diff so, I don't see the need for them to squash it first.

Once merged, the history of your feature branch becomes part of the history of the integration branch.

Sounds like you're using GitHub (Enterprise) or something similar where the pull request view shows you all of the changes in a "squashed" fashion.

Re: Squash your commits

#116

Post by yxhuvud »

lomnakkus wrote: post #54
cballard wrote: post #18

Earlier quoted context omitted.

Small PRs are an issue because PRs are dependent on other users and can't be dependent on a prior PR. Let's say we're adding an interface/typeclass/protocol and a concrete implementation. I'd say these should be two separate commits, as they're adding two different things. An interface doesn't require a provided implementation to work. But, if we were to create those as two separate pull requests, it would be more wo…

> and can't be dependent on a prior PR. This pinpoints the major problem exactly. Without dependencies between PRs there's really no sane way (with this feature enabled) to submit a series of commits while expecting those commits to remain separate . Oh, and I object to the general sentiment in the responses to your post that seem to value drive-by/inexperienced contributors over the "experts". Yes, we definitely sho…

Yeah, it is also the obvious thing that is missing in the review stage of a pull request - viewing all the content and all the diffs separately but on one page, in a serial way that corresponds to the actual order they will show up when you do git log, all on the same page.

Re: Squash your commits

#117

Post by pg_is_a_butt »

jasode wrote: post #97
WorldMaker wrote: post #59

Sometimes 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.…

>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…

side note: you're also a lie

Re: Squash your commits

#118

Post by educar »

A bit OT but a feature I would love to see in git is to be able to see which branch a commit came from. Especially for shortlived branches which we prune periodically on the server (git branch -r --contains won't work as a result)

Re: Squash your commits

#120

Post by yxhuvud »

haberman wrote: post #22
cballard wrote: post #10

This is a bad idea masquerading as a good idea. Before making a pull request (or doing any sort of merge), you should rebase against upstream master (or whatever you're going to push to). However, keeping distinct atomic commits that change one and only one small thing, when possible, is much preferable if bisect or blame is used. If you have broken or poorly written commits, use fixup, reword, squash, etc. in rebase…

There's no guarantee that every individual commit of a feature branch is meaningful, or even builds. It also makes the history of the master branch a lot harder to read when it has tons of commits representing the minutiae of the feature's development.

If it isn't meaningful, then that is something the review stage should catch.
Post reply on HN