GitHub's Missing Merge Option

https://tylercipriani.com/blog/2022/09/30/githubs-missing-merge-option/

by thcipriani • 4 years ago

91 108 4 years ago

tylercipriani.com

epage• 4 years ago

What I wish github supported was "git rebase && git merge --no-ff", or as Azure DevOps calls it "semi-linear merge".

A fairly linear history is a lot easier to read but it is nice to preserve the branch by having a merge-commit.

saghm• 4 years ago

That's what I prefer to use when merging locally (often from a cleaned up version of my feature branch). I'd for for it to be added, but at this point I honestly just wish there were a way for me to manually push and then have it be tied to the PR in some way that shows it as "merged" rather than "closed", since that would essentially handle not only my preference but any possible one someone could have in the future. It would be cool if there were some flag I could specify with a PR id or something when pushing, but I'm not really sure that's feasible without some sort of standard protocol, since I don't expect (and wouldn't want!) git to put in Github-specific functionality. I'd certainly settle for some menu item in Github's PR view for a maintainer to be able to do something like select a recent push from a menu to then be attached to the PR's metadata for future viewers, but at this point I doubt it will ever be added.

q7xvh97o2pDhNrh2• 4 years ago

Genuinely asking: What's the value prop of having the merge-commit in the history for you? Have you ever capitalized on it? And if so, could you share the command-line-fu that's helped you take advantage of having such a commit in your repo history?

I'm asking because I used to do exactly this and feel much the same way as you — I felt it was nice to preserve the historical context.

At some point, it dawned on me that, amidst all the anecdata I'd acquired, I'd never once benefited from having those commits cluttering up the history.

These days, I usually advocate "squash & merge" for the 80%+ of teams that lack the discipline to write good commit messages for every one of their branch commits. And, for those rare teams where every engineer writes thoughtful commit messages on their branches (a true delight!), I savor being able to do "git rebase && git merge --ff".

Either way, we end up with a lovely linear history of (hopefully) atomic commits.

chrsig3• 4 years ago

it's way easier to revert the merge commit than potentially every commit that was included in it.

having everything squashed into one commit can be annoying if the commit is too large, because it can be hard to identify why a specific change was made via git blame.

With a merge commit, I can make individual commits for logical changes, potentially rebasing, or squashing commits together. that also gives an opportunity to write more intentional and informative commit messages. once i have a good changeset, I can publish a single PR for review.

I've only really taken to this approach lately, for a long time I just didn't care. As the years go by, I care more and more about what git blame can tell me. I've been maintaining some projects for a long time, and I've had to pick up many projects that don't have their original authors available for consultation. In both cases, having a quality git commit log is just a time saver.

I don't care about preserving the history from when the code was initially typed, I care about the context the log can provide me about the change sets that have been applied. I've been debating starting to include it in my code reviews: "this commit log needs more details: can you edit the commit message and do a git push --force?"

If you're dealing with a more junior team, or people that don't care about the log, it's really a toss up for me. Roll your dice on maybe an informative message helping you, or sift through 15 commits saying "poke", or squash an enormous commit and get a single sentence about it.

cyphar• 4 years ago

I believe that git bisect is a bit smarter when there are proper merge commits (it won't test a random patch in the middle of a patchset unless it's figured out that the issue is in that merge). You can also revert an entire merge in one shot (but this is also true for squash-and-merge).

However, given that you're comparing this to squash-and-merge, you might see most branches to merge as being something that is reasonable to make a single commit (in which case the above feature isn't useful to you because all of your merges are single commits anyway -- and in that case there is little benefit of having merge commits, though I also use them for tracking who reviewed a patch).

I suspect this comes down to the environment you are working in -- if you are working on an internal repo then it is much easier to make separate pull requests for smaller changes (and in that case squash-and-merge makes sense) but in open source projects where it makes more sense to batch sets of changes to reduce the amount of round-trips spent doing reviews, squash-and-merge would cause its own issues (you wouldn't be able to have small commits for logically separate changes). I regularly make pull requests that have >3 commits which cannot be reasonably squashed without making things more annoying down the line if we ever have to revert or bisect something (or even just doing git blame -- it reduces the amount of work when you're spelunking in the git history).

