Review: GitHub "squash and merge" versus "merge pull request" for pull requests

I have been using "squash and merge" for a few months and just recently switched to "merge pull request" in GitHub. My opinion is that "merge pull request" is much better option than "squash and merge" for our case.

Brief Background

Here is a brief background to my case. The software development process (10+ developers) for this "project" is extremely chaotic and monolithic so a lot of changes are deployed "chaotically" which basically means they deploy whenever developers and/or testers think it is ready. So I may get changes A, B, C, D, E, F but may be deployed C, A, E, F, possibly never B, and D could be "maybe" on hold for a year or tomorrow.

For some reason, I am responsible for the implementation of git (with no prior experience). I am a deployment manager (technically release coordinator... whatever that means). Please forgive if I butchered the purpose of git. Also our tech team is extremely reluctant to change which means I am not going to change process over a minor issue even if it is the industry norm.

Environment

We have 3 environments: DEV, STG, and PRD. 

Each has only a single instance. Master branch is what is in production. 

Stage branch is what is in stage. Stage branch also almost like a fork of master but still technically a branch. By this I mean it is a branch that I never merge with feature branches or master branch. All changes are cherry-picked from the feature branch. 

The feature branch is a clone of master. All pull requests are for the feature branch onto master branch.

Please accept that this is the scenario. As to why we do it this way will be too long to explain for this post.

Squash and Merge

Pro

This was pretty cool to see on the git history. A nice single line and easy to see issues with merges. As I will learn later, this is a very minor pro.

Con

Although I knew that a squash and merge created a new commit id, I didn't fully realize what implications this meant.

For a long period of time, I have been merging the changes to master so I have been doing all the conflict resolutions in git. While trying to get the developers to get into the practice of merging master into their feature branch (particularly really old changes), I found that there were a lot of differences from my personal expectations.

I had thought that git will compare the differences to the final result, but it actually compares the commit history. Because it is a new commit id, this throws a lot of flags at git.

Merge Pull Request

Pro

Merges are much simpler if developers update their feature branches with changes from master branch.

Con

"Messier" history. It's not pretty looking. But from my experience, there has been no real value to seeing a pretty history because there is nothing to get from it. With a merge history, git will know which commits to merge. Also if there is an issue, there is more information in the history. A clean history won't be very helpful.

Conclusion

"Squash and merge" is positive only cosmetically. When things are good, I don't need to look at the history. When things are not good, there is usually not enough information. "Merge pull request" is helpful in both the merge and in troubleshooting. For those who skipped the above, this is based on our process.

If we following a process that was closer to FIFO, then the Merge Pull Request would be slightly less beneficial which I then can potentially see a case for Squash and Merge. I would still prefer Merge Pull Request.

If there was maybe a case for using Squash and Merge, that scenario would be if pull requests were on the development branch (eg feature branch). I have lots of commits of minor fixes and I want to bundle them all together so there is less commits to review when troubleshooting.

Buggish: Microsoft Office365 Excel (Web) Copy/Paste is so aggravating

I completely dislike how Microsoft implemented its copy/paste feature on the web. It completely ruins how copy/paste for EVERYTHING else even its own operating system. I just want to simply copy/paste a data from one cell to something else. Anything except a directly copy/paste from cell to cell is always questionable on why it works or doesn't work (even cell to cell is questionable in my mind but seems to at least work most of the time).

Why?!?! It is the most tested and used feature.

I just want to a text inside of one cell to a text inside another cell... same sheet, same row. Simple? Of course, Microsoft does not want it to be! Worst is to cut it because the original data is GONE so what am I supposed to go back to if the paste doesn't work? Obviously, I have to undo but that also messes with the clipboard. How stressful it is just to copy/paste!

What could possibly be wrong? I HAVE ABSOLUTELY NOT IDEA! I just do it again and it will sometimes work and sometimes not. I just keep repeating until it works. No seeable changes to the steps. I even tested with other applications and they all copy/paste fine. So is it memory? Doesn't seem like it. I tried with the same browser and even the same tab. Is it the browser? Doesn't seem like it too. But for stupid's sake, I even rebooted and perform the same task first with no other applications open yet... and yet, not always!

WHY?!?!

While on this topic... why does inserting or delete a wrong clear my clipboard? Why does double-clicking into a cell SOMETIMES clear the clipboard? SOMETIMES? Why is it even SOMETIMES? I rather have the row insert where it is always cleared.

Oh is it just a temporary clipboard for web Excel? Nope, even if you do not copy/paste or copy from Excel (ie you had copied something from another browser, app, or even the app version of Excel)... it is completely gone.

Also, sometimes it'll appear to copy (where the border changes when you normally copy) then when you paste, it says the data is not available. Why does that happy? No clue. How to workaround? Repeat until it works. Sometimes it takes 10s of times until it works. I can even copy/paste in the middle with other apps and it will work perfectly fine. I can copy another row to change the border cell, go back to copy, and it still won't work. I can wait minutes, hours... and it will won't paste even though the message says to give it time. Perhaps Microsoft is a black hole and time works differently there because copy/paste works perfectly fine before, during, and after this issue. Seems to ONLY be the web version of Excel. It is also funny that there are more issues with pasting from web version to app version of Excel than everything else combined.

I think this is very border-line "Not recommending to others" deal-breaker. Especially if you have the manual task of copy/pasting menial tasks.

Even worse... I've been having this issue for over a year now. I even posted this here, Buggish: Microsoft Web Excel Copy/Paste (https://douglastclee.blogspot.com/2023/09/buggish-microsoft-web-excel-copypaste.html).

WORK LIFE: Do or do not keep meetings short?

I just read this blog: https://timdenning.com/overly-productive-people/

I actually put on my resume and accomplishments that I have shortened meetings from 2 hours to 30 minutes, so I thought this read was interesting and I do agree on a lot of the points it made.

I do a lot of small banter, small talk, and weather. I agree that it is important to connect to people.

The post also mentions to avoid saying that I am busy because it makes it seem my time is more valuable than others. I also agree with this. In my meeting, I say that I want to keep it short to save everyone else's time.

I think this post does a good job of too much trimming to short meetings. I do believe a lot of meetings ARE too long but for reasons not listed on the post (which makes sense as it is not the point of the article).

For me, it is important to keep topics that seem to only address less than 10% of the attendance to a separate call. I do give them a minute or two because it usually takes me a couple minutes to know if the conversation is going off tangent. I do my best to interrupt and side-bar the conversation. (I do not understand why people still do not understand this concept after working with them for 4 years now but that is outside my control so I do my best to change course.)

Sometimes the small talk goes a little too long. I found the most affective way is to just continue the meeting topic. If I add something to the banter, this may trigger someone to rebut or one-up or just wanting to put in the final word. After 10 years, no one has complained about this method and I haven't noticed anyone take offense to it. Most people have complimented me on my meeting management and I also get the highest attendance rate in all companies I have worked for. That is including upper management who I rarely see in other calls.

I also make sure that the majority of my attendance are impacted by the majority of the meeting agenda. I do not like having full teams on my calls for status updates. I recommend team leads to join the calls then they can distribute the information as needed. This also encourages team leads to know what is going on (which I think is helpful for the team leads that are not leaders; I hate having team leads that just delegate to another individual for status because to me the basic team lead should at least know the status).

If I see managers forward to another individual that I do not believe will be helpful to them, I do remind the individual of the meeting agenda and their presence may not be needed.

Of course I am biased to my own meeting style, but I find the frequent attendees of my meetings are much more relaxed and focused which I believe is through the small communications that is mentioned in Tim Denning's post.

Take the title with a nuanced take on the topic. The content has some good things to say and is a recommended read.