Two Years of Squash Merge (2019) • Hacker News Board

Re: Two Years of Squash Merge (2019)

#111

Post by tharkun__ » Sat, May 01, 2021, 1:00 AM UTC

waffletower wrote: post #7

Many developers naively sell `git squash` using a clarity argument. By squashing you lose historical information: there are times when the content of a merge requires a paper trail, times when individual commits can aid to separate the portions of a merge you would like to keep versus those you would like to rollback. Perhaps in a 10 times a day release regimen you decide never to look for such history. One size does…

I would argue that you only loose irrelevant information and you gain the ability to rollback. Without squashing, you are actually way worse off for a "10 times a day release regimen". We release every hour and we squash and rebase with a straight master history.

This enables us to almost mechanically just roll back to the previous commit that was out on Prod, should something happen and it's very easy to skip (revert) just one ticket and let the rest go out. No guessing, no manual figuring out which 7 commits belong to the ticket in question, potentially 6 of them had the ticket number in the commit message like they should, but the 7th, which coincidentally is actually commit number 3 in the sequence but interleaved with other ticket's commits the developer switched some numbers and instead of ticket ABC-123 he wrote ABC-132. Now we have a production incident and a completely garbled attempt to undo it.

We have none of those issues. Each ticket is one commit. If you revert one commit, you are guaranteed to have a working piece of software and you won't have a potentially not even compiling intermediate commit that was subsequently fixed up during a PR, which can happen without squashing.

Re: Two Years of Squash Merge (2019)

#112

Post by thom » Sat, May 01, 2021, 1:09 AM UTC

tharkun__ wrote: post #108

thom wrote: post #105

Earlier quoted context omitted.

But that just sounds like an _incredible_ amount of effort and even at the end you still don't actually know the cause of the bug. Surely you just raise it to someone who owns the code in question? It sounds like you know who they are already?

Until you have done it it may sound like an incredible amount of effort but in fact it isn't at all. Your reality might be different, but we also deal with different time zones. In this particular example the other team was in a different time zone and already gone for the day. The easiest and most efficient way was a 'dumb' bisect. If you _only_ raise it to the team in question, you have nothing in hand but suspicio…

If an issue isn't urgent and you aren't going to fix it, why spend time on it? Why not send it to the team that you already know is responsible? Why do you have teams that refuse to investigate their own issues and instead have weird emotional reactions to bug reports? Why are they more likely to accept a git bisect that took zero brain cycles from you rather than do it themselves in zero brain cycles? This all just sounds completely dysfunctional. Flee!

Re: Two Years of Squash Merge (2019)

#113

Post by wbronchart » Sat, May 01, 2021, 1:13 AM UTC

epage wrote: post #85

wbronchart wrote: post #73

I love clean linear history, but I don't like squash&merge, and I don't like the other options that the github interface gives you either. Plug: I wrote a script recently that merges github pull requests but preserves linear git history (basically, rebase + merge) https://pypi.org/project/git-pr-linear-merge/

This is baked into Azure DevOps, I'm surprised they haven't pulled it over into GitHub.

Yeah, you'll find endless threads on github issues of people complaining Github doesn't have this yet. It's a real pain

Re: Two Years of Squash Merge (2019)

#114

Post by JoshuaDavid » Sat, May 01, 2021, 1:39 AM UTC

thom wrote: post #109

LocalPCGuy wrote: post #72

Earlier quoted context omitted.

I don't bisect regularly, but when I do, it's usually trying to figure out what the original reason for introducing the code that is problematic is. The entire point is on projects big enough, you may not be able to just "follow the logic" enough to know that your fix the to apparent bug isn't re-introducing some regression that was fixed previously. So bisect to me, is a way to figure out where and why the code was…

If you've got a codebase where the intent of the code isn't clear, where you can't track bugs, and where you can't fix them without being confident you're not breaking other stuff, surely those are all fundamental problems worth addressing?

