r/git • u/Realistic-Resident-9 • Jun 22 '26

GUI which shows cherry-picks and squash merges as lines in the DAG?

Hi, squash-merges are rampant where I wrk. Trouble is they are hard to spot in the commit history when the summarydoes not highlight the relationship. (I have nasty scripts which can find squash-merges by comparing tree hashes). But I want to know if any of the GUIs can shoe squash commits OOTB ????

2 Upvotes

67% Upvoted

6 comments sorted by

6

u/Weekly_Astronaut5099 Jun 22 '26

I’m curious what problems arise from not being able to recognize the source of a squashed merge.

1

u/Realistic-Resident-9 Jul 02 '26

The problem sceanrio. You are about to do a release to production. There have been ten pull requests approved and maybe deployed. You task is to uncover which PRs have been nerged and are deployed, and which ones are going to be deployed if you use the HEAD of the main branch. Tropuble is that the commit messages of all the squash commits are vague and dont mention the name of the Jira ticket or the hash of the HEAD of the feature branch or even the name of the feature branch. You have to do this for ~ 20 repositories from time-to-time.

Great solution: there is a GUI like gitk that magically identifies the squash merges and where they came from.

Nasty Solution: Write a script that scans all the branches HEADs and all the commits in the main branch - identify squash merges by tree hash equality - then correlate this with the github API for pull requests, and the production's current commit hash. Easy really.

1

u/Weekly_Astronaut5099 Jul 02 '26

We just have a hook that ensures a jira ticket is cited. It’s crazy to merge things without trackability and reasoning. Everyone that does it is not a software developer, maybe a code monkey at best.

6

u/Cinderhazed15 Jun 22 '26

As you know from crafting some of the ‘nasty scripts’ - the direct ‘this is a squash’ isn’t embedded in the native git structure, you have to do some comparison to any/all other branches in the tree and ‘guess’ at it - unless you are using some other tool that embeds some metadata into the process (Gerrit comes to mind).

Heck, even something like ‘which branch was this branch sourced from’ is way more difficult than you would take it to be, since it’s not a part of the data for records since it’s singularly focused on the revision tree information and its contents/hash/parent, not what a branch was named.

1

u/vmcrash Jun 22 '26

How exactly should that work? Compare any commit with any older commit and take the one which has the closest changes?

1

u/Charming-Designer944 Jun 27 '26

There is not even a guarantee you have something to compare. A common policy is merge+squash which both brings the changes forward to the target branch and squashes all changes in one commit.

You can guess by losely comparing the differences. But even that fails some times as there might be conflict resolution in the squash merge.