Okay thanks for your answer. So if i used audit.Query to get (for example) audit statuses etc.. I have to wait that diffusion.commit.search implements all functionnalities?

No.

Is it possible to unfreeze audit.query if diffusion.commit.search is not returning enough informations to replace audit.Query?

+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 :)

Let's do both!

Maybe every object should allow a cover image then?

also, T8407 maybe fits here? I think it's mostly a UI issue now.

good stuff, thanks!

I resorted to hg log -r "descendants('XYZ123')"

Maybe this was the workflow?

Oh jump to the history via pagination and scroll to it? I don't know if that's technically possible. It's interesting though.

Hmm the history view on this install is significantly different than the one on mine~

The button. That says Browse. 💃

I just came across this today, though I can't recall a time in recent history of it coming up previously. I was looking at a commit in history and wanted to browse through history at that point - if there was a way to jump to the commit history at the point from a commit, would've helped. In this scenario I knew a commit was made shortly after the one I was tracing and trying to locate - that doesn't happen often though.

My solution to this problem was to compile version 3.4.2 of mercurial and install with a different PREFIX, and only use it for pushing to phabricator. That way I can use the latest version of mercurial for everything else.

@jcox ???

(We also likely have a similar problem for hg that D18105 won't fix, and can't use the same strategy there since hg grep has no -f flag or equivalent.)

Note that D18104 is not retroactive, so existing feed stories aren't expected to change after upgrading. New feed stories published after picking up the fix should show "alice committed <commit>" as the title again, though.

In T12804#226525, @epriestley wrote:

In T12804#226522, @bjshively wrote:

The pagination view for very large source trees/folders (in our case located at ourdomain.com/diffusion/name/browse/master/averylargefolder/) is confusing. Specifically, the pagination buttons are placed below related Open Revisions. This can often be confusing or misleading, as it is not immediately obvious that you're not seeing the full set of files.

It might be clearer if these buttons were immediately below the content being paginated (i.e. sandwiched between the averylargefolder list view and the Open Revisions.)

The pagination view for very large source trees/folders (in our case located at ourdomain.com/diffusion/name/browse/master/averylargefolder/) is confusing. Specifically, the pagination buttons are placed below related Open Revisions. This can often be confusing or misleading, as it is not immediately obvious that you're not seeing the full set of files.

See also T7339 and T5554. But the approach we are generally taking there is "wherever possible, use a method where locale configuration is not relevant", which is consistent with using -f -.

This works properly on my local machine (OSX) so it's some kind of Ubuntu UTF8 CLI thing.

Hello, we used this function (add project to a commit by Herald rule) as well happily for about two years (last update of phabricator was 03/16/2016). The current phabricator update (06/06/2017) now lead to messages in the activity feed in the form of "Herald added a project to rXXXXX: <message>: <project>" and the commit itself (or better the message) does not appear anymore. When we disable the Herald rule the commit-messages appear in the feed again as before and expected.

yes

Does this work without using arc and just normal git commit?

I think the Twitter server has some uncommon load issues, partly because a git at twitter has some unusual load issues (I know Twitter had to patch git locally at some point to make it work better). You should probably reach out to the internal Code Review team and complain again.

In T12804#226416, @chad wrote:

I don't believe moving buttons and changing layout will affect page load speed. If you have real performance issues, we should address those in another task.

Though we could remove branches/tags on the initial home page of the repository, I'm only seeing about 500ms a load.

I don't believe moving buttons and changing layout will affect page load speed. If you have real performance issues, we should address those in another task.

I'd like to see little forward and back arrows at the top of the page when viewing actual commit objects. This use case might be unusual, but I've needed to find "the last commit before DXXX" and "the first commit after DYYY" a few times. GitHub doesn't appear to offer this either, but it feels a little easier than just providing links to the parent commit.