seba_dos121• 4 years ago

git log --first-parent

git log --graph --oneline

As long as we're not talking about single commit merges, these merge commits don't clutter the history; they enrich it.

u801e7• 4 years ago

What's the value prop of having the merge-commit in the history for you?

The merge commit contains the sha values of the parent commits. For example, if merged a branch that could otherwise be a fast forward merge using the --no-ff option, then you get a merge commit, but the commit does not change any of the files compared to the HEAD commit of the branch you merged.

Having the parent commit sha values allows you to see the commits that were in the branch that was merged even after it's merged. For example

    git log merge-commit^1..merge-commit^2

Would show the commits made in that branch. Or you could run

    git diff merge-commit^1..merge-commit^2

to get the overall diff introduced by the commits in that branch.

These days, I usually advocate "squash & merge"

The disadvantage of doing that is that those commits can't be reverted easily (without conflicts). If the commits were separate, it's easier to revert a single one since it affects fewer files or lines within a file.

MrPatan2• 4 years ago

Genuinely asking: What's the value prop of having the merge-commit in the history for you? Have you ever capitalized on it? And if so, could you share the command-line-fu that's helped you take advantage of having such a commit in your repo history?

I recently reverted one of those, and it was much easier because it was a single commit, I just had to pick the right parent to revert to.

I'm not bothered about dev branches commit messages, I consider them a backup of my local workspace anyway. But my dev branches are pretty short-lived, maybe that's significant.

sudo_chmod777• 4 years ago

Vote here: https://github.com/community/community/discussions/8940

drewcoo• 4 years ago

Well if we're going to start adding wish list items . . .

I would like decent distributed bug tracking such that I could follow a bug from first detection through branching and merging and forking until fix and then follow the absence of bug through branching and merging and forking.

No more centralized bug trackers. Death to Jira!

mwint• 4 years ago

In a perfect TDD world, you could write a test for the bug and let bisect figure out where the bug first appeared and when it was fixed.

Hard to do, but when I was at a big company they had something similar.

masklinn7• 4 years ago

Good luck with that.

The idea of a distributed bug tracker was in vogue in the first years of the DVCS rise.

The problem is that it doesn’t really make any sense, or at least nobody managed to make it make sense: a bug tracker is a synchronisation point, and a bug is a cross-cutting concern, and one which outlives it’s fix.

kayson2• 4 years ago

I'm not sure I'd call Rebase & Merge clean... If you do it you get duplicate commits (the hash is different but the content is the same). It appears clean if you look at the commit history for a given branch on Github, but it's not all that clean in git itself.

I work on smaller scale projects and set up a work flow where development is done in a develop branch, and main is locked behind PRs so everything gets CI'd and reviewed before its CD'd. I'm definitely on "Team Clean", because I think it works better for projects of our size, but the only way to get a rebase and ff merge is to do it locally and push to main, which I've blocked for safety.

Maybe there's a solution but I couldn't figure one out.

masklinn7• 4 years ago

I'm not sure I'd call Rebase & Merge clean... If you do it you get duplicate commits

Which matters… how? The duplication will disappear when you nuke the development branch.

MathiasPius• 4 years ago

One way in which it is useful, is that you can tag your build artifacts (like docker images) with the commit id in the development branch, and just re-tag them when you want to promote the artifact to main or production, or whatever.

Without this option, you have to either rely on branch names when promoting, which means you can't tie your build to a specific commit in your main branch anymore[1], or you can rebuild your image from the new commit, potentially producing an entirely different artifact which might differ from the one you just tested and validated on your development branch.

[1] Unless you back-fill that information after merge, but the workflow is getting really convoluted at this point.

kayson2• 4 years ago

That's never going to happen if development is ongoing, though. Especially if multiple people are working on it

Ferret7446• 4 years ago

Why do people think that having branches in their history is "unclean"? I'm struggling to understand what is the issue here.

yakkityyak• 4 years ago

I'm betting that a perfectly linear git history is probably easier/nicer to have for people who think of git as a sequence of deltas.

That is not how git works, but I can understand the appeal. For all my personal projects I squash and merge everything.

teraflop2• 4 years ago

