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

Fortunately, I don't squash my commits

blog.ploeh.dk

Post reply on HN
Print view View original

161–170 of 333 posts

Re: Fortunately, I don't squash my commits

#161

Post by nemetroid »

KallDrexx wrote: post #145
dastx wrote: post #86

Earlier quoted context omitted.

> squash merge into shared branches Why not just rely on a merge commit instead?

I personally really dislike merge commits because it makes the tree really difficult to follow in most visualizations. If I'm trying to follow the main branch only to a certain point the graph is polluted with all the "WIP" side branch commits between head and the commit I end up getting to. It also defaults to causing the main to have a ton of commits with "Merged from XXXX branch" as the summary lines when that's n…

> If I'm trying to follow the main branch only to a certain point the graph is polluted with all the "WIP" side branch commits between head and the commit I end up getting to.

Using merge commits doesn't have to mean that you don't squash at all. At one extreme, you include every single commit ever made on the branch, and at the other extreme, you squash the entire branch down to a single commit. Using merge commits, you can go for any option inbetween.

> It also defaults to causing the main to have a ton of commits with "Merged from XXXX branch" as the summary lines when that's not nearly descriptive enough to quickly find what type of commit I may be looking for.

Do you often read the log linearly? 99% of the time when I investigate history in Git, it's either through "git blame" or through "git log -S somestring" (search for commits that introduced or removed "somestring"). I rarely, if ever, just read the log as-is.

Re: Fortunately, I don't squash my commits

#162

Post by Aeolun »

m12k wrote: post #66
Kihashi wrote: post #12

Earlier quoted context omitted.

I find the individual commits on feature branches to be more noise than signal after they are merged . They can be useful during review, sometimes, but mostly I want a cleaner history. > they really would like a complete story, not 20 gargantuan commits that contain 3 years of development That sounds like maybe we split up work differently. 3 years of development for me or my team would likely have hundreds+ of merge…

What do you use your "cleaner history" for? I seldom go back and look at historical commits unless I'm debugging, in which case I'd prefer to know what actually happened at the time with as much information preserved as possible.

I’d prefer that too, but preserving all commits often leads to things like: ‘Changed file 1’, ‘Changed file 2 and 3’ etc.

You’ll have a ton of noisy commits that together make up one full feature. In this case having all that noise squashed into one commit with a proper description is much nicer.

Re: Fortunately, I don't squash my commits

#163

Post by Aeolun »

grumple wrote: post #136
delecti wrote: post #124

Earlier quoted context omitted.

I think you just highlighted one source of the disagreement. Nobody on any team I work with would accept a PR with 3000 lines of change. Each team had a policy, whether formal or informal, to break large work items across PRs so they were more easily reviewable. I would say that 300 lines changed is getting towards the bigger end of what we would accept. If your choice is between 30 or 3000 lines changed per commit,…

Yeah, that’s nice in theory, but in practice the situation is often less ideal. Some features, partially implemented, would break existing functionality if not completed, and merging those upstream prior to total completion is therefore impossible. And on the other side of things, some environments and features require large, systemic changes. This is, surely, an organizational failing, but one that we must adapt to.

Convert all the JS files to Typescript, suddenly you get blame ed for everything.

Re: Fortunately, I don't squash my commits

#164

Post by xorcist »

mumblemumble wrote: post #146
xorcist wrote: post #143

This article presents a very good argument clean and squashed commits are important, under a click-baity title. The ability to use git bisect effectively is one of the more important reasons to enforce a clean and readable commit history by squashing and rebasing before merge. A history where the majority of commits doesn't even compile ("sorry, updated test value was wrong", "oops syntax error", "forgot to update th…

I would say that this is a good argument for linearizing the history by rebasing, but certainly not for squashing. Git bisect can only narrow you down to the scale of your commits. If you do infrequent, large commits, it's not very useful. If you do frequent, small commits, it's great . If you do frequent, small commits and then squash them into infrequent, large commits, it's not very useful. There are plenty of rea…

Squashing is a form of rebasing. Nobody suggests commits should be too large to be useful, just that they should form coherent changes. Preferably self contained enough to be useful in their own.

When you do frequent small commits, unless you are superhuman the majority of them false starts or contains errors. Squashing these useless commits makes the history understandable, and enables the use of tools such as bisect.

That's what "please squash before merge" means.

It does not mean you should do rebase instead of merge. There may be good reasons for that too, sometimes, but that's not the point here. Should you wish to enforce a linear history, it is still just as important to squash undesired commits.

Re: Fortunately, I don't squash my commits

#165

Post by adrianmsmith »

Chris2048 wrote: post #135
Pxtl wrote: post #110

Earlier quoted context omitted.

The problem with this approach is the local branch is no longer represented in the shared branch. So if I'm working on a larger feature and want to PR an intermediate part and continue working, I'm in for a bad merge. If I want to merge my hotfix topic branch into both the release and the master branch, their commits won't match so I can't check if it's present in both automatically. If a topic branch is left up inst…

