KDE appears to be moving to GitLab (see: https://gitlab.com/gitlab-org/gitlab-ce/issues/53206) and we haven't seen this request from other installs, so I'm just going to close this out.

D20420 accepts these refs. We don't show notes in the UI, but we have no outstanding customer requests for this.

See followup in T13105.

The apparent lack of support for scheduling in UTC in much more mature calendar software (Google Calendar / Calendar.app) further suggests that this is not an important feature for most users.

In T5698#223992, @chad wrote:

Oh hai Cura uses Phabricator? I have a Lulzbot at home!

Oh hai Cura uses Phabricator? I have a Lulzbot at home!

@Krinkle, @pablocarrillo I second your requests. Great suggestion. I have a large README.md that I would love to split into multiple documentation files, without losing all the formatting.

And hg export is mostly the same deal as git format-patch.

T12618 could be accomplished by parsing hg log --patch --rev <rev>, which is similar to git show.

KDE has some interest in this as our contributors are distributed around the world.

Recent security issues in GitHub, GitLab, etc., with markdown:

I'm going to probably re-design this page a little.

I think we could even default it to "fancy mode" without a setting, at least to start with. I'm not sure anyone will want to access the plain text mode with enough frequency that we need it to be sticky.

@epriestley this doesn't seem hard to build for a fledgling designer/intern engineer.

In T5029#210026, @bcooksley wrote:

@epriestley my apologies for this. I had sent out a memo previously asking for everyone to file tasks on our Phabricator so that I could co-ordinate things from there. It seems some folks have missed that, so i've now resent it to a wider audience.

(They could also go into the existing "Waiting on Review" bucket, but I dislike mixing authored and non-authored revisions in that bucket.)

The actual reproduction instructions are slightly more involved:

This is something I've wished for a few times. Along with just searching for repositories in general.

Sorry, yes I am bad cop sometimes. :(

@bcooksley, feel free to mention that you've talked with me about stuff when filing tasks in the future. Like 90% of what shows up here spontaneously is pretty questionable, so unannounced reports get fairly strict scrutiny.

Here's the downstream task: https://phabricator.kde.org/T5406

Note that I'm not asking for this to be done for everyone, by default. Rather, I want this to be an opt-in feature. I imagine this is also what the people who voted for the question on StackOverflow have in mind.

I was commenting on your suggestion to remove unwanted items from commit messages. It's a compliance feature for many businesses who need complete audit trails.

@chad sorry, but I don't follow, what has accountability to do with this?

@milianw Please keep in mind Phabricator is an enterprise tool, and the majority of installs (99%) are businesses who rely on the accountability we've built into the software.

See T10622.

Another reason for having a template:

Regarding what modifications I would like to see:

Also, please work with other KDE project members to discuss KDE priorities and needs downstream, then have a single point of contact (nominally, @bcooksley) bring them upstream once there is consensus on the nature and priority of problems. Currently, you, @abika, and @bcooksley are all independently interacting with this upstream.

What specific modifications are you interested in making to the messages?

See downstream for general discussion. See T12256 / T12257 for upstream followups.

Ah, thanks! Good to know what my own community is doing.

I would imagine they're using something along those lines yes. I think we'll probably keep a bunch of people happy if pushing Git refs up were supported.

I'm just curious how people are generating diffs, just command line then cut and paste? I would presume those users would be fine with pushing a branch up for review. Are there other methods we're not considering, like IDEs?

Chances are we're going to get complaints that go either way. Myself, i'd tend to prefer T5000.

You would prefer this over T5000?

We've had some people in KDE kick up some fuss about this.

No easy way to apply a policy to a group of repos.

In T5000#176440, @epriestley wrote:

Another possibility is that we just build this behavior (intercept and react to ref changes) as an extension point prior to the Herald, and then you can implement whatever magic you want. I suspect very few installs want the default behavior of git push origin mybranch for arbitrarily named branches to be anything except "create a branch".

Some parts of KDE use git notes fairly extensively for certain specific workflows.
How difficult would it be to have Phabricator permit pushing Notes, even if Phabricator itself didn't do much with them (doesn't need to display them)?

It's entirely possible I missed some things in supporting the 25,000 different URI forms we now support, but just file a new issue if you run into anything since this task is now 200 years old with seventy pages of unrelated disucssion.

How difficult would this be for someone to implement / does upstream have an implementation timeline for this?

How would we distinguish between source/android/browse/carafe/ being "browse branch carafe of repository android" vs "browse the home page of repository carafe located at path android/browse/" in such a scheme?

Shortname is already used for the shortname.git portion of the URI. Would it be out of the question to allow a separate path to be configured, perhaps also including nested directories?

In T3670#178894, @bhush9 wrote:

I am wondering if is it possible to re-parent existing board to some project? I mean if I already have project A and B and I want to make project A subproject of B without breaking links etc.. is it possible?

I am wondering if is it possible to re-parent existing board to some project? I mean if I already have project A and B and I want to make project A subproject of B without breaking links etc.. is it possible?

Callsigns have been optional for some time (roughly since D15305 in February 2016, although there were a trickle of bugs after that).

@epriestley thanks for the extra context. Makes sense now haha. Sad to see this get deprioritized though.

This was moved into the prioritization queue by a particular customer that was interested in defining Owners via Projects via external sync.

@epriestley can you explain how this was building up toward T10939? That one deals with automatically adding reviewers while this enables project membership (and hence policies) to be based on a predefined source of truth at most companies (LDAP).

I think this was building up toward T10939, and the actual solutions we're looking at there probably don't involve this.