If you have a Git repository with merge commits that merge changes back into your main branch, all you have to do is "git log --first-parent -m" to get a log that looks exactly as if you had squashed and rebased every change.

I'm surprised I don't see more people talking about this option. Sure, the syntax is inelegant, but it seems like it gives you the best of both worlds: you can browse your history as if it was linear, and drill down to the individual commits in a branch only when necessary.

tsimionescu2• 4 years ago

This depends less on how you conceive of Git, and more on the project's development model. For example, in a team using Git for an internal product, with a centralized repo a main branch and (relatively short-lived) feature branches, the conceptual history of the repo is linear. Seeing all of the merges that everyone did when getting into work is line noise, not likely to be meaningful - so rebasing feature beanches on master every day and then doing squash or FF commits when merging back into master makes the most sense.

Alternatively, for an open source project with no "blessed", and with long-lived branches that get contributed by various orgs, trying to make the history appear linear would help nobody.

So obviously this kind of model wouldn't work for Linux, but it works better for most in-house software using Git as a centralized VCS with some nice offline history features.

kortex2• 4 years ago

Because it is visual noise. It's really hard to track, especially on the CLI. It's also a lot easier to reason about the codebase through time if it's basically a linear track.

We started off with merge commits and moved to squash rebase (team history to team clean), and I gotta say, I absolutely love team clean in the overwhelming majority of cases.

The only time team history is handy is as a sort of temporary space on feature branches where you are sorting out complex merges, debugging, or trying different patterns. But all of that gets squashed away onto main eventually.

ilammy• 4 years ago

It's really hard to track, especially on the CLI.

    git log --first-parent --max-parents=1

Now you don't see merge commits.

Forbid merge commits with conflict resolution, and you're done.

raggi• 4 years ago

git log --topo-order

seba_dos121• 4 years ago

I can perfectly understand the appeal of keeping the history clean by requiring ff-only merge commits, but I fail to see any proper case where squash rebase is actually useful in any way. It only loses potentially useful information and doesn't give anything in return. The only usefulness I can image getting out of it is throwing away garbage commit messages and fixup commits made by people who didn't bother to get them right, which sounds like something to fix in the first place.

When you want to maintain linear history, FF-only merge commits allow you to have cake (keep properly atomic changes retained) and eat it (filter out the detail in git log when it's unwanted). Squashing (eating cake) or rebasing with no merge commit (having cake) only makes things worse from there.

generationP• 4 years ago

When merge commits involve conflict cleanup, they are very hard to debug (at least with standard tools like tig/gitk/diff; there might be something more advanced). I've seen lines of code disappear into nowhere in merge commits. You can only hope the conflicts were resolved well.

Even conflict-free merges can be scary -- you're trusting the system to find the right context. Of course, the same errors can happen on rebase, but at least the resulting commits can easily be inspected.

georgyo• 4 years ago

The problems here come from the fact that a "merge" commit is just a normal commit with multiple parents.

This means that anything can happen inside that merge commit, including add, remove, and modify all the code, even if not touched by a parent.

Merge commits are good place for a malicious actor to hide changes.

dataflow• 4 years ago

Do you have a useful & understandable mental model for "delta"-based operations like "rebase", "revert", etc. for arbitrary commit DAGs? Admittedly I haven't sat down to think about it for very long, but I feel like I'm not the only one who feels like lots of operations (including those) become difficult if not impossible to reason about with nonlinear history.

gregmac• 4 years ago

I can see it being an issue with people that don't bother to keep clean git history? Eg, that write commit messages like "fixed bug" "oops" "more stuff".

I'm on Team Write-Good-Commit-Messages. The key of being on this team is learning interactive rebase: of course everyone makes mistakes, but by rebasing before you push no one has to know you did. When the commits are clean, the history is clean.

Write good PRs, too, and make sure they translate to good merge commits. Then you can run `git log --first-parent master` and get a pretty decent high-level overview of changes, but with all the other benefits of keeping individual branch commits in history.

u801e7• 4 years ago

> An eternal war rages between team “git log should be clean” vs. team “git log should have an accurate history.”

Having a clean commit history makes it easier to utilize commands like git blame and git bisect. I'm not convinced those who want to have an accurate history really understand what they want. For example, if after every single keystroke, I saved the file, added it to the index and ran git commit -F - <(date), then I certainly could have a comprehensive history detailing every single keystroke I made as I edited the code, but the history would not be very useful when looking back on it.

> Team Clean
> Methods: git merge --ff-only or git rebase && git merge (extreme clean freaks add the --squash option)
> Pros: Linear history, git log is easy to read, git revert requires no thought.
> Cons: You’re erasing history—you can no longer tell if two commits were written together on a single feature branch.

Could the con not be addressed by using the --no-ff even if it's a fast-foward merge? A merge commit in that situation points to the same tree as the HEAD commit of the branch that was merged, but the merge commit also has the information about the base commit and the head commit of the branch, so you know what commits were in the branch even after it's merged.

Shorel• 4 years ago

I agree with you in the most general sense.

Someone's "accurate history" is just noise to everyone else.

Squash and cherry-pick your commits to a public repository, people.

Now, multiple people working in parallel is something else, but many times a long set of code experiments is not valuable history.

eurasiantiger11• 4 years ago

It is valuable history: it is archaeological evidence of what has been attempted before.

y4mi• 4 years ago

Methods: git merge --ff-only or git rebase && git merge (extreme clean freaks add the --squash option)
> Pros: Linear history, git log is easy to read, git revert requires no thought.

Does it require no thought because it's fundamentally impossible? if you're doing -ff without squashing it's gonna get hard to figure out which commits you'll have to revert I think. All histories get merged into a single stream after all.

unicornmama• 4 years ago

Merge commits provide best of both worlds. Too bad GitHub and friends refuse to render history with —first-parent. So we’re stuck with inane squash commits.

MrPatan2• 4 years ago

Just always do a merge commit into your main branch, and you have the best of both worlds, don't you?

- A straight history of merge commits you can revert or bisect.

- Handy pointers to all the branches you merged, in case you ever need them (I never have, but I do use merge commits)

At some point I may learn to let go and go full squash-and-rebase, which is the same thing just without the handy pointers to the dev branches (which, if I ever needed them, I'm sure there's a git command to fish them out of the repo). But for now I'm OK

TomSwirly3• 4 years ago

Merge commits add negative value to your commit history.

They are a memory of a commit ID and of a branch that no longer exist. They add complexity and empty information to your project for no useful value.

Also, for writing git tools, life is much easier if the commits form a tree. But a merge commit has _two_ parents. If you have even one merge commit, your commits are no longer a tree.

Handy pointers to all the branches you merged, in case you ever need them (I never have

TOO MUCH INFORMATION.

No, get rid of it. Extract any information you might need into the code review or the branch.

I mean, that commit ID will probably float around your repo for the next six months, so it isn't like it's gone immediately.

It's hoarding! Let it go! :-)

u801e7• 4 years ago

Handy pointers to all the branches you merged, in case you ever need them

The one thing that GitHub does when it generates the merge commit (which it does even for fast-forward merges) is that it adds a link to the PR associated with that commit. It's a handy way to go back to the PR and see the review of the branch before it was merged.

For projects that use the email patch workflow like the Linux kernel or git itself, the merge commit message contains the branch name which can be used to find the mailing list discussion. In the git project, you can find the "what's cooking" emails to find the branch name and references to the message-id of the patch series cover letter.

jillesvangurp• 4 years ago

A lot of this stuff is written from the point of view of people pushing changes to a central repository. Git was actually designed from the point of view of people pulling changes between multiple forks and doing that at an enormous scale.

Team clean and team accurate both win here. If your git branch has an ugly history, you'll have a hard time convincing others to pull those ugly changes. They'll throw it back at you and tell you to clean that up using the tools that are available to you. That's why it's called a pull request and not a push demand. You are asking others to pull your changes and merge them.

Open source projects are a lot better at this than corporate projects where it is common for people to huddle around a central repository where everyone has write access like they are still using subversion 20 years ago.

With Linux, the only person that does not have to worry about people upstream from him is Linus Torvalds everybody else is pulling changes from others all the time and they are paranoid about making sure to not rewrite history. You only ever rebase your own changes and only before you share them with anyone else. Linus Torvalds runs a complex network of people from which lots of patches emerge (git patches, that is). If it's not clean, it won't get in. If it's not accurate, it won't get in. And they all pull changes from upstream. So if upstream no longer merges cleanly because you rewrote history on your fork, you have a problem. Simple solution: don't do that.

The linux commit history is an endless sequence of squashed merge commits (and some small commits). Some of them big, some of them small. It's both clean and accurate. And this simplifies the process of pulling those changes for the many forks. torvalds/linux actually has no branches, just an insane amount of forks (45k, and that's just on Github), which of course is the same thing in git. Some of those forks are where maintenance releases are created for older versions of linux.

seba_dos121• 4 years ago

The linux commit history is an endless sequence of squashed merge commits

Nothing is being squashed in Linux.

TomSwirly3• 4 years ago

Hear, hear.

I have absolutely no interest in "accurate history".

WHY. Do people really want to see my minor spelling mistakes and goofs that got corrected in review?

It's worth spending the extra time to have a completely clean and perfect log, if only for being able to read your commit history like a novel, but also for using `bisect` to find regressions and behavior changes.

---

I have gone to extremes. At some point this summer, I realized that running the tests with one collection of flags led to breakage, and this breakage had been there for almost two months, and it was important that this flag work. (Yes, it was also a testing/CI issue, and we fixed that.)

I found the issue with `git bisect` and then patched that change two months ago and rebased everything - a couple of hundred commits.

We all feel it is of key importance that all the tests pass at each commit ID, so no one had any issues with that and it really didn't take very long.

To rebase without changing modification dates, use

`git -c rebase.instructionFormat='%s%nexec GIT_COMMITTER_DATE="%cD" git commit --amend --no-edit' rebase -i`

gorgoiler2• 4 years ago

There are two kinds of history: private and public.

When you are writing your book, your drafts might be versioned and you might want to revert a chapter or section if it turns out to be of no value. Later on you might want to cherry pick that chapter out of the bin*. That’s all part of the writing process.

When your work is complete you have your editor give you feedback on which also use a revision control system. This isn’t quite public but it’s different to the private process in that the changes have semantics related to the decisions making you and your editor take part in. Those decisions need to be recorded in the history of the project. You eventually publish the first edition.

Longer periods of time see revisions to the first edition. A friend of mine just finished his third edition ten years after the previous one. These big changes will be made up of many small changes you do want to know about (decisions you and your editor came to) and many you don’t (“wip reverting section 43 / 45 ordering”.)

Software is the same. Some people want to publish their entire decision making process. This is a mistake — no one finds value in it, so it should be kept private. Most people are happy for the decision making process to be public (pull request arguments) or at least their outcomes to be visible (ff commits of approved PRs.)

Editions of the work (tags and/or release branches) shoul have a git log at the granularity of ideas that were agreed upon and made public as opposed to every single idea we ever had.

*Is a writer’s reflog their wastepaper basket or their brain?

madmax108• 4 years ago

This is a mistake — no one finds value in it, so it should be kept private.

Just anecdotal, but I disagree vehemently. In my experience, an easy way to follow Chesterton's fence ( to figure out why a piece of code is the way it is before modifying it's behaviour), is to understand the decision making process that was being followed and not just the blob of code that added it (Even more so on older repos where the original author may not be around).