Yes, but those things take time to address and in the meantime the need to make changes that address more immediate needs doesn't go away. Bisect specifically helps if you've got an easily reproducible bug in a hairy part of the codebase and you know that bug could be arbitrarily old but is on a path that recently started getting exercised much more often. I use it maybe once a month but when I do it is very nice to have that context of how the bug happened and any other places that might need to be fixed.

Re: Two Years of Squash Merge (2019)

#115

Post by thom » Sat, May 01, 2021, 1:44 AM UTC

JoshuaDavid wrote: post #114

thom wrote: post #109

Earlier quoted context omitted.

If you've got a codebase where the intent of the code isn't clear, where you can't track bugs, and where you can't fix them without being confident you're not breaking other stuff, surely those are all fundamental problems worth addressing?

Yes, but those things take time to address and in the meantime the need to make changes that address more immediate needs doesn't go away. Bisect specifically helps if you've got an easily reproducible bug in a hairy part of the codebase and you know that bug could be arbitrarily old but is on a path that recently started getting exercised much more often. I use it maybe once a month but when I do it is very nice to…

Sure, but at that point there's a whole raft of practices that seem more important than 'having a nice commit history'.

Re: Two Years of Squash Merge (2019)

#116

Post by jaredsohn » Sat, May 01, 2021, 1:49 AM UTC

thom wrote: post #112

tharkun__ wrote: post #108

Earlier quoted context omitted.

Until you have done it it may sound like an incredible amount of effort but in fact it isn't at all. Your reality might be different, but we also deal with different time zones. In this particular example the other team was in a different time zone and already gone for the day. The easiest and most efficient way was a 'dumb' bisect. If you _only_ raise it to the team in question, you have nothing in hand but suspicio…

If an issue isn't urgent and you aren't going to fix it, why spend time on it? Why not send it to the team that you already know is responsible? Why do you have teams that refuse to investigate their own issues and instead have weird emotional reactions to bug reports? Why are they more likely to accept a git bisect that took zero brain cycles from you rather than do it themselves in zero brain cycles? This all just…

Not the GP, but this kind of thing can happen all of the time.

The people experiencing the bug don't know who is responsible so they arbitrarily pick someone. The bug could get passed back and forth endlessly between teams until somebody isolates it a little better and bisecting is a good tool for doing that. Just doing the bisecting rather than arguing with the other team about who should do the bisecting is a way to get things done. If it does turn out to be the other team, it may be easier to convince the other team to take on similar requests in the future.

Re: Two Years of Squash Merge (2019)

#117

Post by JoshuaDavid » Sat, May 01, 2021, 2:10 AM UTC

thom wrote: post #115

JoshuaDavid wrote: post #114

Earlier quoted context omitted.

Yes, but those things take time to address and in the meantime the need to make changes that address more immediate needs doesn't go away. Bisect specifically helps if you've got an easily reproducible bug in a hairy part of the codebase and you know that bug could be arbitrarily old but is on a path that recently started getting exercised much more often. I use it maybe once a month but when I do it is very nice to…

Sure, but at that point there's a whole raft of practices that seem more important than 'having a nice commit history'.

Bisect doesn't require a nice commit history, just a granular one (well, it doesn't require a granular one either but it's a bit less helpful if it lets you identify the problem commit as the +18000/-7000 LOC "Overhaul payment system " than if it drops you on the +3/-3 LOC "fix encoding bug ")

Edit: I should also add that if you use github, squash-merging pull requests is fine because you can pull down and check out the pull request branch and run bisect on that. Or more generally if you don't delete history and keep a record of what commits were squashed to make your giant commit, your friendly local maintenance programmer might grumble slightly but will still be able to work effectively. Just please avoid erasing history entirely.

Re: Two Years of Squash Merge (2019)

#118

Post by ziml77 » Sat, May 01, 2021, 2:12 AM UTC

nemetroid wrote: post #83

nickbauman wrote: post #14