But doesn't that assume that you based your larger feature on the local branch, instead of the squashed public version? If you wanted to build on the previous commit, why wouldn't you build on the squashed version?

> If you wanted to build on the previous commit, why wouldn't you build on the squashed version?

alexmingoia proposed:

> That way one gets clean shared history while preserving local work history.

But if you keep on building upon the squashed versions each time you do a merge, you won't have convenient access to the local work history any more.

If you wanted to have access to the local work history you'd need to keep each branch alive still, each time based on the squashed history plus your individual commits up until the next squash.

Re: Fortunately, I don't squash my commits

#166

Post by UK-Al05 »

Joker_vD wrote: post #2

Do people out there actually squash commits? Granted, I didn't change many work places in my career, but at no place where I worked people squashed commits. What's even the point of it? It's not like people routinely read the commit history, and when they do, they really would like a complete story, not 20 gargantuan commits that contain 3 years of development.

  # Implement feature
  # Whoops fixed issue in feature i just implemented
  # Add in whitespace
  # Remove whitespace
  # Forgot place to add in whitespace
  # Fix variable name for feature
Vs

  # Implemented feature "x"
Which ones easier to rollback and read.

Re: Fortunately, I don't squash my commits

#167

Post by nemetroid »

idoubtit wrote: post #138
m12k wrote: post #98

Earlier quoted context omitted.

If you use the standard merge commit message in git, then you can still tell what branch things came from when being merged. As someone that has used both mercurial and git, the trouble with named branches (and having to remember to remove them when merging to master) is one of the reasons why I prefer git.

Knowing the name of the branch is not enough to find the commits. With Git, a branch is just a kind of moving tag on the last commit. The problem mentioned in this thread is rolling back a feature that was merged. The only solution I know is navigating the log to find the first commit on the branch from which to revert. Don't forget there may have been several merges from and to master, as well as commits shared with…

> The only solution I know is navigating the log to find the first commit on the branch from which to revert. Don't forget there may have been several merges from and to master, as well as commits shared with other git branches that should not be reverted.

The only step necessary to revert the changes from a merged branch is to revert the merge commit. See:

https://stackoverflow.com/questions/7099833/how-to-revert-a-...

https://github.com/git/git/blob/master/Documentation/howto/r...

Re: Fortunately, I don't squash my commits

#168

Post by DarkWiiPlayer »

jerf wrote: post #150
_-___________-_ wrote: post #112

The most striking thing in this story for me has nothing to do with commit squashing. Faced with something that suddenly stopped working, the developer went on a wild goose chase, first decoding their JWT -- presumably the same one that "used to work" -- then looking for possible framework bugs or misconfiguration, before looking at their own code, the single most likely place that the bug would be. They even linked…

"went on a wild goose chase" Because 19 times out of 20, that "wild goose chase" finds the bug faster. As there is no perfect debugging methodology, sometimes whatever method you use will go wrong and you'll end up on the bottom of your list of things to check, or worse, right off the bottom of the list. (Those are some bad days.) That is not, itself, proof that your list is broken. After all, the author found this a…

Over the years I've figured out that you can not only bisect in your development history, but also in the program runtime. Start with "print('1/2')" or whatever around halfway through the runtime of your code and see if you get there, then move to 1/4 or 3/4, etc.

This can be done with break points, of course, but in my setup adding a print is usually just faster.

Re: Fortunately, I don't squash my commits

#169

Post by nicoburns »

Pxtl wrote: post #110
alxmng wrote: post #55

Earlier quoted context omitted.

Programmers can have the best of both worlds. Use granular commits on a local branch and squash merge into shared branches. That way one gets clean shared history while preserving local work history.

The problem with this approach is the local branch is no longer represented in the shared branch. So if I'm working on a larger feature and want to PR an intermediate part and continue working, I'm in for a bad merge. If I want to merge my hotfix topic branch into both the release and the master branch, their commits won't match so I can't check if it's present in both automatically. If a topic branch is left up inst…

> if I'm working on a larger feature and want to PR an intermediate part and continue working, I'm in for a bad merge.

I usually deal with this by `git rebase`ing your feature branch on top of the shared branch as soon as the PR is merged. You sometimes still get merge conflicts with this approach, but they're always in the code you've just written so they're usually pretty easy to fix.

Re: Fortunately, I don't squash my commits

#170

Post by xorcist »

twic wrote: post #57
FeepingCreature wrote: post #14

Earlier quoted context omitted.

I squash commits. Well, I rebase so that changes are logical rather than historical. This is because when people read the commit history, which actually happens regularly, they would actually like a complete story, not 15 commits of "fix audit", "fix review" and "fix typo" - let alone refactors where previous work in the PR is thrown out, which you can by definition never care about. Commits so small that they're non…

Nobody is suggesting you should make commits so small they're non-functional.

Are you simply suggesting the removal of those non-functional commits to be called something else than "squashing"?
Post reply on HN