11" Macbook breakpoint is 1080 it looks, I think we still do tablet around 960? 1080 is enough space for anything we do. Not sure where @avivey 's laptop actually is. I do want to add more information to blame view though, so the space will be used.

I was joking.

Did you consider increasing the "tablet" breakpoint above the size of an 11" macbook instead?

Just for @avivey and his 11" macbook: D18448

neato!

Yes. In Mercurial, branch heads may be "Open" or "Closed".

That the branch is closed?

What is state here? I don't really remember what this was about, or if it's needed.

Search is now in the header, see rP

I'm just going to merge this into T929, I don't think it's a distinct task. I'll link that to T12824.

adding my vote to @ivo's suggestion.

seems ok now.

caret now appears when attaching dropdown menus to buttons.

In the past there used to be a Browse button at the repository homepage in Diffusion. Clicking on it would show the file tree for the current branch and some extra buttons. You could then click Search to grep the file contents of the current branch.

Most browsers can only give us a timezone offset, like "UTC-7", not a locale name like "America/Los_Angeles". We already attempt to read this value (D15962, T3025#176547) but when I wrote that stuff it was only available in Chrome and not necessarily reliable. We do try to guess the default zone selection based on the information we get from the browser, but currently ask the user to confirm it in all cases.

I was thinking that the first time they log in, we just take the browser timezone and set the user config to that.

Since the History is now dumbed down and separated from the Technical details on the Graph view, it might be more useful to filter out merge commits from the History view. Perhaps they can be replaced by a small "Merged to <branch>" link at the bottom of the box for the last non-merge commit that was part of the merge.

We use (most of) the graph code for drawing the "Task Graph" and the "Revision Graph" so we need to keep it around in the upstream anyway.

doh! nice. I obviously need more coffee.

("Graph" button in upper right.)

https://secure.phabricator.com/source/phabricator/history/master/

I know just maintaining the hooks is more work but certainly less than what's involved in maintaining the graph code.

I think that's what D18131 did -- or do you mean something else?

Maybe provide some extension hook-points in diffusion so that the community can maintain the commit graph visualization as an extension?

Ah, alright. Yeah, behavior is:

This is great for testing!

I'm fine with 7 days, I didn't think we had any auto-update.

Oh, maybe I misunderstood. I thought you wanted an easier way to test changes in a development environment, but it sounds like you actually want end users to immediately get the new images instead of needing to wait 7 days for them?

I was wanted something I could trigger like celerity, generate a map hash or something. I presume users still need to run this command?

A slightly more aggressive fix would be to make these have a 5 second TTL in development or something (or hash the file modification time into the builtin key? But that's a bit tricky...) so you'd never have to purge the cache, but I think this arises rarely enough that it isn't too valuable.

Strictly speaking, you still have to do a "manual purge" (with bin/cache ...) after D18146, but I assume you just didn't want to have to fish around in the DB.

So simple

In T12859#227762, @chad wrote:

Also not sure how to "retire" ones from Projects I don't intend to replace (low value).

Ouch, sorry for the noise. I usually get confused between Diffusion and Differential.
Keep up the good work.

This task is for Diffusion feedback, not Audit or Differential

My two cents here:

+1 for bringing this back.

(Fine to keep open so I don't forget)

There will be a place to get to this.

(I've extracted the graph issue to T12840)

In T12804#227133, @nickhutchinson wrote:

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 perspective we use commit hooks to ensure that commits made in patch releases must exist in upstream major release first before being allowed in the respective patch branch. We then utilize herald to notify a group about suspicious merges or commits.

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.

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).

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.

T929 is probably the earliest request for this feature :)

Not exactly related, but these cancel buttons used to be grey and are now blue:

Well let me actually re-read everything then.

Sorry, I guess I'm being unclear: I don't believe that (1) is a reasonable starting point.

The flag color system seems like overkill though, I wonder if we can simplify that.

I'm agreeing that (1) is a reasonable starting point.

I think maybe we're talking about a couple different things? These are both relatively easy:

Have flags as an automatic search filter then like projects?

have a flagged filter automatically everywhere

Maybe also, in general, we could define an "explore by tags" view, that works something like this:

Flags is something I definitely thought about, since it's already everywhere. If it integrated with applicationsearch (have a flagged filter automatically everywhere) I think that's reasonably handy and easy to build UI upon.

Constructively, some adjacent changes which are maybe worth considering instead: