Extracting this discussion here, so it doesn't hijack T12804 too much:

In T12804#227101, @nickhutchinson wrote:

I'd like the commit graph to come back in some form -- looks like it was removed in rPc5bb69fd7d79. For the reasons @epriestley outlined here: rPf2fcafb40dde#38208, this view is really useful for visualising the relationship between Git branches and sanity-checking recent merge commits. These are tasks that would otherwise require something like gitk.

Our workflow relies heavily on merges. Let's say we have three Git branches, v1.1, v1.2 and v2.0, representing two maintenance releases as well as the latest-and-greatest. Any bug fixes for v1.1 need to be committed to that branch, merged onwards to v1.2 and then merged from v1.2 to v2.0.

Personally I'm reasonably happy to go back to using the command line and/or gitk for visualising the history, but that's not true for everyone. In the extreme, we have remote Windows devs who refuse to learn Git, gitk, the command line or anything associated with it. I can't send these Windows devs a CLI snippet to bring up a gitk window to demonstrate their bad merge, but I can point them to a Diffusion page that they can view using an Internet Web Browser that shows the same thing.

In T12804#227133, @nickhutchinson wrote:

In T12804#227102, @avivey wrote:

I think we have it documented somewhere that "we have developers who refuse to learn git" is considered a bad reason to ask for a feature, and you should maybe consider solving this issue with some workflow changes.
Note also that in your link, epriestley says

In projects which do not linearize history with arc land + squash merges, I believe this feature is virtually useless because many commits are merges and visualizing the repository isn't very informative (the history has so many parent/child relationships that none of them convey much of anything).

which can translate to "We don't understand exactly what you're trying to see - what's the root issue?"
From your description, it sounds like a listing of "is commit in branch" for a given commit and all/some branches would be more useful for you.

Equally valuable as "what branches contain that commit" is "what commits are in the branches we care about". For us, the answer to this is the commit graph -- it's a succinct, easy to understand representation of our branches and their relationships.

I get that if you only have one primary branch, there's not much value in the commit graph. Similarly, if you're not linearising history, your commit graph will be so messy as to be meaningless. But if you do have the requirement to actively maintain several releases of some B2B software package and have a well defined branching strategy for your team to make this happen, then the commit graph is meaningful and unexpected merges will stick out.

For clarity, we're currently maintaining three active releases, and our commit graph looks something like this:

v2.0
 o
 o
 o
 |\
 | \
 |  \_v1.2
 o      |
 |      o
 o      |\
 |      o \
 |      |  \_v1.1
 |      |      o
 o      |      |
 o      |      |
 |\     |      o
 | \    o      |
 |  \   |      o
 |   \__o      |

Apologies for being glib about our Windows friends. But I really do think it's valuable to be able to send a Diffusion URL to a remote team member and trust that they are looking at the same thing as you, irrespective of their choice of platform. We'll need to come up with an alternative, probably web-based visualisation if Phabricator's commit graph really is gone for good.