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

181–190 of 333 posts

Re: Fortunately, I don't squash my commits

#181

Post by Chris2048 »

adrianmsmith wrote: post #165
Chris2048 wrote: post #135

Earlier quoted context omitted.

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…

I suppose you could cherry-pick the new branch onto the squashed version, but I'm still not sure of the value.

You have the local work history already, and that work is done to the point of it being squashed and pushed. Why would you need to keep referencing it to the point that it's inconvenient to have it in another branch?

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

exactly what I do, and there are maybe just three or four branches I maintain for reference, very few squashed branches are useful a couple of weeks after they are released.

Re: Fortunately, I don't squash my commits

#182

Post by l72 »

fs111 wrote: post #6
aurelianito wrote: post #3

I never understood the need to squash commits (or rebase). If you do merge requests and use merge commits (like GitHub or gitlab do). A "nice" history is a small script away. It should even be a part of the GitHub/gitlab gui. Do not loose information about the development history!

Merge commits are noise, a clean history is has no merge commits

I think this depends on your policy. The policy at my work place is that every commit into master is always a merge commit. When looking at the git logs, we then always do:

  git log --first-parent
This only shows the top level commits (either a direct commit or a merge commit) and doesn't show any of the subcommits in the branches.

This gives us a very clean history, something like:

  commit ce29331f7da82ce528ca6e437b8893248a842169
  Merge: a14522cbf 936ef9f90
  Author: Joe Sample 
  Date:   Tue Jul 7 14:25:41 2020 -0500
  
      ISS-2045 - Return a reason of why the invitation was auto-cancelled
Then if I want to see everything that happened in the branch that was merged in, I can just run:

  git log d083421702e3ff50bc4c62e85b687e172e4bfe76^..d083421702e3ff50bc4c62e85b687e172e4bfe76
and see all the commits that were in that feature branch. No need to squash things or hide them.

I really wish git, by default, showed commits under a merge as a tree, rather than as a flat list. This is what bazaar (bzr now breezy) did, and it made a lot more sense when looking at the history.

Re: Fortunately, I don't squash my commits

#183

Post by bananaface »

nicoburns wrote: post #169
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…

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

The problem with rebasing is you might break every one of those commits, which defeats the purpose of chunking the work like that in the first place (since its no longer an honest reflection of what was happening/what worked at each point).

Re: Fortunately, I don't squash my commits

#184

Post by [deleted] »

dcolkitt wrote: post #178
davewritescode wrote: post #45

The reason to squash commits is more than just keeping your commit history read-able, it's about making easy to revert a feature and being able to keep history in a way that makes it simple to revert a change if you run into issues. If I rollout a rewrite of an endpoint and run into a weird issue in the QA environment, I'm a simple git revert away from fixing the issue. If I had spread that endpoint across 25 commits…

I wish git had a builtin notion of two different types of commits: working commits and release commits. I really like making tiny, continuous commits as I work. It's a great flow. git-revert becomes a Ctrl-Z on steroids. I don't what to clutter up the "official" history, with all these tiny changes, many of which don't even compile. That breaks git-bissect and all kinds of other flows. So the only option is to squash…

[deleted]

Re: Fortunately, I don't squash my commits

#185

Post by IggleSniggle »

dcolkitt wrote: post #178
davewritescode wrote: post #45

The reason to squash commits is more than just keeping your commit history read-able, it's about making easy to revert a feature and being able to keep history in a way that makes it simple to revert a change if you run into issues. If I rollout a rewrite of an endpoint and run into a weird issue in the QA environment, I'm a simple git revert away from fixing the issue. If I had spread that endpoint across 25 commits…

I wish git had a builtin notion of two different types of commits: working commits and release commits. I really like making tiny, continuous commits as I work. It's a great flow. git-revert becomes a Ctrl-Z on steroids. I don't what to clutter up the "official" history, with all these tiny changes, many of which don't even compile. That breaks git-bissect and all kinds of other flows. So the only option is to squash…

