My plan is:

• If there's a commit information in the revision, use the author name and email from there. Not that this might not be the same as the revision's Author
• If there's no git commit - use author name from Author field, and make up email address (annonymos@example.com).

@avivey Yes I think this is what we need.
There is a caveat though:

@ton - this is what I have so far:

I have created T15559 with extra information, now that D25342 was closed and the issue behavior changed somewhat.

Feel free to elevate this as a Task, since it's a nice bug report

Unsure if tagging as Bug Reports

The workaround for me was to manually strip all of these lines:

yeah, typo. I'll fix it again...

ok, now I understand.

Thanks :) Silly question since I'm not native English: is there a repetition in "creating revision from revision from raw diff"?

I agree and that is why the general idea is: still showing your Diffs, but, showing the selected one (even if it's not yours). So it's just a +1 entry

I suspect just listing all open revisions would make using this page even worse - users will have to wade through a giant list.

In an early version I did not consider "do it only in create mode". Now I think the patch D25338 does what we imagine.

Here the follow-up:

Can I just propose a veeery small fix for this (it's one line, after all), and then create another one to modernize the workflow with that component? I'm not sure I will be able to do not destroy everything if I immediately try the modernization ihih

consider just replacing the selector with a modern AphrontFormTokenizerControl - that smart search features.

Marginally related to T15096

The task had a heavy dose of "describe a solution, not a problem", so I cleaned it up.

Hoping to receive more feedback from the original author (without closing as invalid) I keep open but with a cute Clarification Needed

Probably this is a good starting point to understand what to do:

More prior art: https://zuul-ci.org/docs/zuul/latest/gating.html#cross-project-testing

Arcanist internally generates a diff that includes a similar suggested parameter to account for the entire file contents being present in the resulting diff.

There is some support for this today, I have worked with dependent revisions in the past. There are some gaps but it’s possible today. I’ll look through my notes but I think this requires a fair amount of additional state tracking as commits change on local machines. I haven’t fully thought through it all but I think an ideal solution would be something like mercurial’s “evolve”, but that is likely a ton of work.

In T15364#8952, @avivey wrote:

"tooling for chains of diffs" might need its own topic, with a design of the what the whole thing should look like in an ideal world, and how to get to it.
Even if not all of the stuff fits nicely into Phorge, there's probably a lot that can work, and some conduit methods can be added to implement the rest.

Breaking this out from the discussion at T15364: arc land complaints summary by FreeBSD community

"tooling for chains of diffs" might need its own topic, with a design of the what the whole thing should look like in an ideal world, and how to get to it.
Even if not all of the stuff fits nicely into Phorge, there's probably a lot that can work, and some conduit methods can be added to implement the rest.

Chaining Diffs is something that we would like to use more often, and it is definitely not used enough today. FreeBSD is a large codebase and making any change that is bigger than trivial often involves touching multiple parts of the system, the most difficult kind of change is architectural changes. We are limited by our tooling to a certain degree:

• Keeping everything in one Diff makes it very difficult to review as well as reach consensus, as there are often multiple responsible parties involved. It also violates the ethos of Phab/Phorge of having small atomic changes.
• Breaking changes down in smaller chunks has lots of downsides too - it is very hard to track and changes often get lost in depths of Differential.

mmm... I've never really worked where many changes are made of lots of dependent revisions - it's possible I've never even seen a chain of 3 revisions in the same repo. So I'm not sure about workflows for this kind of scenarios.

Yea, today I have about 50 lines of shell scripting that gets the different bits of data from the condon API point and then bashes them into a nearly acceptable commit message....

Ok, so here's my thoughts on moving this forward:

FWIW I think the test plan is configurable (that requirement can be disabled in phabricator's config server side which should remove it from commit messages in arc)

What are the reasons for doing commit message rendering on the server side?

In an ideal world the solution should be as simple as having a template somewhere in {{repo_root}}/.arcanist/commit_template.j2 that arcanist injects values in and renders.

We can probably come up with a way to allow an extension to customize the "render template" implementation without forking (e.g., just add a hook in differential.getcommitmessage), but it would have to be very carful about the whole form-thing.
Maybe just adding an "for landing" flag in differential.getcommitmessage (or adding a different method) would solve this problem...

In T15364#8281, @ton wrote:

The template is actually generated server side, not in arcanist, so it just a matter of getting the BSD Phorge server to have the right opinions.
Some of the sections can be configured already

Please point me in the right place in the code where I can find the template

The template is actually generated server side, not in arcanist, so it just a matter of getting the BSD Phorge server to have the right opinions.
Some of the sections can be configured already

re @avivey : arc land --hold sort of works but look at the ergonomics:

Alternatively - there's also arc land --hold, which does almost everything except for the git push, which would allow the user to update the commit message. Have anyone tried that?

thanks @ton - these look very actionable:

In T15249#8232, @ton wrote:

@avivey today I tried arc patch to download a bunch of Diffs.

Some diffs check out OK. Lots of Diffs fail to be fetched, I get a very useless error message:

Exception
strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated
(Run with `--trace` for a full exception trace.)

@avivey many developers do not use arcanist at all for reasons outlined in https://we.phorge.it/T15096#6224 - many do not wish to install php, some find arc interface confusing...

@ton: Why are "they" not using arc patch to download the patch?

T15011: Build a Phorge Developer Environment

This?

I wanted to set up some docker/compose file or possibly a VM but didn’t get far since neither of those are great solutions on windows, primarily for getting local code into the container/vm. My goal would be to get a quick setup time with a rapid dev/test cycle. For me to make progress I’ll likely have to switch to mac or Linux.

In T15249#6474, @speck wrote:

Getting set up with a development environment (including database~) along with configuring the local instance and populating it with sample data is extremely daunting and is frankly why I haven’t done much contributing. I lost my dev environment a few years ago and have tried only once to get set back up, spent a few hours and never came back to it. It doesn’t help that arcanist’s self linter isn’t usable on windows systems.

I suspect the barrier is more the dev environment and less PHP or the codebase.

Getting set up with a development environment (including database~) along with configuring the local instance and populating it with sample data is extremely daunting and is frankly why I haven’t done much contributing. I lost my dev environment a few years ago and have tried only once to get set back up, spent a few hours and never came back to it. It doesn’t help that arcanist’s self linter isn’t usable on windows systems.

In T15249#6391, @ton wrote:

Ok, after spending a weekend looking at PHP I can say that I overestimated my level of enthusiasm.

I might be willing to take a stab at this but not sure when I'll have the time.

Phabricator's codebase is mostly high quality and fairly easy to jump into but I probably wouldn't recommend it for someone new to PHP :D

It is hard to say objectively, as I am new to PHP and to this codebase in particular. In total I spent probably 4-6 hours over the weekend, but someone with more experience could've done a lot more in that time. I was reading about PHP, setting up my dev environment, reading the code, navigating class hierarchy, trying to understand PHP idioms, etc. In the end of the day I realized that learning yet another language (and TBH not the most sexy one) in my free time to hack on a gigantic legacy codebase is not something that I want to do.

Ihih maybe we can have a "number of hours invested in this" as warning. Ton: how much?

I admit that I would be TOTALLY impressed if ton would be able to do something like THIS as first contribution. Fortunally this fail just means you are a human being.

Ok, after spending a weekend looking at PHP I can say that I overestimated my level of enthusiasm. This is the kind of work that I'd like to get paid for and not spend my free time on.
Sorry @avivey, but you can cross me off the list of potential code contributors.