I think the majority of issues I (and many others at Twitter) run into is due to performance / slow page loads. If there is anything in the UI that could be minimized / simplified to speed up page loads, that would be really helpful. However, I imagine that performance is mainly a back-end issue (and probably our instance's fault in some ways).

I think branches could be more accessible so I don't have to scroll to the bottom of the page, especially if my file tree is large.

I think "search across multiple repos because we have 2,000 extensions" or whatever is a great use case, that just didn't seem to be the motivation of any of the requests above -- I think it wouldn't make sense to put cross-repo search on the main page of a particular repo, or particularly on subdirectory browse views.

In T12804#226348, @epriestley wrote:

You can use, for example, -C3 with git grep to show 3 lines of Context around each match.

About 95% of the time when I'm searching for content it's because I want to edit a subset of the callsites. I do this with git grep some_function | maybe_more_grep | give, which opens all matches in my editor. This would take me about 100 years from the web UI for a nontrivial number of results. Do you have some other use case for searching for content?

My rough plan is to get rid of all the curtain stuff and move to button bars so the content can be full width. Owners stuff could get a new UI under the file content.

I just mean the curtain, yeah (It can be a largish chunk of the screen on a laptop)

It's limited if your company doesn't provide you with a 31" Dell monitor.

Maybe this is a better screenshot:

Slightly less important is that the width in the Browse File page is limited

When grepping in a repository, the results should (optionally) be ordered by their blame date.

u w0t m8

In T12804#226366, @epriestley wrote:

When I view a repository, it would be incredibly helpful if the files I most recently touched were at the top of the UI.

When I view a repository, it would be incredibly helpful if the files I most recently touched were at the top of the UI.

(Some of this discussion is pertinent to T9287: Working with many repositories)

In T12804#226344, @epriestley wrote:

What do you use file content search from the web UI for? (That is, in what situations is web UI search better than git grep?)

I execute content searches very frequently (hundreds per day?) but about 99.9% of them are git grep and maybe ~0.1% are web UI.

What I would really love to see is global filename search. Currently you can search for a filename within one repository but you have to know which repo to look in first.

We have thousands of repositories and it's hard to differentiate in a list which repository I need.

I would also say I use git grep locally probably 95% of the time, and web maybe 5%. It's not part of my usual routine.

I don't want to assume everyone is a knowledgable engineer who is sitting at a desktop with a cli and the code checked out. Diffusion to me is a web front end that is much more enjoyable, sometimes quicker, sometimes slower to browse and search for things in codebase that maybe aren't "I'm, coding right now" related?

In T12804#226344, @epriestley wrote:

What do you use file content search from the web UI for? (That is, in what situations is web UI search better than git grep?)

I execute content searches very frequently (hundreds per day?) but about 99.9% of them are git grep and maybe ~0.1% are web UI.

In T12804#226305, @epriestley wrote:

In T12804#226290, @sascha-egerer wrote:

T8442 would help a lot for those "I have to many repositories"

Today, you could save searches in different Spaces. For example, here I've done this:

• Search for "Spaces: Phacility".
• Save the search as "Phacility Repositories".

Do you use this strategy today? How would T8442 improve on this? If you don't do this already, but dividing repositories by Space is useful, why don't you currently do it? Put another way, what problem exists with search today that T8442 solves but search changes could not solve?

You can use, for example, -C3 with git grep to show 3 lines of Context around each match.

I like GH search where I can see content before and after the term searched for. This has been helpful for migrations where I'm searching for something generic like addButton that is on multiple classes.

What do you use file content search from the web UI for? (That is, in what situations is web UI search better than git grep?)

I'd be happy if you just added Grep File Contents search at the base repository view. It is kinda annoying that I have to click into a sub-folder to grep (sometimes I don't remember which folder it is in).

In T12804#226303, @epriestley wrote:

Maybe I'm misunderstanding what you mean by "omnibox"? How do you use the search input to search for anything other than file content?

Thanks - I thought it was already filed but couldn't seem to find it.