You could get this behavior pretty easily with a double merge: “main” which contains the squashed commits and “history” which contains all commits as well as “main” merged back in post-squash.

I do see your point though.

Edit: the only reason to merge “main” into “history” is to enforce convergence.

Re: Fortunately, I don't squash my commits

#186

Post by LanternLight83 »

matheusmoreira wrote: post #148
Aeolun wrote: post #123

Earlier quoted context omitted.

If you can fast forward the fact that the branch ever existed was irrelevant, since the branch is a direct child of what you based it on. Just with a different name.

It's not irrelevant. The branch represents a feature, a topic. It groups the commits you're merging into one logical set. This grouping of commits is exactly what will let you revert the feature later if it causes problems.

I've always been frustrated by losing my topic branches once they're merged and deleted, but can't bring myself to clutter my local branches keeping them around, to the point of tagging them just to keep track- I like the sound of your argument and will look into how fast-forward effect my commit history vs. a merge commit, thx c:

Re: Fortunately, I don't squash my commits

#187

Post by madhadron »

dcolkitt wrote: post #178
davewritescode wrote: post #45

The reason to squash commits is more than just keeping your commit history read-able, it's about making easy to revert a feature and being able to keep history in a way that makes it simple to revert a change if you run into issues. If I rollout a rewrite of an endpoint and run into a weird issue in the QA environment, I'm a simple git revert away from fixing the issue. If I had spread that endpoint across 25 commits…

I wish git had a builtin notion of two different types of commits: working commits and release commits. I really like making tiny, continuous commits as I work. It's a great flow. git-revert becomes a Ctrl-Z on steroids. I don't what to clutter up the "official" history, with all these tiny changes, many of which don't even compile. That breaks git-bissect and all kinds of other flows. So the only option is to squash…

I go one step further and work entirely in get rebase -i where I build up a stack of tiny, incremental commits. This also lets me get small changes reviewed and committed on a nearly daily basis instead of building up days or weeks of work.

I've been wishing for a git GUI that lets me drag hunks around such a stack so I don't have to keep moving them by hand.

Re: Fortunately, I don't squash my commits

#188

Post by StanLindsey »

rutthenut wrote: post #156
simias wrote: post #58

Earlier quoted context omitted.

I often do intermediary commits that don't compile or break something significant, only to make sure that I don't lose the code. When that happens I always squash my commit afterwards once the code is in a usable state. The alternative is making bisecting harder which is not something that I want. I want every commit to compile and be testable individually. That definitely doesn't mean that I think it's a good idea t…

I'm a bit confused on your comments here. You state "I often do intermediary commits that don't compile ... to make sure that I don't lose the code" And follow that with "I want every commit to compile and be testable individually."

I'm the same as OP. I commit constantly when hitting a natural stop point or when taking a break and push up to my branch/pr. I hate having code locally that hasn't been pushed to the origin.

But doing this means I have many commits that don't mean anything or are unfinished and in an uncompilable state.

So I git rebase and massage the history to make more sense.

Re: Fortunately, I don't squash my commits

#189

Post by amenghra »

dcolkitt wrote: post #178
davewritescode wrote: post #45

The reason to squash commits is more than just keeping your commit history read-able, it's about making easy to revert a feature and being able to keep history in a way that makes it simple to revert a change if you run into issues. If I rollout a rewrite of an endpoint and run into a weird issue in the QA environment, I'm a simple git revert away from fixing the issue. If I had spread that endpoint across 25 commits…

I wish git had a builtin notion of two different types of commits: working commits and release commits. I really like making tiny, continuous commits as I work. It's a great flow. git-revert becomes a Ctrl-Z on steroids. I don't what to clutter up the "official" history, with all these tiny changes, many of which don't even compile. That breaks git-bissect and all kinds of other flows. So the only option is to squash…

You want this for git: https://www.mercurial-scm.org/wiki/GroupExtension
Post reply on HN