Many a times, it becomes obvious that the code was written under a very different understanding of the what the system evolved to be, and as such can be changed accordingly, and inversely that the code makes certain strong assumptions when written which hold true even today.

This is why as a thumb rule, especially for junior developers just getting started with git, I spend time on getting them to understand good git commit messages instead of 'git add . ; git commit -m "some code"' because I've seen a tonne of value retrospectively in this.

someweirdperson2• 4 years ago

[...] I spend time on getting them to understand good git commit messages instead of 'git add . ; git commit -m "some code"'

Decisions could also be documented explicitly, explaining the pros and cons of possible solutions to future readers. However, in absense of this, commit logs may contain this information, better than nothing. But with all the commits kept from development the logs will contain a significant amount of non-interesting information, and make the history hard to read a few years later. And reading the log to find something will get slowed down by explanations that should be in docunents or comments in the code.

lamontcg2• 4 years ago

understand the decision making process that was being followed

This should be documented in the PR in human language, hopefully with some backwards and forwards and questions asked and answered.

I'll frequently go back and document why the PR wound up the way it did even after everything has been merged and shipped because some discussion a day later makes me realize that the information had never been captured.

And those can be options that were never in the commit history because they weren't the path that was taken.

Then a few years later you can read the PR and see that there were different options, that some of them were rejected as not meeting the actual requirements, there might have been concern about breaking changes, the very issue that has cropped up later might have been anticipated but a simpler solution was used on the expectation that the complicated solution wouldn't be necessary (and now it is necessary). The "why" of a change is a lot more than the history of the person typing on the keyboard and making commits, there's a whole lot of thinking that goes into a change which is never reflected in a single line of code.

