Hacker News Reader

Comment by dec0dedab0de | Hacker News Reader

It's pretty easy though. Leave all the commits. Put meaningful messages in your merge commits, and your clean macro history is just merge commits and the messy one is the rest.

View on HN

Merge commits prevent having clean history, because they lie to you. If you "git show" a merge commit, it hides almost all changes because they've been automatically merged, but it doesn't follow that they were merged correctly. This can cause things like gotofail.

You can show the full changes by one of these:

> git show --first-parent COMMIT # perspective of target branch = branch you were on when merging

> git show -m COMMIT # perspective of both branches

Lengthy explanation and more ways to do it: https://stackoverflow.com/questions/40986518/git-show-of-a-m...

Also the following works in my experience and is more easy to memorize because the command literally says what you want to know:

> git diff COMMIT_BEFORE_MERGE..MERGE_COMMIT

I think the scenario you've described assumes that the branches have diverged -- that each branch has a commit not on the other. But if you always rebase your branch onto `develop` before merging, your branch definitively has no conflicts. If you then use `--no-ff` to merge, it will create a merge commit anyway.

This article shows what I mean: https://euroquis.nl/blabla/2019/08/09/git-alligator.html . (The only thing missing is the rebase before merge, since the example image shows a case where a merge could have hidden some changes.)

If you do that then, the diff in git show for the merge commit will always be empty. But I think it's a solvable problem, there just needs to be a better/easier way to say, show the diff between the one side of the merge (usually the first/left) and the result of the merge when showing a merge commit. Or maybe there is an option I'm not familiar with.

That said the rebase followed by --no-ff merge is my preferred approach as well.

If [commit] is the merge commit for the feature, then this should work:

    git show [commit]^1..[commit]

The ^1 incantation means "first parent", so in the feature branch style I'm describing, this would show the changes on all of the commits for the feature merged at [commit]. You can use `git diff` instead of `show` in the same way, if you just want the cumulative diff.

It seems to work on the repository I've been contributing to, as it shows each of the commits that were part of the feature branch. The merge commit itself is empty, as desired, avoiding the up-thread concern of unreviewed auto-merged code.

I want a clean merge history I can run git bisect against. The utility of git bisect is much diminished when the commit history is full of broken commits. It works best when all the commits successfully run the test suite at the time, which is perhaps not the highest standard of "clean commit" we could ask for but my impression is that it puts it fairly high vs. the "commit everything" criterion.

> I want a clean merge history I can run git bisect against.

"git bisect" supports "--first-parent" too.

All of these arguments are of the flavor “git supports —-flag-1%-of-users-know so that works.” But there’s a nontrivial cost to teaching all of your users a non default workflow, which you have to pay for every new person that comes along.

It doesn't matter what git supports if I'm bisecting into history where the tests don't run cleanly on every commit. Now I don't know whether the test case I'm bisecting with is broken because it's revealing the bug or if it's broken because the commit is broken. git bisect is literally mathematically useless if you get even a single --good or --bad wrong.

Doesn’t this require that you get everything right before that merge commit?

I often do this, but then have some integration related change that’s required after.

The change after would just be a new branch and then a new merge. First merge is adding the feature second merge is the bug fix.

Reply on news.ycombinator.com