Generally, time spent twiddling with the repo is time not spent delivering code. It's a distraction. Yes git has all these features that lets you do that and those feature matter when you're committing to the Linux repo which has thousands of eyes and your commit history has to help you communicate to a very wide audience. But the vast majority of us are not using git like this. I've used git bisect so rarely all thi…

Time spent "twiddling" with the repo is time spent documenting the business reasons for code changes. Depending on what type of code you're writing, this might be not-so-important or massively important for future understandability.

Business reasons for code changes are kept in JIRA tickets and in merge requests. Comments might also explain business or technical reasons for certain chunks of code.

Commits are just logs of the units of work done to support completing those tasks. They often don't have any real logic for where they're broken up except that it happens to compile or that I want a checkpoint that can be stored remotely for safety.

Re: Two Years of Squash Merge (2019)

#119

Post by tharkun__ » Sat, May 01, 2021, 2:19 AM UTC

thom wrote: post #112

tharkun__ wrote: post #108

Earlier quoted context omitted.

Until you have done it it may sound like an incredible amount of effort but in fact it isn't at all. Your reality might be different, but we also deal with different time zones. In this particular example the other team was in a different time zone and already gone for the day. The easiest and most efficient way was a 'dumb' bisect. If you _only_ raise it to the team in question, you have nothing in hand but suspicio…

If an issue isn't urgent and you aren't going to fix it, why spend time on it? Why not send it to the team that you already know is responsible? Why do you have teams that refuse to investigate their own issues and instead have weird emotional reactions to bug reports? Why are they more likely to accept a git bisect that took zero brain cycles from you rather than do it themselves in zero brain cycles? This all just…

As my sibling already points out correctly, no need to flee, not completely dysfunctional at all and very very common in both functional, semi-functional and yes also dysfunctional companies.

At the point where I have _not_ done the bisect, I in fact do not actually _know_ who is responsible. I have a suspicion, a hunch, an assumption. Assumptions are bad and need to be validated. I can either let the other team that I suspect validate it. If it turns out that I was wrong, I have both wasted their and my own time and reduced my credibility. What then? I try to suspect another team and try the same thing again? That's what happens in a lot of large companies all the time. Nobody looks into anything and just tries to pawn it off to someone else. If someone tried this more than a couple of times with me, I definitely know what I would do the third time around.

They are more likely to accept a bisect from me, because it shows that I am not simply trying to pawn something off to them based on a mere assumption. It shows that I care and that I validate my assumptions and don't just try to pawn things off to other teams and play 'hot potato'. That would indeed be dysfunctional.

Re: Two Years of Squash Merge (2019)

#120

Post by cratermoon » Sat, May 01, 2021, 2:25 AM UTC

jakeva wrote: post #106

cratermoon wrote: post #100

Earlier quoted context omitted.

> In my experience squash messages combine the messages of the commits they consolidate. I believe they do, by default, but the developer gets to modify. In other words, if I squash 3 commits, the git cli will set the resulting message to be a combination of all 3, but opens an editor to let me change it. I'm not for or against any git merge/squash/rebase flow on technical grounds, but I do want every message in the…

I guess I haven't worked on a project important enough where the history is more important than the current state. Usually it's more like it might be useful to gain perspective by looking at the history, only to find it was a conflicted merge or the comment contained no useful info anyway ("Clean up", or "Fix this feature"). Even if it tried really hard to document the purpose of the change, I've rarely gotten more f…

> I've rarely gotten more from a commit message than the content of the code changes in the commit.

That's generally true, but the article is specifically about how a rule/convention/expectation in DNSimple workflow ensures, or purports to ensure, that commit messages are informative. My experience is that it doesn't really matter if the explanation is in the commit message, a bug tracker ticket, or the team wiki, as long as I can go from commit -> understanding, it's good. I also say that if a programmer can't craft a useful commit message, they probably don't have good documentation for it elsewhere.