gorgoiler2• 4 years ago

You’re absolutely right. Version control should show the changes to the code as well as the reasoning for making the change. Our only disagreement is that you want to track that using the commits that led up to the final idea being complete, whereas I delete the history and rewrite the story of the idea, what was there before, what’s changing, and why in the final commit message.

When the problem you want to solve is to provide a historical account of new features for future developers fixing bugs — often you, yourself — then a written document of a few paragraphs, right there in the git log/ blame, provides the highest signal.

copirate• 4 years ago

The private/public distinction also matches Linus' view on when history can be rewritten: https://www.mail-archive.com/dri-devel@lists.sourceforge.net...

codeapprove• 4 years ago

As someone who is a big proponent of "squash and merge" I am susprised to see myself labeled an extreme clean freak! I don't have very extreme git uses or opinions.

I want a few things in my team's workflow:

* A commit history that a human can mostly understand

* Effective code reviews where I can easily see what changed between rounds

* The ability to revert a whole Pull Request easily and cleanly

* A local workflow that does not get in my way and allows me to be messy when I need to be

For our team that means we commit whatever we want to our local branch and then squash and merge the whole thing at the end. The result is a single commit saying "Adds feature foo". I don't feel like I lost anything in the squash ... am I missing something? I really don't want to have "fix lint, address review comments" in the shared commit history.

jlokier• 4 years ago

The result is a single commit saying "Adds feature foo". I don't feel like I lost anything in the squash ... am I missing something? I really don't want to have "fix lint, address review comments" in the shared commit history.

Neither.

If you're doing it then way it's done in Linux, you will end up with neither of those. Instead you will have: "Add a new geometric engine with tests", "Add the geometric engine to view API keeping backward compat", "Use the new view API extensions in the main window renderer", "Implement behaviours for feature foo in the renderer", "Hook up scripting extensions, keys and menu options to make feature foo user-accessible", "Add basic documentation for feature foo".

No "lint", "reviewer feedback", "fix typos" or "I changed my mind and reverted the last revert" trivia goes in the history.

You should not in general submit your minute by minute trivial actions, indeed the commits submitted are usually not even in the same order as they were written and refined

Nor are the above individually complex, logical, meaningfully revertable and bisectable changes squashed down to an unhelpfully crude one-liner "Add feature foo" with a 5,000 line diff that touches most files in the project.

Some would say the logical changes should be separate PRs. To some extent, but it depends how fast you wrote the feature, whether the round trips make sense, and how involved in the nitty gritty you want the feedback to be.

The ideal unit of review or feedback, ie PR size, is often larger than the unit of a logical change. That's because the "future why" is not so apparent with individual changes, so people tend to zoom into the weeds instead of using appropriate context. In so doing they also tend to use up their reviewer attention budget so the other changes don't get the same scrutiny.

Think about the feedback to the first big logical change "Add a new geometric engine with tests": "Why are you adding this? What is the motivation?", or "This works but the API has these unnecessary warts" (warts you have to explain will be necessary in 3 PRs time). You can either have a chat in the PR feedback where you have to persuade someone that the rest of your plan makes sense, not easy if they can't see how it does. Or you can present the later changes all together as a group and then the code speaks for itself, much more convincingly.

melonrusk• 4 years ago

I have no idea what this article is talking about, but if there are two plausible representations for the whatever-it-is, why not allow it to be represented both ways ?

GitHub's Missing Merge Option

Related Stories